テストプロセスを詳細化した話 - レビュー・テスト分析

以前、シフトレフトのために静的テスト、動的テストの2つのアプローチからどんなアクションを取れるかを記事にしました。

上記記事で書いたように、以前までのwith QAチームではテスト設計以降の作業を重視せざるをえず、上流工程でのテスト活動を明文化できていませんでした。しかし、メンバーの増強とユニット制への体制移行により、より上流工程から積極的にQAが関わっていけるようになりました。

その中でQAとして何ができるとよいのかを考えた結果、より積極的にテスト活動が行えるようテストプロセスを詳細化することにしました。具体的にはwith QAチームでは新たにレビューとテスト分析をテストプロセスとして明示することになりました。¹

今回は、このレビューとテスト分析を中心に、実際に何が変わったのかを書いていきます。

前提の確認

本題に入る前に、レビューとテスト分析とは何かという確認から行います。

「レビューってなに？」という方はそう多くないかと思います。これは一般的なものとしての「誰かの成果物を、他の人がチェックし評価する作業」のことをイメージしてもらえれば大丈夫です。

そして、この記事でいうレビューはQAが行うものですので、より限定的に「仕様書などを読み込み、考慮漏れがないかをチェックし早期から欠陥の作り込みを防ぐ活動」を指しています。

一方で「テスト分析」という活動については、ご存じない方も少なくないかと思われます。JSTQB Foundation Levelのシラバスでは、次のように説明されています。

テスト分析では、テスト可能なフィーチャーを識別し、テスト条件を決めるためにテストベースを分析する。言い換えると、テスト分析では計測可能なカバレッジ基準から見た「何をテストするか」を決定する。

後半部分の表現が分かりやすいですね。テスト分析においては「何をテストするのか」を決定します。そしてその後、テスト設計の工程で「どうテストするのか」を決定する、という流れです。

ここでお断りしておきたいのですが、これまでのwith QAチームではレビューやテスト分析をやっていなかった、というわけではありません。仕様が共有されたタイミングでレビューは行っていましたし、「なにをテストするのか」を決めなければテスト設計もできないので、テスト分析も必然的に行われていました。

しかし、テスト分析は工程として分けず、テスト設計に含める形で行っていましたし、レビューもそれぞれが経験的にフィードバックを返していたため、いつどうやってレビューやテスト分析をやっていたのかがブラックボックスになっていました。

つまり、やっていなかったことを新しくやるようにしたというよりは、これまでやっていたことに対して「いつ、何を目的に、どういった作業をするのか」の定義を改めて行ったのです。テストプロセスを詳細化した/テストプロセスとして明示したというのはそのような意味です。²

それでは、具体的にどんなことをやったのかを説明していきます。

レビュー - ガイドラインと観点リストの作成

まずレビューに関しては、

• レビューの目的
• レビューの対象
• レビューの方法

の3つをチームで話しながら確認し、これらを「レビューのためのガイドライン」としてドキュメント化しました。

例えば、レビューの目的は以下のように記してみています。

• 施策の内容について理解する
  • レビューを通して疑問点を洗い出す
  • 疑問点をチームに共有することで、自分やチームの仕様理解を深める
• 早いタイミングで仕様の課題を発見する
  • レビューを通して仕様書に潜む課題を発見する
  • 課題をチームに共有することで、欠陥の作りこみを防ぐ
• テスト対象を明確にする
  • 仕様書を読み込むことで「何をテストすべきか」を理解する
  • 理解した内容を書き出してチームに共有することで、テスト内容を正確にする
    • 「何をテストすべきか」の漏れを防ぐ
    • 「何をテストしないか」を決める

レビュー対象は、施策概要や仕様書など、開発の中で使われるドキュメント全般です。一般的なものなのでわざわざ明言しなくてもよいと思いつつ、これらの中にはレビュー会が開かれないものもあったりします。レビュー会が開かれなかったとしても、QAは自主的にこれらをレビューしていく必要がある……といったことを明確にするために、あえてレビュー対象も明記しました。

そしてレビュー方法としては、ガイドラインとは別にレビュー観点リストを作成し、それを使うことにしています。

レビュー観点リストとは、一般的にどういった観点でレビューを行うか、といった抽象的な観点と、「どういう観点でレビューを行っている？」というのを各メンバーにヒアリングした結果としての具体的な観点とをかけ合わせて整理したものです。

レビュー時にこのリストをガイドとして参照し、記載されていない重要な観点に気が付いたら適宜リストに追加する形で使うことを想定しています。

テスト分析 - 成果物のフォーマットを定義

つぎにテスト分析について。こちらでは、テスト分析の工程で成果物を出すことに決めました。³

これまでのテストプロセスでは、テスト設計書が完成するまでQAの成果物は何もない状態でした。あるいは確認事項があればメモを作って共有していたかもしれませんが、毎回やっていたわけではありません。

レビューを行った事がある方は分かるかもしれませんが、テスト設計書は詳細すぎて全体像を掴みづらく、必要な項目が網羅できているのかをレビューしようと思うとかなり負荷が高くなります。QAであってもそう感じるので、これをQAではない人にレビューしてもらうとなると、なおさら大変だというのは想像に難くありません。

そのため、テスト内容を詳細化する前に中間成果物として共有することで、QA以外のメンバーも含まれているユニットにおいてレビューを行う際の負荷を軽くしつつ、早い段階で観点の漏れを見つけることが出来るようになる、というわけです。

プロセスの全体像と今後の課題

