TestDesignDoc：テスト分析・テスト設計に関する新たな試み
ナレッジワーク QAエンジニアの綿貫(@gun_chari)です。
以前「ナレッジワークQAのテスト設計プロセス」という記事でナレッジワークQAグループにおけるマインドマップを活用したテスト設計プロセスを紹介しました。
それから今まで、以前紹介したテスト分析・テスト設計のやり方をベースに試行錯誤を繰り返しながら、改善を進めてきました。本ブログでは、その試行錯誤の結果見えてきた課題を概観し、その課題解決の取り組みとして、TestDesignDocというテスト分析・テスト設計の成果物について紹介したいと思います。
1. 改善前のテストプロセス
まず、テストプロセスの前提となるナレッジワークの開発プロセスを概説し、その後に改善前のテストプロセスを紹介します。
1.1 スプリントサイクルとその中でのテスト活動
スプリントサイクルとその中におけるテストプロセスを以下に図示します。
ナレッジワークの開発では、2週間1スプリントを採用しています。QAエンジニアは基本的に、スプリント後半の1週間で、当該スプリントのスコープのエピックに対するテスト分析・テスト設計を行い、次のスプリントの前半の1週間でテストを実行するようなサイクルになります。このように1週間でテスト分析・テスト設計を行い、テスト実行ができるような段取りを整えることは、時間的な制約もあり非常に Agility が求められる活動になります。
1.2 改善前のテストプロセス
1.1のテスト活動において、我々が採用していた改善前のテストプロセスを図示します。
※minispec、DesignDoc について、詳しくは「ナレッジワークの開発体制」をご覧ください。
この図が示すように、テスト分析からテスト実行までマインドマップ形式のドキュメントを作成し、管理してきました。また、この図の開発成果物のスコープは、スプリントが対象としているひとつのエピックになります。
テスト分析・テスト設計では、マインドマップ形式でテスト観点を洗い出し、そのままテストケースとして使えるように成形していました。そして、テスト実装でテストデータを定義して反映し、テスト実行でテスト結果を記入していました。
2. 課題と解決策
このように、テストプロセスのすべてのアクティビティが一つの成果物で完結することで Agility のあるテスト活動を進められていましたが、次に示す2つの課題がありました。
課題1：自由度の過度な高さ
すべてのアクティビティの成果物はマインドマップ形式で作成していましたが、マインドマップの表現方法には特に細かいルールを設けずに、各QAメンバーが自身の創意工夫によって進めていました。しかしながら、特にテスト分析・テスト設計では表現の自由度が過度に高いために、マインドマップの構造はメンバーによってまちまちであり、またブランチには開発成果物から抽出された用語がテスト観点として記載されるもののその捉え方には無視できないほど大きいばらつきがあるという状況となっていました。結果として、第三者のレビューでは、丁寧な説明が必要となり、キャッチアップ・コミュニケーションの無駄なコストが発生したり、QAメンバーの意図が正確に伝わっていないことがありました。
課題2：成果物管理のばらつき
ナレッジワークでは、自社プロダクトのセールスイネーブルメントクラウド「ナレッジワーク」をドッグフーディング的に社内でも活用しており、エンジニア組織内でも日々利用しています。minispec（プロダクトの仕様書）、DesignDoc（技術的な設計文書）といった開発に必要なドキュメントの多くはGoogle ドキュメントで作成し「ナレッジワーク」に格納していますが、マインドマップツールは「ナレッジワーク」と連携していないため、別の方法で管理していました。その結果、ひとつのエピックに対する開発・テストの成果物が一箇所に集約されておらず、検索性が悪くなっていました。
以上の2つの課題を解決するために、テスト分析・テスト設計のための成果物としてTestDesignDocという形式を検討し、それと合わせてテストプロセスを改善しました。
まず、TestDesignDocという形式の取り組みを始めた背景として、ナレッジワークでは、minispecを作成してその後コーディングの前にDesignDocという成果物をGoogle ドキュメントで作成しています。その流れに従い、テストでもテストケース作成の前にTestDesignDocというテスト分析やテスト設計の方針を記載するような成果物をGoogle ドキュメントで作成するアプローチを採用しました。
次の章では、TestDesignDocに形式として用意している項目を概説し、そのTestDesignDocという成果物を作成するアクティビティを含めた改善後のテストプロセスを紹介します。
3. TestDesignDocと改善後のテストプロセス
3.1. TestDesignDoc
TestDesignDocとは、Google ドキュメントで作成するテスト分析とテスト設計の成果物になります。TestDesignDocは、4つの大項目から構成されています。また、各項目には解説を用意して記載のガイドを行うようにしています。
(1) テストベース
TestDesignDocを作成するにあたり、インプットとした情報へのリンクを記載します。
例として、minispec、DesignDoc、UIデザインなどが挙げられます。また、必要に応じて仕様の問い合わせをしたSlack Threadのリンクも記載します。
(2) テスト対象の分析
開発成果物を参照しながらテスト対象を分析する過程で仕様の整理やテストスコープなどを記載します。また、「第三者に対象のエピックの仕様を説明するように記載する」と解説でガイドしています。解説でガイドすることにより、項目内に記載すべき内容の認識を揃えることが出来ます。
(3) テスト設計仕様
テスト方針、テスト観点などを記載します。テスト方針が定まらない場合は、テスト観点を列挙していく中でテスト方針を検討していくという方法でテスト分析とテスト設計の行き来しやすいのが、このTestDesignDocのメリットだと考えています。
また、この大項目の配下には「要注意観点」という補足情報を置いています。こちらは観点として漏れやすいものを記載しており、ドメイン知識やテスト設計スキル不足を補うための参考にするガイドとして用いています。
(4) テストケース（とテスト実行結果）
TestDesignDocをもとに別途スプレッドシートなどでテストケースを作成した場合は、そのリンクを記載します。エピックが小規模で、別の成果物としてテストケースを作成する必要がない場合には、この項目の配下にテストケースをリストアップして実行結果も記載しています。
これらの項目は、テスト分析・テスト設計のアクティビティに対するガイドの役割もあります。また、項目の配下には日本語でしっかり記述していくことによって、当初抱えていた自由度に関する課題に対して一定の解決ができたと考えています。また、TestDesignDocはGoogle ドキュメントで作成するため、「ナレッジワーク」に格納することができ、それぞれのエピック単位で開発・テストの成果物が集約できるようになりました。
上述した項目および各項目に対するガイドを記載した、TestDesignDocのテンプレートのキャプチャがこちらです。(2) テスト対象の分析までのキャプチャとなっていますが、TestDesignDocの外観が伝われば幸いです。
TestDesignDocの取り組みを導入するにあたり、テストプロセスも変更したため、以下で概説したいと思います。
3.2 改善後のテストプロセス
TestDesignDocによる改善後のテストプロセスを図示します。赤枠で囲んだところが変更した部分です。
今までは、テスト設計という大きなアクティビティで捉えていましたが、改善後では、TestDesignDocの(3) テスト設計仕様の項目を記載するアクティビティをテスト概要設計と捉え、その結果をもとにハイレベルテストケースを設計するアクティビティをテスト詳細設計と捉えるように変更しました。また、TestDesignDocの(2) テスト対象の分析の項目を記載するアクティビティをテスト分析と捉えています。
4. 気づきと今後の課題
TestDesignDocによる改善後のテストプロセスの運用を2023年9月から始めてみたところ、以下のような気づきと今後の課題を得ることができました。
気づき1
TestDesignDocによって「何をテストするか」を示すことで、エンジニアがテストケースをレビューする際にも理解してもらいやすくなることが分かりました。
気づき2
文書ベースで「何をテストするか」を考えることで、自身の仕様に対する理解の曖昧さやテストケースに落とし込む際の考慮不足、仕様自体の曖昧さや矛盾などに気づく機会が、以前よりも早く訪れるようになったと感じています。
今後の課題1
テスト分析・テスト設計の成果物をマインドマップ形式で作成していた際にできていた「思考の発散」が、TestDesignDocという形式に変更してからはできなくなっていないだろうか、という懸念があります。
今後の課題2
アウトプットの形式は揃ったものの、各項目に記載されるアウトプットの質は各QAメンバーに依存してしまうのでは、という懸念があります。
今後の課題1については、TestDesignDocの各項目の記載にあたり思考の発散が必要な場合には、マインドマップを含めたツール・方法などを適宜活用する。何を活用するかは各メンバーの自由だが、発散後の収束はTestDesignDocで行うことをルールとする。など、進め方を工夫することで解決できると考えています。
今後の課題2については、QAメンバー間でのペアテスト設計やテスト設計レビューの機会を通じた知見共有、「テスト設計仕様」項目配下の「要注意観点」のブラッシュアップなどを続けていくことで解決できると考えています。
5. おわりに
本記事では、はじめに改善前のテストプロセスを概観し、それに基づき我々が抱えていた課題を2つ示しました。そして、その課題解決の取り組みとして検討したTestDesignDocという成果物および改善後のテストプロセスを紹介しました。最後に、今回の取り組みによる気づきと今後の課題を示しました。TestDesignDocは、運用を続けながら今後もブラッシュアップしていこうと考えています。
ナレッジワークでは引き続きQAエンジニアや、その他職種の採用を積極的に行っております。ナレッジワークのQA Groupに少しでも興味を持っていただけましたら、ぜひカジュアルにお話しましょう！