究極のソフトウェアテスト計画チェックリスト

この記事はMatthew Heusserによるゲスト投稿です。

1つの見方として、テスト計画は管理されるリスクの集合であるとみなすことができます。ここで紹介するチェックリストは、どんなリスクがあり、どのように対処するか、何を対象外とするかについてのアイデアを提供します。

おそらく最も有効なアプローチは、チェックリストを確認してからテスト計画を作成し、その後チェックリストに戻り、こちらの究極のテスト計画スプレッドシートを使用して、チェックリストの要素がはい(Y)、完了、いいえ(N)、対象外(O)、該当しない(I)のどれであるかを判断することでしょう。

網羅的なリストは膨大になりすぎるおそれがあるため、私たちは、ある程度のユーザーにとってある程度のケースをカバーするのに十分なチェックリストを作成することをねらいとしました。以下で紹介するリストは、何十年という経験を持つエキスパートのレビューを基にバランスを考慮しています。

このチェックリストを1、2回使ってみると、たとえばユーザビリティやセキュリティなどの特定の要素がいつも対象外になること、あるいはよく利用されるテスト設計アプローチがあることなどに気づくでしょう。このリストの良い点は、カスタマイズ可能なことです。自由に独自のテンプレートを作成して行を追加または削除してください。

テスト設計時に考慮するべきアプローチ
計画
機能以外のテスト
最後に、放置したものを放置しない
関連する製品
- テスト管理ツール TestRail
  - ■ TestRailの特長 ■

テスト設計時に考慮するべきアプローチ

機能リスト: 機能リストを作成し、機能をテストケースにします。機能リストはトレーサビリティマトリクスと呼ばれることもあり、カバレッジの抜けを明らかにできるほか、もう作業する必要がない機能を発見できる場合もあります。

ユーザージャーニーマップ: 機能を列挙するのではなく、チェックインからチェックアウトに至るユーザーの行動フロー全体を考慮します。これを表す一般的なE-コマース用語の1つが「購入に至るパス(path to purchase)」です。機能がどのユーザージャーニーにも現れない場合、特にログにもあまり現れない場合は、テストや今後の拡張の優先度を低くする根拠になる可能性があります。

ログマイニング: ログエントリを機能ごとに分類してソートし、利用頻度が高い機能を特定します。それらのコア機能のテスト設計に重点的に時間を配分します。

例外条件: 問題が発生した場合のためのテストです。たとえば、データベースがダウンする、ウェブサイトの性能が低下する、APIが長時間にわたって応答を返さないためにブラウザーがタイムアウトするといった問題が考えられます。クイックアタックはこのカテゴリと重なる部分があります。

SFDIPOT:「サンフランシスコディポ」と読みます。structure(構造)、function(機能)、data(データ)、interfaces(インターフェイス)、platform(プラットフォーム)、operations(操作)、time(時間)の頭文字を取ったものです。テスト計画の準備として、これらの要素をノードとしてリストアップし、要素に関連するリスクをサブノードとして作成することが考えられます。リストが完成したら、その時点でのテスト計画とリスクのリストを照合し、リスクがカバーされているかどうかを確認します。大規模なプログラムでは、大きな機能またはサブシステムごとにSFDIPOTを作成する場合もあります。

その他の経験則に基づくテスト戦略: SFDIPOTを定義したJames BachのHeuristic Test Strategy(冗談で「Heusseristic test strategy」と書かれることもあります)には、テストのミッション、製品のゴール、品質目標を理解するうえで考慮すべき事項が豊富に挙げられています。これを使用してまったく新しいテストアプローチを考案し、その後テスト計画を見直して、それらのアプローチが含まれているかどうかを確認します。

ドメインベーステスト: クイックアタックおよび例外条件はソフトウェアに関する知識を必要としないのに対して、ドメインアプローチはさまざまな潜在的条件を認識したうえで、意味のある条件に対して妥当で有効性の高いテストを判断します。ドメインテストでは、要件を注意深く分析する必要があります。デシジョンテーブルはドメインベーステストの一例です。簡単に言って、要件が「長文」であり、テストのアイデアが10以上になるような場合は、テスト計画を完成させる前の中間的なステップとして、視覚的に表現することを検討します。

デシジョンツリー: デシジョンツリーからテストケースを導き出すことができます。

RCRCRC: Karen Johnsonによる造語であり、recent(最近)、core(コア)、risky(高リスク)、configuration-sensitive(設定依存)、repaired(修正済み)、chronic(慢性的)の頭文字を取ったものです。このような要素を検討すると、再テスト、特に回帰テストで最優先すべき領域を特定できます。

計画

リスクと優先度リスク、影響度、優先度を重視することで、テスターは最重要部分を先にテストできるようになります。これは、プログラマーに重要な情報を提供し、現実にデリバリーを加速することにつながります。また、プロジェクトがスケジュール上のプレッシャーにさらされている場合、詳細な計画はジレンマも生み出します。テストのためにプロジェクトを遅らせるべきでしょうか、それともテストを未完了のままにするべきでしょうか? 計画に優先度が含まれていれば、より多くの情報に基づいて決定を下し、棚上げされるリスクを少なくできます。

