QAチームのテスト設計改善およびテストマネジメント改善の取り組みを、9月16日に主催したD3QAにて発表しました。事前登録者数は500名以上、配信時の同時視聴者数は最大300名以上となりました。
質問も60問ほどいただいたのですが、イベント期間内に全ての質問に答えることができなかったため、3つの記事に分けて質問に回答します。また、当日参加できなかった方にも把握していただけるように、当日の発表内容から抜粋して紹介しつつ、質問に回答していきます。
本記事ではテスト設計改善に関する質問に回答します。
発表概要の紹介
改めましてこんにちは！ビズリーチのQA基盤推進室のブロッコリーです。社内でも社外でも「ブロッコリーさん」と呼ばれています。
私は先日「テスト活動の納得感を持ってテストケースを激減させた話」というタイトルで発表を行いました。
発表スライドは下記となります。
また、当日の配信内容はYoutubeにアーカイブとして残しています。45分弱の発表となりますので、興味があればこちらもご覧ください。
ありがたいことに、この発表に対しては計60問の質問をいただきました。
そこで3つの記事に分けて、いただいた60問の質問を発表の構成に沿った下記の順番で回答します。
- テスト設計の改善（質問1〜質問22の計22問）←本記事の対象
- テストマネジメントの改善（質問23〜質問32の計10問）←次回の記事にて回答
- 改善結果（質問33〜質問44の計12問）←次々回の記事にて回答
- 発表以外の部分（質問45〜質問60の計16問）←次々回の記事にて回答
また、質問の回答前には、今回の発表内容の補足説明も記載していますので、興味のある部分だけでも読んでいただければと思います。
テスト設計の改善に関する発表内容の抜粋
発表ではテスト設計改善の取り組みについてお話ししました。質問回答を記載する前に、発表内容の概要をお伝えします。
まず、テスト設計を手厚くしました。改善前ではほとんどテスト設計を行わず、テスト実施の工数が全体のほとんどを占めていました。改善後は、テスト設計とテスト実施の工数比を半々にしました。
さらに、テスト設計レビューも手厚く行いました。改善前ではほとんど行なっていなかったのですが、改善後はほぼ必ずテスト設計レビューを行いました。その際には、作成完了したものを行うのではなく、作成途中のものであっても、作成の方針が正しいのかというようなレビューを行なったりしました。
その結果、テスト設計の成果物も変わっていきました。改善後には、テストパターンの列挙を重視した記載になっていました。これにより、どの組み合わせパターンは優先度が低くなるのかを把握する議論がしやすくなりました。
このように行えるようになった理由として、テスト設計とテスト実装の考え方を分離したことが大きいです。テスト手順のような文章を書いたものだと、全体感としてどのパターンが書かれていないのか気付きにくくなります（この点は【質問3】で詳しく説明します）。結果として、テスト分析のフェーズでは行いづらい、テストを削減する取り組みが効果的に行えるようになりました。
以降では、このテスト設計改善の取り組みに対する質問に回答していきます。
テスト設計改善についての質問の回答
【質問1】テスト設計にあたって開発ドキュメントの参照はしないのでしょうか。開発ドキュメントがほとんど無い？
開発ドキュメントの参照はします。チケットの内容、開発ドキュメントだけでなく、その内容に対しての疑問点は実際に開発と議論しておきます。開発者との議論はテスト設計に着手する前、テスト観点出しを行う前後の活動です。
【質問2】テストと設計の比率を出していらっしゃいましたが（テストをいっぱいやるようにした）、数える単位は何ですか？人数？時間？その他？
説明資料では文字の大きさの都合上省略した形で書いていますが、比率を出していたのは「（開発の設計ではなく）テスト設計」と「テスト実施」の比率です。また、ここでの比率は感覚値ではありますが、工数比です。
【質問3】改善後の成果物サンプルやアクション内容は共有いただけたのでわかりやすかったのですが、改善前のとき（「テスト設計」と一括りにしていたとき）はどんな作成物を用意して何をレビューしていたのかを知りたいです。
改善前のときの作成物の例は下記画像の通りです。（発表資料17ページにもあります）
この成果物に対してのレビューはほぼ何もできていなかったのが正直なところです。それは、レビューに充てる時間が無かったという理由以外に、改善前の成果物はレビューしづらい記載内容になっているということがあります。
例えば、上記画像をパッと見て、2つの青囲み部分の違いに気付きますか？同じような内容に見えますが、実は「未入力でエラー表示されること」という期待値（赤囲み部分）がある行とない行が存在しています。改善前の成果物だとそのことに気付きづらいですが、改善後のようなテストパターン作成であれば、指摘がしやすいことが分かっていただけると思います。
【質問4】テストパターン作成にはどれぐらいの工数がかかるものでしょうか？
内容や対応する人によって変わってきますが、1つのテストパターンの図表作成につき30分〜2時間程度です。ですので、例えば「開発が着手した当日中にリリースまでもっていく」といったような現場であっても、問題なく対応することは可能かと思います。
【質問5】不具合が出たあと修正連絡を受けた時、何のテストを再度やり直すべきなのか設計段階をきちんとやっていれば浮かび上がるものでしょうか。
修正連絡があった場合には、テスト観点出しのところから見返すことで、どのテスト設計を修正すれば良いか容易に見つけることができます。
ただし、IDを割り振ってトレーサビリティを上げているわけではありません。
テスト設計の成果物には、それぞれのパターン表などにきちんとタイトルを付けていることが容易に見つけることができる理由です。タイトルはテストを行う対象を示しているのではなく、「なぜそのテストを行うのか」「そのテストを行うことでどんな部分でバグがないことを確認したいのか」といった、テストの目的を記入するように心がけています。
【質問6】テストケースを減らすのにHAYST法やPICTを使われたりしますか？
HAYST法1は使っていません。
プロセスとしてのHAYST法（HAYST法プロセス）では様々なやり方（手法）を使っていますが、その手法の一部を我々も使っています。ですが、手法を採用する意図は、HAYST法全体の中での利用意図とは全く違った考え方です。
HAYST法は、一見すると関係ないと思われる組み合わせに実は存在しているバグを見つけ出すのが目的です。一方で我々は、要件や設計から考えて関係のある組み合わせをテストしてバグがないことを確認するのが目的です。
このように、使う手法は同じかもしれませんが、手法を使う目的が異なります。
また、技法としてのHAYST法（HAYST法ツール）については、主に無則なものの組み合わせに対して有効な手法です。我々は無則なものの組み合わせ以外の方が多いため、技法としてのHAYST法は活用しません。
PICT2についても同様です。現状ではPICTのようなツールを用いていません。
純粋なペアワイズ3を導き出す際にPICTは有効なツールですが、有則な関係を持っている因子群では使いづらいです。
今後、ツールに頼っていくフェーズは出てくると思いますが、そもそもどのようにツールで作成されるのか、どのようにしてテストケースを減らしているのかをQAメンバーが理解していない限りはツールを使う予定はありません。
【質問7】具体的にどういうケースを削っているのか知りたいです
網羅基準を意識して削っています。
例えば、因子がA,B,Cの3つある場合のテストでも、下記のように、対象のシステムの状況によって網羅基準が変わっていき、結果としてテストケースを削ることになります。
- 全ての組み合わせで考える
- 二因子間網羅で考える
- 実は因子Cは組み合わせることが重要ではなく、因子Aと因子Bの組み合わせを考えつつ、因子Cの水準は満遍なく登場するようにする
詳しくは今後のD3QAで発表したいと考えています。
【質問8】テストパターンというのはどういうものを指しているのでしょうか？テストケースを作るための一段抽象化したまとまりという認識でいますが…。
一例としては、スライドの32ページで示した「改善後のテスト設計成果物」です。他にも、状態遷移図を図示した上で、状態遷移表を作ったりもします。詳しくは、今後のD3QAで発表したり、本ブログで紹介できればと考えています。
【質問9】テストケースを減らしたところの品質の担保はどのようにするのでしょう？
我々が減らしたのはテストケースであり、担保したい品質の内容を減らしたわけではありません。
例えば、改善前にはテストケースAとテストケースBの2つあったとします。その際に、どうしてテストケースAとテストケースBの2つを行なっていたのか調査したところ、実は同じ内容を確認したかったということが分かりました。であれば、この2つのうち1つを削るという判断をしたということです。
もしも「テストケースBを削ってしまうと、確認したかったところの品質の担保ができなくなる」という声があれば、それはそもそも削る理由として考えていたテスト目的とは異なるテスト目的があるということなので、テストケースを残した方が良いです。それと同時に、残すべき理由となったテスト目的を明示化させた方が良いと考えています。
このように取捨選択していくことで、テストケースは減らしつつ、品質の担保はある程度残しています。
【質問10】観点を用いてパターンを出すという話がありましたが、例で提示いただいたデシジョンテーブルではあくまでデータパターンのように感じました。手順パターンについても手順作成フェーズ前に出し切っているのでしょうか？
今回示したデータパターンはあくまでも一例です。状態の遷移について考える必要があれば、状態遷移図から導き出した状態遷移表を書いて、状態遷移のパターンも出します。
なお、質問していただいている「手順パターン」というものが何か分かりませんでした。もしも質問者が「手順パターン」なるものを普段の業務で作成しているのであれば、「我々のチームでは作成していません」というのが回答となります。
【質問11】開発は1スプリントで済むものの、それに対するテストは1スプリントで済まないような PBI あるいはフィーチャーが考えられます。そのようなテストについて優先度の議論がありましたら聞いてみたいです。
今回の質問の際の優先度の議論については、ケースバイケースのため、ここで簡潔に表現することは難しいです。ですが、ポイントとしては、その開発チケットが完了することで生み出したい価値は何かを考え、その中でも大切な価値は最低限テストする考え方を持つことだと思っています。
また、優先度の議論ではないですが、他にもいくつか対処方法があります。
- feature toggleの考え方を用いて、ソース上は存在しているがお客様の中には機能を表示させない仕組みを開発にお願いする
- （あまりこの方法を取りませんが）開発者にもテストを協力してもらう
- （あまりこの方法を取りませんが）最低限確認すべきテストだけは実施し、次のスプリントで残りの部分のテストを行う
【質問12】テストパターンの優先度の高い低いは何を基準にしていますか？
いくつかの視点を複合して考えています。
- 業務での頻度が高いかどうか
- 同じ箇所で過去に不具合が発生しているかどうか
- 網羅基準Aは満たすが網羅基準Bは満たさない集まりのものを優先度中以上、優先度中以上のテストケースに加えて網羅基準Aも網羅基準Bも満たすものを優先度低
このような視点を持って、開発者やカスタマーサクセスチームの担当者にも意見を伺いながら優先度を付けています。
【質問13】テストの優先度はどうつけているのでしょうか？先程の表だと表の中で優先度をつけているように見えたのですが、スプリント内を俯瞰したうえでの優先度付けなどされているのでしょうか？
現状では、チケットごとの優先度とチケット内の優先度は作成していますが、スプリント内全体を俯瞰した明確な優先度付けはしていません。
【質問14】大きなバグが発覚したときに、次のスプリント計画が完全に崩壊しそうなんですが、 そういう事はなかったんですか？
現状ではそのようなことが発生したことはありません。
まず前提として、テスト設計フェーズでも（テストを実施する前からでも）バグを発見することが多いです。特に、大きなバグ・影響度が高いバグはテスト設計フェーズで発見することがほとんどです。なので、次のスプリントのPlanningが始まる前に見つけることになるので、次のスプリントが崩壊することはまずありません。
【質問15】テスト仕様書に使用しているツールを教えて下さい。
テスト仕様書はGoogleスプレッドシートを用いています。
【質問16】QAメンバーが実施するテストと、開発者が実施するテストをどう区分けしていますか？
データの組み合わせや状態遷移を踏まえたテストはQAメンバーが実施することが多いです。
また、システムテストレベルや受け入れテストレベルのようなテストはQAメンバーが実施します。そのために、最近ではカスタマーサクセスチームの担当者やシステムの社内利用者と連携して、どういった業務が発生しているかを調査した上で、その業務を遂行するためのテストを考えて実施する取り組みも行なっています。
【質問17】開発者とともにお客様の価値を実現するといった、テスト目的などの点はどのように、テスト担当者と開発者の間で認識をあわせておられるのでしょうか。
特に大きなFeatureに関しては、テスト観点出しで出てきた観点を開発者と共有して、開発チームでできる部分とQAチームで行う部分についてミーティングで話し合います。
【質問18】アジャイルで開発されているので、アジャイルテストの4象限を意識したテスト設計をされていたりするのでしょうか。
アジャイルテストの4象限4の把握・理解はしていますが、現状ではそこまで意識していません。
そもそも、アジャイルテストの4象限は決まり切ったものではなく、4つの空欄になっている象限に対して、自分たちのチームの場合はどんなテスト活動が当てはまるのか考えていくことが重要です。もっとQAチームと開発チームが近づいていく将来には、我々にとってのアジャイルテストの4象限は何か話し合う機会が設けられるかもしれません。
【質問19】設計レビューは全員とのことでしたが、レビュー工数が多くなり、逆に設計に支障をきたしたりしませんでしたか？QAチームが10名など多くなると設計レビューも人数制限したほうが良いですか？
発表中にもお伝えしましたが、レビュー工数はどんどん減っていくので、日常的に支障をきたすことは現状ありません。しかし、テスト設計の量が多くなる時や休暇が重なって工数が足りるか怪しい時は、全員ではなく、テスト設計が得意な人とまだこれからの人でペアを組んでテスト設計レビューをする取り組みも始めています。
【質問20】レビューする際、開発機能への理解度の差でレビューの質が変わってしまったりしないでしょうか？理解度の低いメンバーがレビューで活躍するためにどんな取り組みをされているでしょうか？
レビューというと、「指摘しなければ」という思いを持ってしまうかもしれません。しかし、そんなことを考えなくてもよいと個人的には思っています。
開発機能への理解がまだまだの人であっても、テスト設計の作成者が話した内容に対して「ちょっと意味が分からなかった」と表明するようにお願いしています。この表明はレビューとして価値があると伝えています。分かりづらいテスト設計の成果物は、そもそも成果物の作成者が思考を整理できていない可能性が高いので、他の人の「分からない」という発言は、思考を整理するきっかけに繋がります。
【質問21】テスト設計のレビュワーはQAチームのメンバーだけでやるのでしょうか？自分の場合はPOや開発チームがレビュワーになることが多いので気になりました。
QAチームのメンバーだけでなく、開発チームがレビュアーとなる場面も出てきています。（全てのレビューに入ってもらっているわけではありません）
業務知識などのドメイン面や実装を踏まえた面についてはPOや開発チームもレビュアーになる方が良いと思います。一方で、QAチームのメンバーがいることで、テスト技術を用いたテストパターンの削り方のレビューをすることができます。
【質問22】レビューの手法はどのようなタイプでしょうか？
質問者の意図として、JSTQB5に記載の「レビュータイプ」について聞いているのであれば、ペアレビューやテクニカルレビューに近い方法を用いています。レビュー技法」について聞いているのであれば、パースペクティブベースレビューが回答になります。
おわりに
今回はテスト設計改善について紹介していきました。発表では軽くしか紹介できなかったテスト設計の方法や、テストパターンの削減方法についての質問が多くあったように感じました。具体的なやり方については今後のD3QAで発表できればと思います。
なお、今回の発表内容および質問回答を見ていただければ分かる通り、QA基盤推進室には「テストの考え方を用いて開発と協働できるQA」が集まっています。
本記事を読んで少しでも興味を持った方がいましたら、ぜひカジュアル面談をして、お互いにQAについての考え方を共有できればと思います。
皆様のご応募をお待ちしております！
