この記事はPeter G Walenによるゲスト投稿です。
多くの有名なテスターが、たいていのメトリクスプログラムに否定的な反応を示します。メトリクスの計測は意図したものを計測しないというのが彼らの主張です。人はマネージメント層が見たいと思う方向にメトリクスを近づけるよう行動を変えるものだと彼らは指摘します。数字だけを見て、他の情報を見ないでいると、現状を誤認することになりがちです。
それでも、開発マネージャーやリーダーは、プロジェクトで何が起きているかを高いレベルで把握する必要があります。マネージメント層とテストチームの双方に役立つメトリクスもあります。私の経験上、有用だったメトリクスをいくつか紹介します。
テストカバレッジ
テストカバレッジを把握するのは有用です。なぜなら、何がテスト済みで何がまだテストされていないかがわかるからです。このメトリクスは、テスト完了までにあとどれくらいかかるかという質問に答えるのに役立ちます。バグが発見されなかった理由を示す場合もあります。また、なぜテストに時間がかかっているのか、適切な対象をテストしているかを明らかにするのにも役立つ可能性があります。
総合的なアプローチを採用するのがよいでしょう。まず、計測が最も容易な場所から始めます。つまり、コードです。継続的インテグレーションシステムにコードカバレッジツールを追加すると、単体テストでどの程度コードがカバーされているかがわかります。それだけでは、それほど有用には思えないかもしれませんが、時間が経つにつれて傾向が見えてきます。単体テストカバレッジが急に減少した場合、もっと早い段階で設計によって製品から排除できたはずのバグにテスターが費やす時間が増加するという現象が見られるかもしれません。
あまりツールを使わずに手動で行うテストについても把握するとよいでしょう。その際、製品目録を作成すると役に立ちます。私たちは常に、ページ、機能、シナリオ、構成などの抽象概念によってソフトウェアを把握しています。それらのメトリクスを、変更と共有が容易な簡易的フォーマットで記録します。このカバレッジは、コードレベルのカバレッジを検討するのと同様の方法で検討できます。
テストカバレッジは、それだけでは、テストの品質や、重大な問題を発見する可能性が高いテストを設計できているかの指標にはなりません。ただ、会話を始めるべき場所を提供してくれます。テストカバレッジに関する会話の目的は、何が計画されているかを明らかにし、何がすでにカバーされ、何が不足しているのかを確認することにあります。
手戻り
手戻りは、何かが初回で適切に完成しなかった場合に発生します。手戻りを記録することは、テストの周囲にあり、テストに直接的な影響を与えるものに着目することです。
通常、バグが最初の形跡になります。たとえば、新しい変更がテストブランチにマージされたとします。詳細に見ていくと、いくつかの異なる条件下でページのサブミットが失敗することがわかります。その後、時間をかけてエラーを調査・収集し、バグをレポートし、修正がマージされてビルドされるのを待つ必要があります。できれば、2回目はうまくいってほしいものですが、そうならない場合もあります。
手戻りは、開発が始まる前にも起こることがあります。私が以前働いていたある企業では、変更に関する作業を始める前に3 Amigosミーティング（立場や役割の異なる複数のメンバーで開発する機能について議論する打ち合わせ）を行っていました。これは、どのような変更が求められているかを皆が確実に理解し、これから構築する機能が適切かどうかを判断する最後の機会を作るために行われていました。月に何度か、私たちはカードを渡され、議論を始めました。最終的に、変更がすでに作業中の機能と矛盾していたり、明確ではない点があって開始できなかったりすることがありました。そのカードは製品管理作業キューに戻され、レビューを受けて明確化されます。そうでなければ、開発チームは間違ったものに時間をかけていたでしょうから、これはよいことです。しかし、これも手戻りではあります。
通常、手戻りを見つけるのはテスターですが、手戻りは開発環境に関しても示唆的な情報を与えてくれます。ひんぱんに手戻りが発生する場合、通常は、チームに適切なスキルセットを持ったメンバーがいないか、時間の制約が厳しすぎて、製品を「より早く」構築するために他の側面が犠牲にされていることを意味します。
手戻りのたびにスケジュールが狂い、連鎖的に次の作業に影響を与えます。手戻りは予算にも影響を与えます。手戻りは、当初の計画より多くの人間が、より長い時間働いていることを意味するからです。
手戻りの記録を始める最も簡単な方法は、フローの上流に戻されたバグやカードを計測することです。重要なのは、バグをカウントすること、何かをテストするのにかかった時間を見ることが目的ではないということです。意図するところは、環境の何が多数のバグや開始できない作業の原因になっているかを知ることです。それによって、スキルを開発したり、プロジェクトの制約を取り除いたりすることで、どのように状況を改善できるかがわかります。
レグレッションの問題
レグレッションテストの最中に見つかった問題をカウントし、計測することも、手戻りを計測する方法の1つです。私の経験では、このメトリクスは、製品を受入テストまたは運用環境にリリースする準備がどの程度整っているかを評価する際に役立ちます。
レグレッションバグを評価するとわかるのは、テストチームが何をしているかということよりは、開発プラクティスや環境に関することです。テストやソフトウェア品質に関するメトリクスの多くと同様に、レグレッションバグは開発手法やプラクティスの遅行指標です。以前に発見され、修正され、テストが済んだバグが、レグレッションテストによって再び見つかった場合、問題を指し示している可能性があります。
主要なテストが行われるのとは別の場所でレグレッションテストを行うと、開発プロセスに加えてデプロイメントプロセスの有効性を測る手段にもなります。レグレッションの問題は、製品を運用環境にリリースする前に対処し、レビューする必要がある、構成やデータ構造の問題、その他の環境の違いを警告しています。残念ながら、そういった問題は、運用にリリースする前に解決するべき問題の中でも、最もコストがかかる部類のものです。
計測が行動を変える
人はメトリクスを「正しい方へ」動かそうとして行動を変えるものです。これは意図的に行われる場合もあれば、無意識の場合もあります (Goodhart の法則)。参考にするメトリクスは、特定の問題を理解する助けにならなければなりません。メトリクスを情報ソースとして利用し、パフォーマンスや行動の期待値としては利用しないようにすると、緊張がやわらげられます。メトリクスとその目的を伝えましょう。
最も多く問題を発見したメンバーや、担当したコードのバグが最も少なかった開発者に報奨を与えたくなる誘惑にかられることもあるでしょう。私の経験では、通常、それは益よりは害が多く、逆効果です。たいてい、熟練した開発者は最も複雑で困難なタスクを引き受けるので、問題が発見される可能性が高くなります。優れたテスターほど、時間をかけてソフトウェアやシステム全体の動作を深く掘り下げます。そういったテスターは、アプリケーションをざっと触ってささいな問題を見つけるようなテスターに比べれば、少ないバグしか発見しないでしょう。優れたテスターは、ソフトウェアの動作と、ソフトウェアを使用する顧客のエクスペリエンスに影響を与えるような問題を発見します。
まずは、チームや組織、あるいは顧客に影響を与えるような問題に取り組みましょう。そういった問題に関連するメトリクスを探しましょう。目的となぜそれが重要なのかを皆に知らせましょう。メトリクス自体がよい行動を促すようにしましょう。
Peter G. Walenは、ソフトウェア開発、テスト、アジャイルプラクティスで25年以上の経験を持っています。ソフトウェアがどのように動作し、他のソフトウェアと連携するか、またソフトウェアを利用するユーザーをチームが理解できるよう支援に尽くしています。Agile Alliance、Scrum Alliance、American Society for Quality (ASQ)のメンバーであり、ソフトウェアミートアップに熱心に参加し、カンファレンスでもたびたび講演しています。
（この記事は、開発元Gurock社の Blog 「What Metrics Should You Be Using?」2021年9月8日の翻訳記事です。）