構造: テスト計画は、どこで誰がテストを実施し、どのように作業を追跡するかを明確にする必要があります。作業が電子的なトラッキングツールで追跡され、メンバーが自律的に作業を分担しているなら、それでかまいません。それを文書化するだけです。チームが常に同じアプローチに従い、同じプロジェクトドキュメントを繰り返し使用しているなら、テスト計画では違いだけを明確にすればよいよう、チームの標準を作成することを検討します。構造には作業をどのように分割するかも含まれます。機能ごと、リスクごと、チャーターごと、ストーリーごと、スプレッドシートで、テストケース管理ツールで、またはその他の仕組みでといったことです。

人間の創造性: テスト計画には、テスターがどの程度の創造性を発揮するかを記載する必要があります。程度はテスターのスキルレベルおよび機能によってさまざまでしょう。たとえば、各機能を正確にテストするよう要求するが、概要レベルでユーザージャーニーを文書化し、大きなフローごとにテスターに2時間のテストの枠を割り当てるという計画もあり得ます。James Bachの探索テスト連続体 (許可を得て使用) はこのような程度の違いを視覚化しています:

レポート: どのように進捗や障害を提示するかによって、プロジェクトが停滞することもあれば、加速することもあります。最近のツールの中には、メンバーが作業を完了すると、自動的にWebページを更新してくれるものもあります。レポートの計画には、どのメトリクスをいつレポートするかも含まれます。

タイミング: 計画には、物事が「いつ」発生するかという側面も含まれます。たとえば、機能の開発時に行われるアクティビティもあれば、リリースの直前に行われるアクティビティもあり、「試運転」的なテストからシステム全体の詳細な回帰テストまで、あらゆるものが含まれる可能性があります。

ツールおよび自動化: どのリスクが自動化によってカバーされ、どのリスクが手動で計測されるでしょうか? こういった質問に答えるために必要な作業として、CI/CD、要員、リソース、時間的制約などの検討があり、どこにツールと自動化を配備するかを決定する際の参考にされる場合もあります。

他の役割との連携: 従来、開発者テストおよび単体テストはテスト計画に含まれていませんでしたが、最近のテストケース管理ツールはこれらを可視化することもできます。どのようにバグがレポートされ、処理され、受け渡されるか等は、テスト計画またはチームの標準に含まれているべきです。

機能以外のテスト

アクセシビリティ: デバイスの使用に支援を必要とするユーザーのための機能が計画から漏れていることがよくあります。テスト計画チェックリストがあれば、すべての画像に説明テキストがあるか、またキーボードだけでWebサイトを読み、利用できるかを確認するようリマインドするのに役立ちます。支援機能を追加することで、ソフトウェアの自動化とナビゲーションが容易になることもよくあります。

国際化およびローカリゼーション: ソフトウェアが複数の言語をサポートする必要がある場合、それもテストするべき対象です。英語のみであっても、名前を格納する機能があるなら、フランス語やスペイン語の文字に遭遇することもよくあるでしょう。これらのテストは5分で完了できます — テスト計画にリストアップされてさえいれば。

セキュリティ: コードスキャニング、脆弱性スキャニング、侵入テストは、現在のあらゆるWebサイトで考慮すべき3つのテストです。

パフォーマンスおよび負荷テスト: 最近のユーザーは、たとえほかに1000人のユーザーがソフトウェアを使用していても、2秒以内にページがロードされることを期待します。負荷が高いとソフトウェアが機能しないなら、負荷テストを「非機能」テストと考えることは困難です。

ユーザビリティ: すべての要件を満たしていても、使うのが苦痛であるため受け入れられなかったというソフトウェアに心当たりがある人は多いでしょう。テスターがそうしたフィードバックを積極的に提供するよう推奨されているなら、テスト計画で文書化するべきです。

最後に、放置したものを放置しない

既知の(そして未知の)未知の問題: 外部依存モジュールがデリバリーされない、規格が変わる、文書化されていないシステムがある等の問題に突然ぶつかる場合があります。これらのリスクが計画に記載されていれば、たとえ対処法は計画されていなくとも、少なくとも相談を始めることができます。

対象外: テスト計画がセキュリティ、ユーザビリティ、アクセシビリティ、さらには負荷テストまで「対象外」とみなすことはよくあります。計画に優先順位が含まれていない場合、欠陥が多発してプロジェクトが遅延したとき、スケジュールの圧迫にどう対処するかが計画の対象外である可能性があります。これらを計画で明確にすることで、マネジメント層は意図的にリスクを許容したり、リスクが他の方法で対処されることを確実にしたりできます。

究極のソフトウェアテスト計画チェックリストをチェックするのをお忘れなく。このリストは、リスクを識別し、適切にリスクに対処する方法を知り、最終的には、チェックリストの要素が「完了」、「未完了」、「対象外」、「該当しない」のいずれであるかを判断するのに役立ちます。

Matthew Heusser はプロジェクト管理、開発、著述、システム改善の知識を持ち、Excelon Development の Managing Director を務めています。そしてもちろん、ソフトウェアテストも行っています。

（この記事は、開発元Gurock社の Blog 「The Ultimate Software Test Planning Checklist」2022年2月8日の翻訳記事です。）