# タイトルコール ようこそ、世界が広がるソフトウェア品質へ。 このチャンネルでは、エンジニアリングマネージャー兼QAリーダーのサミーが、 ソフトウェアデジタルやソフトウェアの品質保証を中心に、 日々奮闘していることや考えていることをお話しします。 毎日、お昼の12時30分に配信しています。 ゲストの方やリスナーのあなたと、 テストウェア品質の世界を広げていきます。 # テストケースの粒度が分からないです こんにちは、さみぃです。今日もテストしてますか? 今回はですね、テストケースの流度がわからないですという質問に答えていこうと思います。 質問なんですけれど、テストケースの流度ってどうしてます?どういう流度でテストを書いてますか? テストケースの流度っていうのは正解がないんですよね。 その誰が読むのか、誰がテストを実行するのかによってテストの流度が決まってきます。 なので正解は時と場合によるという感じなんですよ。 でもそれだと話が終わっちゃうので、現実的じゃないので、どういう風に考えていくんだっけというところを少し、 私はどういう風に考えているのか、どういう風にやっているのかというところの工夫をお話ししていきます。 その前提としてですね、そもそもハイレベルテストケースとローレベルテストケースの話をまず前提としてお話ししていこうと思います。 これはですね、JSTQBのシラバスのアドバンスドレベルのテストアナリストのシラバスに載っている内容ですね。 ちょっと補足をすると、JSTQBという日本のソフトウェアテストの資格試験とか、シラバスとかそういう運用をしている団体があるんですけれど、 そこの資格ですね、試験として一番最初にまずベーシックというかファンデーションレベルというのがあるんですけど、 その次にアドバンスドレベルがあります。 そのアドバンスドレベルにもめちゃくちゃいろんな種類があるんですけど、その中の一つにテストアナリストというものがあります。 テストアナリストなんでその名の通りどういうテストが必要なのかというテスト分析をしっかりして、 何をテスト対象というのかな、システムの何をテストするのか、どういう特性をテストするのかというところをしっかり分析してテスト活動に生かせると、 そういうのが求められているのがテストアナリストかなというのが私なりの解釈です。 あともう一つテストマネージャーのシラバスにもこのハイレベルテストケースとかローレベルテストケースの言葉書かれています。 テストマネージメントも先ほどのテストアナリストと同じようにアドバンスドレベルにテストマネージャーのシラバスというのがあります。 こちらはもう少し広く手のマネージャーなんでテストの全体を管理できるという感じですね。 なのでさっきのテストアナリストはどちらかというとテスト分析とかテストの分析設計実行あたりをメインにしているんですけど、 テストマネージャーはもうちょっと広くてテスト計画からテスト完了の報告とかテスト完了の方も含めてクロージングというところまで含めてがテストマネージャーかなというのがざっくり大きな違いになっています。 で本題に戻ってくるんですけれど、じゃあハイテキスト間違えたハイレベルテストケースとは何なのかなんですけど、 ハイレベルテストケースというのは詳細な記述をあまりしないのが特徴ですね。 でテストを実行の時にテスト担当者が経験とか判断とかというのを生かすためにあまり詳しくは書かないハイレベルなテストケースです。 ちょっと説明になってるかな。 逆にローレベルテストケースというのはもうあるいは誰が読んでも同じようにテストができるぐらい具体的に手順とかだったりを細かく書いていくというのがローレベルのテストケースになっています。 それぞれ長所と短所というのがあってお互い逆っていうんですかね。 ハイレベルテストケースとレベルケースとか両極端ですかね。 ハイレベルテストケースの長所っていうのは詳細の仕様が決まる前に作れるんですね。 大雑把にこういう時はこういう風になるという期待結果というかテスト結果になるのでプロセスの前半というか早いタイミングでも作ることはできたりしますし テストを実行時の柔軟性というのも上がってくるんですよね。 こういう状態の時にこういうオペレーションをしたらこういう期待結果になるというのがテストケースの型としてあったとして この粒度が粗いちょっと中小度というのがあるとテスト実行者実行する時にテスト実行者がこれってこういうことかなというのを想像膨らませて柔軟にテスト実行することができるというのも実はこのハイレベルテストケースの長所だったりします。 一方でなんですけど裏を返すとですね経験があまりないとか初めてそのシステムを触る対象テスト対象のプロダクトシステムを触るってなるとその抽象的なのだと何をしたらいいかわからないとか 本当はこういうことを確認したらいい確認するべきなのにそこが漏れてしまうというところもリスクは上がってきちゃうんですよね。 なのでローレベルテストケースの長所になるんですけどローレベルテストケースの長所っていうのは誰が読んでも同じテストが実行できるっていうのが長所ですよね。 再現性が高いって言えばいいんですかね。 でも一方でさっきその想像力というか柔軟性って話をしたのはそこはもう短所になるんですよね。 細かくこの画面を開いてこういうこの項目に位置というのを入れて保存ボタンを押したときに保存のダイヤルが保存が完了しましたダイヤルが出るっていう風に書いちゃうとなかなかそこから別のことを想像するっていうのはちょっと難しくなる。 抽象的にハイレベルテストケースで書いているよりかは想像しづらくなるっていうのはそれが短所になっていきますね。 シロバスの中での使い分けっていうのかなとして書かれているのはプロジェクトのフェーズテストのフェーズで変えるということですね。 最初プロジェクトの初期のタイミングではハイレベルでテストケースを書くでそれをだんだん仕様が固まっていくにつれてローレベルのテストケースを作っていく定義していくっていうのはそういうやり方があるよねという風に書かれています。 ここからは最後のパートになるんですけれど私がどういう工夫をしているかというお話でどういう風に使い分けているかっていうところなんですけれど テストの目的とあと誰がテスト実行をする予定なのかっていう誰がどういう人がテスト実行者なのかっていうのでざっくり分けているかなと思っていて テスト目的って言ったのは例えばシナリオテストとかで今回私が作る機能を使って何かユーザーが何かをやりたい実現したいものがある、実現したい業務がある、実現したい体験とか体験させたいものがあるっていう一連の流れがあったときに シナリオテストを書くときはハイレベルテストケースになってます。どの具体例で行こうかな。 例えば勤態システムがあったとして一従業員と上長が承認するといろいろあると思うんですけど、例えば上長が勤態の承認をするみたいなのがあったとき、その業務としてやりたいのは部下10人の勤態の内容を確認して承認をするみたいなのがざっくり実現したいことがあって それを実現するために、じゃあ個々人の勤態の時間各1ヶ月分のそれぞれの毎日の勤務時間が確認できるとか、ちょっとこうざっくりめのハイレベルなテストケースでまず書くっていうのは多いですね。 何を実現したいのか、何が実現できたら良いのか、妥当性みたいなところをシナリオテストで書いてたりするんですよね。 あえて抽象的にっていうのかな、具体すぎないようにすることで、じゃあそれってシステムで実現する場合はこういう風になるのかな、どういう状態が良いのかなっていうのを考える余裕とか余力とか、あとプロジェクトの初期のタイミングで画面がどうなって実装されるのかとかまでは決まってない段階でも書けるので、確かにそういうシナリオテストで、 今回の新機能の妥当性を確認したいという、そういう目的でシナリオテストを作ったりしているので、その時はかなりハイレベルなテストケースになっているなという風に思います。 一方でローレベルテストケースの一番パッと思いつく具体例というのが、リグレッションテストでかつ第三者検証とか、社外の方にテスト実行をやっていただいているみたいなテストというのはやっぱり誰が呼んでも同じオペレーションができる、同じテストの内容を確認できるということが大事、再現性がとても大事なので、 かなり具体的にテストの条件、テスト条件も手順も期待結果も書いていますね。なのでこの画面を開いて、この画面のここの項目にこういう値を入れたら、期待結果としてはここの画面にこういうことが表示されますとか、なるべく具体的に書くようにしています。 あとは普段の新機能の時のテストのテストケース、機能テストのテストケースは、テストをレビューする人と実行する人が同じ認識を持てる、どのくらい同じコンテキストを持っているかという次第で変わってきていて、そこまでめちゃくちゃローレベルテストケースじゃないとダメというわけではないです。 # #295のコメント返し🥰 コメント返しのコーナーです。今回は295話目、ほうれん草の動く意、あれどうなった?と聞かれたら終わりの放送のコメントを開始します。 コメントは、マツさんからいただいております。いつもコメントありがとうございます。 聞かれたら負け。分かります。聞かれるってことは上司を不安にさせているかどうかなんですよね。 いつまでに何をするか共有しておけば、基本的に聞かれることはないですが、自分から約束することは怖くてなかなかできないんですよね。 やったことないことは遅れるのが当たり前なのに、遅れた時に部下のせいにして怖さを植え付ける。 結果報告してもらえないことで上司の不安になる負のスパイラル。 上司側も急に聞きたくなったら負けという心持ちにするのが優しい世界な気がしてきました。 ということで、コメントありがとうございます。 なんか読んでて確かに言って、なんかちょっとほっこりなのかな?しちゃいました。 上司側も聞きたくなったら負けという心持ちにすると。 なんか自分も聞きたくなったら負けというか聞いちゃってるような気もするなーってちょっとコメントを読んでいてですね、自分の胸に手を当てて考えておりました。 まぁ遅れたからといって、メンバーのせいにするってことは私はしてないつもりではあるんですけれど。 まぁでも一方で私としては、なんかお願いしてるっていうか依頼させてお詫びしているという側として、 温度感とか気質感が2、3日くらいなんだけれど、 受け手の方は1週間くらいだと思ってたとか、もうちょっとゆっくりでいいと思ってたってことは結構やっぱりちょくちょくあるので、 まぁそこはなんかどっちが気をつけるというよりかはお互いにですし、 気質感、いつまでにこのアウトプットっていうところを確認しとく、認識をするっていうのは、 お互い認識を合わせるというのはめちゃくちゃ大事だなというふうに思っています。 はい、ということで以上コメント返しでした。 # 次回予告 今回も最後までお聞きいただきありがとうございました。 次回はですねGQMの話をしていこうと思います。 GQMっていうのはゴールクエスチョンメトリック数、メトリックかな。 目標をどうメトリック数に落としていくのか、指標に落としていくのかとかその作った メトリック数が目標をちゃんと達成できているかを確認 目標を達成を確認できる指標になっているかみたいなところ、その辺を考えるための考え方っていうのかな、 手法っていうのがあるのでGQMの話をしていこうと思います。 今回の放送を聞いて、なるほどな、確かにな、学びになったなと思った方は是非 画面右下ハートマークでいいねを押していただけるととっても励みになります。 是非是非フォローもよろしくお願いします。 それではまた明日お会いしましょう。ごきげんよう。