2021年4月23日 / 最終更新日時 : 2021年4月23日 user 事例・ソリューション

セッションベースよる探索的テストの力

ソフトウェアテストの分野は過去数十年の間に大きく変化しましたが、少なくともひとつ、変わらないことがあります。それは、テスターが探索的テストを引き続きおこなうということです。
探索的テストは、テスト担当者の創造性や経験を活用するための強力なアプローチです。これは、学習、テスト設計、実行を同時におこなうものです。

歴史的に見ても、開発チームはさまざまなツールや戦略を用いて、いくつかの方法で探索的テストをおこなってきました。しかし、テスト担当者が構造化されていない方法で製品を探索すると、このプロセスが自動テストや手動テストを含むテスト作業全体にどのように適合するかを理解するための具体的な情報を収集することが困難になる場合があります。
構造化されていないテストでは、特に開発チームがすでに強固なテストプロセスと戦略を持っている場合、探索的なアプローチは役に立たないという誤解を招く可能性があります。

このような場合には、セッションベースの探索的テスト（SBET）が役立ちます。

SBETとは？

SBETでは、特定のモジュールや機能、シナリオに焦点を当てた、通常45分から90分程度のタイムボックス型の中断のないテストセッションを使用します。セッション中、テスターはテストに関するさまざまな情報を「チャータードキュメント」と呼ばれるドキュメントに記録します。

これは、セッションの目標、使用したリソース、タスクの内訳と各タスクの実行に要した時間、テストのアイデアや観察に加えて有益な情報を含むメモ、セッション中に発見された問題、スクリーンショットなど、セッションに関するすべての詳細が記載されたドキュメントです。

このドキュメントがあれば、誰もがセッションの詳細と作業時間を知ることができます。このドキュメントは、ストーリーや、テストの成果物を保管するリポジトリに添付することができます。

SBETはどのような場合に使用すべきですか？

SBETは、エッジケースをカバーし、既存のテスト作業を補完するために、さまざまなシナリオで使用することができます。テストプロセスを持たないスタートアップ企業では、製品について学び、ユーザーストーリーをテストし、セッションで得たドキュメントを使ってスクリプト化したテストケースを作成し、機能を自動化するためにSBETを始めることができます。

テストプロセスを持っている中堅・大企業では、開発プロセスのさまざまな段階でSBETを利用することができ、リスクの高い分野のテストや、自動化が難しい機能の評価などに利用することができます。また、既に実施している回帰テストと並行して使用することも可能です。

製品を早期リリースするために、開発チームはシステムに関する迅速なフィードバックを求めています。そのためには、QAにビルドを提出する前にSBETを使用して、より多くのテストカバレッジを得て、人々が思いつかないようなエッジケースをカバーしたり、機能を本番に投入する前にユーザー受け入れテストをおこなう方法があります

SBETは自動化の取り組みをどのようにサポートしますか？

SBETは、さまざまなアプリケーションの機能や、複数の機能を比較して、どの機能がリスクが高いのかを知るための優れた方法です。これに基づき、開発チームは自動化する機能の優先付けをおこなうことができ、自動化する・しないかについてもより良いアイデアを得ることができます。また、自動化すべきテストケースの情報を収集するのにも役立ちます。なぜなら、SBETセッション中のすべての作業がドキュメント化され、今後の参考になるからです。

SBETセッションの詳細をドキュメント化したり、記録されたドキュメントを直接テストケースにエクスポートできるさまざまなツールがあります。これらのツールは、新人や経験の浅いテスターが、経験豊富なテスターとペアを組んで、アプリケーションについて学びながら、同時にテストをおこなうための強力なアプローチとなります。

SBETは、スクリプトによるテストケースの実行に代わるものではなく、補完的に実行されるものです。SBETは、テスターが創造性と経験を発揮しながら、製品に関する情報をより多く得られるようにするためのアプローチです。その結果、ステークホルダーは十分な情報に基づいた意思決定をおこなうことができ、テストチームは作業の優先順位を高めることができます。