レビューとテスト分析を明示した上での、現在のテストプロセスの全体像はこのような感じです。⁴

こちらはwith QAのテストプロセスを、PFD（Process Flow Diagram）で書いてみたものです。

PFDをご存じない方もいらっしゃるかと思います。実のところ私も勉強中で、今回は練習がてら書いてみました。PFDを簡単に説明すると、業務におけるアクション（＝丸い図形）と成果物（＝四角い図形）を交互に繋げて表現し、業務プロセスをモデリングしようというものです。⁵

これまでは「施策概要」「仕様書」「デザイン仕様」「Slackや定例での会話」の4つのアウトプットがテスト設計という1つのアクションに流れ込んでいた形だったので、工程を追加したことでかなりバランスが良くなりました。

一方で、いくつかの課題も見えてきています。

レビューの課題

レビューにおける課題は、観点が肥大化してしまい、管理・把握のコストが上がるというものです。これは今時点で起こっている問題ではないのですが、真面目に観点を積み上げていくとその量が大変なことになるのは既に目に見えています。

この問題に対しては、妥当性のある構造化を行って整理していくということと、観点の中に重要度を定めて、どこから優先的に見ていく必要があるのかをすぐに理解できるようにすることで対処したいと考えています。

テスト分析の課題

テスト分析については2つ課題があります。

1つ目は粒度の問題で、テスト分析の段階でどこまで細かく作れば良いのか分からない……というもの。2つ目は、テスト分析をテスト設計と繋がりをもたない作業として行われることがあった、というものです。

実際は「テスト設計で行っていた作業の一部を切り出したもの」なので、やることが増えたわけではありません。しかしテスト分析で成果物を出す、ということの経験がないメンバーもいたため、そのイメージを共有しきれなかった結果「テスト設計とは別に新しくやることになった作業」と思わせてしまったところがあります。⁶

これは単に「テスト分析についての説明が不十分だった」と言えます。今後は「テスト分析とは何か？」という説明を改めて行っていく必要があるのと、粒度感の認識を揃えるためにも、モブテスト分析のようなことが出来たら良いなと思っています。

今後の展望

前期で行ったテストプロセスの改善についてはこんなところです。今後はこの新しいプロセスの精度を上げていくことを目指せたらと思っています。

加えて「生成AIを補助的に活用できないか」というアイデアも出ており、QAチームでChatGPTのPOCを行うことになりました。設計で用いるにはまだまだ不安なAIも、レビューやテスト分析では活用できそうな予感があり、とてもワクワクしています。

そして今回はテスト中心のプロセス改善を行ったわけですが、次は開発プロセス全体の改善を行うことを考えています。それにあたっても勉強中のPFDを活用したく、まずは開発プロセス全体をPFDで整理してみようと思っています。

やることが多く大変ですが、まだまだ伸びしろがあるんだとポジティブに捉えて、改善を進めていけたらと思います。

1. 「レビュー」「テスト分析」という2つの活動は、前回の記事で書いた「静的テストのアプローチ」「動的テストのアプローチ」そのものであり、完全に地続きの記事となっています。 ↩

2. テストプロセスを定義して、より良いテスト活動にしよう！ という考え方はブロッコリーさんのスライドが大変参考になります（テストプロセスを用いて、テストケース作成の思考を整理しよう） ↩

3. 「項目1」「項目2」「項目3」という項目の作り方はwithで使用しているテスト設計書のフォーマットに揃える形で書いています。これは問題のある方法として、QAコミュニティでたびたび批判的に語られてきたものです（「固定3レイヤー法」のページを参照のこと）。自分もこの項目名の問題については重々承知していますが、ここにメスを入れると大がかりな手術になってしまうので、今回はスコープから外し、そのまま使っています。 ↩

4. ここでPFD化したテストプロセスは「ユニットでの施策をテストする際のプロセス」です。実際は他にも「ユニット外施策でのテストプロセス」や「リグレッションテストのプロセス」のような異なるパターンがあります。今回はユニット制に体制変更したことをきっかけしたプロセス改善なので、ユニットでのテストプロセス改善にフォーカスしています。 ↩

5. PFDについての詳細は、考案者の清水吉男さんの「PFD(Process Flow Diagram)の書き方」という資料をご覧ください。当記事で「アクション」と呼んでいるものは、本家では「プロセス」と呼ばれています。この呼び変えはナレッジワークでQAエンジニアをされているtettanさん（@TetsuayaKouno）に教わりました。PFDはQAに限らず活用できるフレームワークですが、QAがPFDを活用している例としてはマネーフォワードのこちらの記事が参考になります。 ↩

6. 今回のプロセス改善は自分が主導したわけですが、テスト分析に関しては、その成果物をどのように出せばよいのかというところも含めて、自分もゼロから勉強しました。その際にはゆもつよメソッドを大いに参考にしました。とはいえ、ゆもつよメソッドの全体像からメンバーに理解してもらうのは負担が大きいだろうと判断し、ゆもつよメソッドとは切り離す形でメンバーにテスト分析をお願いしています。一方で、ゆもつよメソッド抜きにテスト分析を説明するのは自分にとって難しく、結果として説明不十分なところが出てきてしまった……という感じです。特に項目名を、当初は「機能項目」「テストカテゴリ」「仕様項目」としていたのですが、これが分からないだろうと注釈3で記載した項目名に揃えたのですが、そうするとやはりというか、今度は粒度を揃えるところで課題が出てしまいました。 ↩