# タイトルコール ようこそ、世界が広がるソフトウェア品質へ。 このチャンネルでは、QENジニアのサミーが、 ソフトウェアテストやソフトウェアの品質保証を中心に、 日々奮闘していることや考えていることをお話しします。 毎日お昼の12時30分に配信しています。 ゲストの方やリスナーのあなたと、 テストや品質の世界を広げていきます。 # テストケースレビューで工夫している3つのこと こんにちは。Qエンジニアのサミーです。 今日も楽しんでいますか? 今回はテストケースレビューで工夫している3つのことをお話しします。 その3つのことというのが、1つ目がなるべくテスト設計の中間成果物を作ってもらうこと、 2つ目がテストケースレビューで何を確認するのかを言語化しておくこと、 3つ目がフィードバックの方法の認識を合わせておくことです。 順番にお話ししていきます。 テストケースレビューで工夫していることの1つ目は、 なるべく中間成果物であるテスト設計のアウトプットを作ってもらうことです。 よくあるのが、一番最終形態のテストケースだけボーンと渡されて、 レビューお願いしますと言われることはよくあると思うんですけれど、 最終成果物のテストケースだけを見て、そこからこの人は何を考えてこのアウトプットになったのかというところを 推察、理解するのって結構大変だったりするんですよね。 もちろんその書いた人の書き方だったりにもかなりよるんですけれど、 例えば思いついた順にバーって書いたみたいなテストケースだったりすると、 昨日の網羅性とか全体感ではこれは網羅的抜け漏れがないのかというところの確認がかなり難しくなってしまいます。 なので、特にですねパッと見て、一体これは何を保証しようとしているのかわからないテストケースになっている場合、 あるいはジュニアの方とかに対しては因子水準表を書いてみてほしいとか、 最初にどういうパターンだったりテスト観点を考えて、それがどのテストケースに結果になっているのかというのをヒアリングしたりとかをしています。 あと過去にやったことあるのは、一緒にテスト設計をする、開発担当者と一緒にテスト設計をするというのをやったことがあります。 そのときに案件の内容とか性質とかを見ながら、今回は状態遷移図が良さそうだから状態遷移図を一緒に書いてみるとか、 ディシジョンテーブルで仕様を整理した方が良さそうだからディシジョンテーブルを一緒に作ったり、みたいなこともやったことがあります。 一方でテストケースの最終成果物を見て、大体どういうテストをしようとしているのかがパッと見て理解できた場合とかは、 必ずしもテスト設計のアウトプットを作ってほしいというところは言っていなくて、本当はあった方がレビューはとてもしやすいんですけれど、 そのときの組織の状態、余力みたいなところを見ながらどうするかというのを判断しています。 ということで、ここまでがテストケースレビューで工夫している三つのことの一つ目。 なるべく中間成果物、テスト設計のアウトプットを作ってもらうでした。 二つ目はテストケースレビューで何を確認するのかを明文化するです。 さあ、テストケースレビューしようって言ったところで何を見るかが分かってないと時間がかかってしまいますよね。 私はDocsとかドキュメントとして、レビューで何を見るかの観点一覧というものを簡単に作っています。 イメージ機能テストのテストケースだったらこういうものを見るとか、テスト計画のレビューだったらこういうものを見るとか、 リグレッションテストのテストケースを更新するときはこういう内容を見るみたいなところを書いています。 いくつか二つぐらい機能テストのテストケースレビューでよく見ている観点を紹介すると、 例えばリクエイメントの内容が網羅しているかですかね。 PRDだったり、アジャイル開発だとストーリーの受け入れ基準とかでもいいかなというか当てはまったりすると思うんですけど、 要求に対してそれの内容がちゃんとテストの中で確認が全部できているか抜け漏れがないかということは確認する必要がありますよね。 あとは異常系の観点が含まれているかみたいなのもあったりして、条件の分岐みたいなものが網羅されているかとか、 異常系も考慮されているかというのはよく見る観点だったりします。 あとはそのテストの組み合わせテストでどれかのパターンを間引いているときは、その間引いているロジックというか理由がちゃんと妥当かどうかという確認だったりとか、 リクエイメントには書いてないけど気になる機能とか挙動とかというものがあれば、こういう観点必要じゃないですかみたいな話をしたりフィードバックしたりします。 そんな感じです。 ここまでがテストケースレビューで工夫している三つのことを二つ目。 レビューで確認することを明文化しておくです。 そして最後三つ目です。フィードバックの方法を認識合わせておくです。 ちょっとこれはやり方の話ではあるんですけれど、レビューお願いしますって言われたときに、そのフィードバックってどのように返しますか。 例えばスラックで依頼があったらスラック上にバババッと書きますか。 それともスプレッドシートとかテストケースのドキュメントの方にコメントを入れますか。 それともスプレッドシートの別シートに一覧を作ってフィードバックを書いていきますか。 人によってどういうフィードバックの方が、人によってテストを作った人が直しやすいかというのが変わってくるかなとは思うので、 フィードバックの方法の指定がない場合は、たまにというか気になったときはレビューを開始する前に確認したりはしますし、 自分がテストケースのレビューをお願いするときは、テストケースのドキュメントにコメントを入れる形でフィードバックをお願いしますとかというふうにやり方はして押しするようにしています。 個人的にはスプレッドシート上でコメントを入れてもらうのが一番スムーズかなというふうには考えていて、 どこの箇所を指しているのかが一目で分かりますし、入れてもらったコメントに対して返信する形で、 例えばスラック上とかだとスレがいっぱい続いてしまうということもないですし、 コメントにしておくと件数もパッと分かりますし、終わったら勘定にすれば減っていくので、 そのコメントに入っているところを順々に対応していけば、テストケースの修正ができるという意味でも、 直接ドキュメント上でやり取りするのが私はやりやすいかなというふうに考えています。 要はテストケースを作った人が直しやすいようなフィードバックの方法がいいですよねということが言いたかったです。 特にフィードバックの数が多くて、例えば30とか60とかになってしまうと、 どこを直してどこを直してないのかというのは分からなくなってしまうので、 やり方も大事なポイントになってくるかなとは思っております。 ということで今回はテストケースレビューで工夫している3つのことを話しました。 1つ目がなるべくその中間指定化物ですね、テスト設計のアウトプットというものを作ってもらう、あるいは何かしらの方法で理解をするです。 2つ目がテストケースレビューで確認する観点を明文化しておくです。 3つ目がフィードバックの方法を認識合わせておくでした。 こういうことを工夫しているよう、テストケースレビューで工夫していることがありましたら、ぜひコメント欄で教えてください。 # 📣放送/相談/コメントリクエストを募集中！ おしゃべりリクエストボックスの宣伝です。 放送、相談、コメントのリクエストを募集中です。 このチャプターにリンクを貼っております。 2025年3月31日、今月末までの期間限定となっております。 こういう話をしてほしい、聞きたい、相談に乗ってほしいなど、気になるトピックを投稿しませんか? 悩みを気軽に相談できるサウンドプレスにしたいです。 あなたの投稿を待ちしております。 # 今日のほっこり話🚃🎺 今日のほっこり話です。オーケストラの話をします。 趣味でオーケストラでトランペットを吹いてるんですけど、最近オペラの練習が始まりました。 このチャプターにチラシの画像を貼ってますので、よかったら覗いてみてください。 ちょっとチラシ切れちゃってるんですけど、最低限必要な情報を見れるようにしてます。 曲目がですね、グノーのローメオとジュリエットでして、今回演奏するってことで初めてちゃんと聞いた曲ではあるんですけれど、一生懸命練習頑張っていきたいと思います。 練習会場が家から遠くてですね、眠い目こすりながらお家に帰るという日がちょっと続きそうですが、頑張っていきたいと思います。 はい、ということで今日のほっこり話でした。 # 次回予告 今回も最後までお聞きいただき、ありがとうございました。 次回はですね、レビューで指摘しやすい雰囲気を作るには、というお話をしようと思います。 今回の放送を聞いて、なるほどな、確かにな、まるみになったなと思った方は、 ぜひ画面右下、ハートマークでいいねを押していただけると、とても励みになります。 SNSでのシェアや、口コミでのシェアも、ぜひよろしくお願いします。 それではまたお会いしましょう。ごきげんよう。