この記事はCameron Lairdによるゲスト投稿です
今日の急速に進歩するテック業界では、品質は市場で製品を差別化するための鍵です。ソフトウェア開発ライフサイクル（SDLC)でテストが後付けするものと考えられている場合―あるいは単にSDLCの１つのステップと考えられている場合も―製品を十分にテストできず、QAはリリースの障害とみなされるでしょう。DevOps、継続的テスト、CI/CD、分散コラボレーション、分析に強い機能などのよりモダンなプラクティスへの移行に伴ってカルチャーを変えるにあたって、QAチームのリーダーであるあなたは主導的な役割を果たすことができます。組織には技術的な強化にもまして概念の変化が必要であり、QAにはその変化に影響を与える大きな力があります。
この記事では、QAカルチャーを変革し、SDLCにQAをより緊密に統合するための成功するアクションプランを３つ紹介します。
- チームのKPIをレビューし更新する
- 部門の既存のカルチャーを分析する
- 「青信号」への障害を取り除く
QAがSDLCを改善する力を持っていることをあなたほどよく知っている人間は、組織の中でほかにいません。あなたにとっては日常的な概念も、他の人にとっては未知の概念、あるいは驚きです。以下の３つの成功戦略を検討すれば、QAはリリースを妨げるだけではないことが他の人たちにも理解できるでしょう。
QAをSDLCに組み込むためにするべき３つのこと
以下の３つの項目は、チーム固有の状況に合わせて調整することもできますが、このまま採り入れるだけでも大きな進歩になるでしょう。
以下の項目は、どれもSMART ゴール、つまり具体的（specific）、計測可能（measurable）、達成可能（achievable）、現実的（realistic）、タイムリー（timely）な目標にすることができます。以下のKPIは、建前として計測するような教科書的な概念として挙げられているのではありません。肝心なのは、いくつかを選び、実践し、毎日アップデートを記録し、他のメンバーと話題にし、これらのKPIからわかることを日常的に体感する機会を与えることです。
1.チームのKPIをレビューし更新する
バグを数えることは必須です。レポートし続けましょう。そのうえで、可能なかぎりコスト、バリュー、リスクとして表現されたキーパフォーマンスインジケーター(KPI)を重視しましょう。「我々のチームのテスターは、先週、53件の欠陥を発見した」という言い方は、QAがコストセンターだという見方を補強します。同じ事実を「先週は、顧客にとってリスクの高い３つの致命的な欠陥を発見して解決することができた」、「欠陥検出までの平均期間を87日から11日に短縮した」、あるいはもっといいのは、「先週我々が発見したバグは、カスタマーサポートのコストに換算して33,420ドルの節約に相当する」と言い換えれば、QAは単にコストセンターではなく投資であるということが組織にとって理解しやすくなるでしょう。
世界中の組織で幅広いKPIが使用されています。手始めとして、以下のうち、自分の組織ではどれが計測可能で役に立つかを検討しましょう。
- 要件カバレッジ
- このKPIは、少なくとも1つのテストケースの対象になっている要件の割合を測定します。テストマネージャーは、すべての機能要件がテストケースに関連付けられていること、またその反対を確認します。このプラクティスは、すべての要件に十分な数のテストがあることを保証します。目標は、要件からテストケースへのマッピングを100%に保つことです。
- 作成されたテスト数
- このKPIは、一定の期間内に設計されたテストケースの数を測定します。作成されたテストをテストマネージャーまたは同僚がレビューすることもできます。そうすることで、テスト設計のアクティビティを分析するのに役立ちます。このKPIは、要件に対するテストケース数を計測するのにも役立ちます。設計されたテストケースを評価して、レグレッションテストスイートまたはアドホックテストスイートに入れるかどうかを決めることもできます。
- 欠陥検出漏れ率
- このKPIは、製品のユーザー受け入れテスト（UAT）の前にソフトウェアテスターがテストプロセスの効率性を分析することを可能にします。 テストチームによって発見されなかった欠陥がユーザーによって発見された場合、欠陥検出漏れまたはバグ検出漏れと呼ばれます。
- 欠陥検出漏れ率 = (UATで検出された欠陥数合計/ UATの前に検出された欠陥数合計) x 100
- モジュールごとの欠陥密度
- 欠陥密度は、特定の期間—運用または開発期間—にソフトウェアで見つかった欠陥の総数を把握するのに役立ちます。結果はモジュールの大きさで割り算され、それを見てソフトウェアのリリース準備ができているか、それとももっとテストが必要かを判断することができます。欠陥密度はコード1,000行（KLOC)あたりで計算されます。
- 欠陥密度 = 欠陥数/リリースまたはモジュールのサイズ
- 変更リスク分析
- このKPIは、定性的基準と定量的基準を組み合わせて変更に関するリスクレベルを評価することで、より高い生産性を実現するのに役立ちます。一貫性のある標準的なプロセスに従ってリスクを評価すると、変更の精度を高めることができます。
- 未解決の欠陥数
- このKPIは、欠陥トラッキングシステムに登録されたが、まだ解決されていない欠陥数を計測します。このメトリクスは、特定の時点で未解決の欠陥数を表わします。
- 未解決の重大な欠陥数
- このKPIは、アプリケーションに一度に存在する重大な欠陥数を制限内にとどめることを狙いとします。重大な欠陥数が制限を超えた場合、ただちにアクションが必要です。しかし、このメトリクスを使用する前に、重大な欠陥を正しく認識できるようテストチームをトレーニングする必要があります。
- 却下された欠陥率
- このKPIは、レポートされた欠陥の総数に対する却下された欠陥の割合を測定します。決められたしきい値より割合が高い場合、製品の意図された動作の記述または欠陥の定義に潜在的な問題があり、それを特定して対処する必要があります。つまり、ソフトウェアテスターのトレーニングや、要件の記述の改善が必要であることを意味する場合があります。
- (開発チームによって却下された欠陥の数 / レポートされた欠陥の総数) x 100.
- テストケースの品質
- 作成されたテストケースを評価し、定義された基準に従って採点します。このメトリクスの目的は、各テストフェーズでテストチームによって実施されたテストケースの効率性を把握し、作成されるすべてのテストで定義済みの基準に注意を払うことで、品質の高いテストケースシナリオを作成することです。
- 自動テストの割合
- このKPIは、テストスイート内のテストケース総数に対する自動化されたテストケースの割合を測定します。通常、割合が高いほど、ソフトウェアデリバリーストリームに入り込んだ重大で優先度の高い欠陥を捕捉できる可能性が高いことを意味します。
- 欠陥検出効率(DDE)
- 欠陥検出率とも呼ばれる欠陥検出効率は、ソフトウェアのテストフェーズで検出された欠陥総数の割合です。DDEの計算式は次のとおりです。
- DDE = (フェーズで検出された欠陥数 / 総欠陥数) x 100 %
- 欠陥解決時間
- このKPIは、ソフトウェアのバグを発見し、修正の検証および妥当性確認を行うのにかかった時間を計測します。このメトリクスは、解決時間を追跡するとともに、バグに対するテスターの責任およびオーナーシップを計測し、認定します。
なぜこの12個を計測するのでしょうか？これらは、計測可能で、効果の実績があり、部門の最も大きな課題に光を当てるのに十分な多様性があります。
KPIプログラムを始めようとしているところであれば、最初は小さく始めて、どのKPIが適しているかを学んでゆきましょう。特に以下の３つのKPIは、早期に追跡を開始するのに重要です。
- 要件カバレッジ: 一般的に、一部のテストが手動であっても、すべての製品要件が少なくとも１つの文書化されたテストに現れることを目指す、つまり100%の要件カバレッジを目標とするのが現実的です。
- 欠陥検出効率(DDE): DDEはリリース前に発見された欠陥数とリリース後に発見された欠陥数を比較します。QAがリリース前に48個の欠陥を発見し、顧客が新しい欠陥を2つレポートした場合、DDEは48 + 2に対する48の割合であり、96%です。DDEは、QA作業および製品リリースの両方の計画に役立ちます。
- 自動テストの割合: すべてのKPIは経過を追跡する必要がありますが、自動テストの割合は、絶対的なレベルというよりは、ほぼ相対的な比較の問題です。このメトリクスが逆行している場合、つまり自動テストの割合が製品の存続期間を通じて常に低下している場合、ただちに組織的注意を製品に向け、もっと継続的にテスト可能なモデルへと作り変える必要があることがわかります。
KPIポートフォリオを繰り返しレビューします。常に学ぶべき新たな洞察があり、行うべき調整があるでしょう。KPIを評価する際は、最善の決断を下す必要があります。たとえば、組織が慣れ親しんだレガシーKPIだけに頼ると、発見できることは限られます。いっぽう、あまりに多くの新規KPIを導入すると、組織が圧倒され、混乱が生じたり、得られたかもしれない利益を消し去るような拒絶を招くこともあるかもしれません。常に、適切に実施されたQAはより価値の高い製品をより早く作り出すのに役立つという点を補強するKPIを選ぶべきです。
KPI自体がビジネス投資です。上に挙げたものなど10個程度を計測し、どれが計測のコストが低いいっぽうで、他の部門にとって意味を持つか、アクションのよいガイドとなるか、モチベーションを与えるかを確認します。KPIが個人的なプラクティスにとどまり、あなたとあなたの上司しか知らない場合、成果は限定的です。いっぽう、チームや朝のスクラムミーティングが、選択した特定のKPIに関する会話から始まる場合、違いを生むのを実感できるでしょう。
2.QA部門の既存のカルチャーを分析する
QAディレクターにとって最も困難で最も重大な仕事は、成功するQAカルチャーを醸成することです。品質カルチャーの水準を上げたい、あるいは新たに品質カルチャーを確立したいと考えるなら、真っ先にやるべきことは、会社の価値観が明確に定義されているかを確認することです。会社がすでに持っている価値観を考えてみましょう―品質については触れられているでしょうか？その価値観はあなたが期待するものでしょうか？改良の余地はないでしょうか？
QA部門の従業員は、自動化可能なテストの自動化に熱心に取り組み、まだ自動化されていないテストを確実に実行するスキルに自信を持っているでしょうか？ミーティングの要点は、実際に実行され、完了されるアクションを決定することにあると理解しているでしょうか？同僚やQA以外のチームメンバーとスムーズにコミュニケーションをとる能力があるでしょうか？製品開発サイクルのどの時点であっても、毎日作業を先に進めるという心構えを持っているでしょうか？こういった意識を持っていない場合、どうやって教育すればよいでしょうか？あなたは、QAに関する自分のビジョンを伝え、メンバーがそれぞれのやるべきことを容易に理解できるようにしているでしょうか？やるべきことをやるために障壁を取り除き、チーム全体が一日一日の仕事を効果的に実行するのだという期待値を掲げているでしょうか？
適切なカルチャーがあれば、QAチームは主体性を持ち、SDLC全体に関与する方法を探すようになります。自部門の既存のカルチャーを分析し、求めるカルチャーに近づけるために何を決断するべきかを考えましょう。
3.「青信号」への障害を取り除く
あまりにも多くの組織がQAを共通の目標への妨げだと認識しています。QAは製品と顧客の間の障壁であるとか、QAが市場への投入期間を長引かせているといった見方があります。購入者にバリューを届けることを重視する部門が進路に立ちふさがるあらゆるものに対して懐疑的であるのは当然です。そうであれば、QAがソリューションの一部であることを証明できれば大きなチャンスになります。
製品開発の最後にだけ実施されるものとして扱われるなら、QAは障壁になる場合もあります。SDLCがQAを製品の完成間際だけに限定しているなら、QAは製品リリースのボトルネックになるだけでなく、QAが製品からかけ離れ、QAのスケジュールを立てたり見積もりをしたりするのに憶測を働かせなければならないでしょう。
QAを完全にSDLCに統合すると、製品開発の最初期から貢献できるようになります。初期段階で関与することで、決定のコストが最も小さく利益が最も大きいうちに、テストが容易かどうかやスケジュールへの影響を見通すことができます。開発または機能拡張の初期から「継続的QA」を適用すると、よくある、製品のリリース近くになってはじめて重大なありがたくない事実が判明するというリスクが低減されます。
「継続的QA」は単に継続的テストを実施することには留まりません。ほかにもさまざまな方法でさらに完全にQAをSDLCと一体化することができます。製品リリースプロセス自体のさまざまな段階でテストを設定し、SDLCの早い段階にQAを統合します。可能であれば、要件開発にも参加したり、マージリクエストのレビューで開発者とペアを組んだりすると、実際にテスト準備ができたコードに対して作業するより前にQAからインプットを提供できます。
そうすることで、開始時から未完成の製品が「青信号」、つまり関係するテストが成功する、またはそれに近い状態に保たれます。いくつか修正を行うだけで製品をいつでも青信号に持っていける状態にあれば、製品開発がずっと容易になります。開発終盤まで待ってから何百もの絡み合った問題を解決するよりも、1度に10個の小さな矛盾点を直すほうが簡単です。
製品が「青信号」の状態からスタートし、道を外れるたびに速やかに戻れるなら、開発に関わるすべてのメンバーの仕事がより明快になります。QAを完全にSDLCに統合することが、QAやそれに相当する組織にとっていいことだと主張しているのではありません。そうではなく、早期の統合がQA活動を最大限に活用することにつながり、製品に寄与し、他のあらゆるメンバーの負荷を軽減すると主張しているのです。
もしあなたの組織でQAがサイロ化されているなら、変化を起こすべき時です。適切に実施されたQAはより価値の高い製品をより早く作り出すのに役立つという点を補強するKPIを選ぶことでそれが可能になります。自部門の既存のカルチャーを分析し、求めるカルチャーに近づけるために何を決断するべきかを考え、「青信号」への障害を排除しましょう。この３つを実行し、QAをSDLCに組み込むことで、製品の品質が改善するでしょう。
Cameron Lairdは、賞を授けられたソフトウェア開発者で著述家です。Cameronは、Python Software Foundationの投票権を持つほか、いくつかの業界のサポートや標準化組織に参加しています。長くTexas Gulf Coastに住み、農場自動化アプリケーションがお気に入りです。
（この記事は、開発元Gurock社の Blog 「DevOps Testing Culture: How to Build Quality Throughout the SDLC」2022年6月15日の翻訳記事です。）
関連する製品
テスト管理ツール TestRail
テストケースの管理やテスト結果の記録、チームでの情報共有など、Excelを使ったテスト管理の業務に限界を感じていませんか？TestRailはシンプルで使いやすいUIを提供し、テストにかかるさまざまな管理コストの削減に貢献します。
■ TestRailの特長 ■
- テストにさまざまな情報を関連づけて一元管理
- Webブラウザー上でテストケースを簡単に入力や編集可能
- テスト実施の準備と結果の共有が容易
- 進捗や比較などのレポートを提供
- 要件 / 課題管理ツールやテスト自動化ツールと連携
日本国内では、テスト管理にExcelを使っていたお客さまからの乗り換えが多く、Web上で完結するテスト管理を実現されています。
TestRail でテスト管理のお悩みを解決しませんか？
テストの生産性向上をTestRailでお試しください
クラウドおよびオンプレミス、デモサイトでTestRailがお試しいただけます。
- TestRailクラウド（クラウドサービス）
- クラウドサービス環境でTestRailをお試しいただけます。
- TestRailサーバー（オンプレミス版）
- お客様のマシンにTestRailをインストールしてお試しいただけます。
- TestRailデモサイト
- インストールなどの設定なしにTestRailにサンプルデータが登録された環境にて操作をお試しいただけます。