テスト設計＞探索的テスト
ライフイズテックのサービス開発部でQAを担当しているotkyskです。
誕生日を迎え、心機一転１人QAで奮闘していきたいと考えています。
今回はテスト設計してのテスト実行と、テスト設計をしないでの探索的テスト、どちらが有効か？を個人的な見解ですが書いてみたいと考えました。
テスト設計の有効性
テスト設計は主に機能仕様書（ユーザーストーリー）に沿って、主に正常系のテストケースを作成していき、異常系を洗い出してとテスト対象のレベル、操作する内容とその期待値を明示化をしていく事が目的です。
この行為はテストを明示化出来るのでテスターが指示通り動けるという点と、開発がテストに合わせて実装できるという点がメリットとして挙げられます。
しかし、デメリットとしてはテスト設計工数が機能仕様書の規模によっては大小ある点は否めないです。また、テスト設計者とテスターが異なる場合は、テスターが理解できるようなテスト設計をしないと注意しなくてはなりません。主語、述語、対象、前提条件、期待値の明記、これらが必要になります。
ただ、テスト設計をする事で開発前に開発メンバーにインプットする事で、テストに合わせた実装をする事が可能であり、開発段階でのバグの埋め込みを防止する事が実現出来る事もあります。この手法は前回触れたTDDに近い手法とも考えられます。
探索的テストの有効性
探索的テストは機能仕様書（ユーザーストーリー）に沿って、そのドキュメントに書かれている内容を探索的になぞってテストし、違和感がある場合は仕様かバグかをヒアリングする事が目的です。
この行為はテスト設計が不要な点と、バグ出しを主に目的とした場合にバグを多量に加算する事ができる点がメリットとして挙げられます。
しかし、デメリットはテスト設計をしていない事で機能仕様書に埋もれている細かいバグを見落とす可能性がある点と、また、テストが開発よりも後になる事で後工程での負荷が高まる点は否めないです。
ライフイズテックのQAの取り組み
弊社では以下のような取り組みをしています。結論から言うと、"基本"、テスト設計ありきです。
弊社塾プロダクトでの取り組み
新規機能、エンハンス、バグFIXだろうと、エンジニアがテスト観点を洗い出し、QAがテストケースに落とし込み、ピアレビューを行い、FIXした後にテスターにテストケースを渡す。
テストケース消化後に余力があれば、探索的テストを行う。
弊社学校プロダクトでの取り組み
新規機能は以下のケースで対応する。
機能仕様書のボリューム、複雑度をPDとレビューし、テスト設計が必要と判断した場合はQAが機能仕様書からテストケースを落とし込み、ピアレビューを行い、FIXした後にエンジニア、テスターにテストケースを渡す。
テストケース消化後に余力があれば、探索的テストを行う。
機能仕様書のボリューム、複雑度をPDとレビューし、テスト設計が必要と判断しなかった場合は、機能仕様書に沿ってテスターが探索的テストを行う。
最後はリグレッションテストでフィニッシュ
テストケース、探索的テストを消化後、リリース前にリグレッションテストを行って、最終的にメインパスが通るかを検証しています。リグレッションテストの項目もテストケース化しています。これらをパスしてようやくリリースへと達します。
テスト設計はドキュメント文化な会社だと強みになる
何社か経験して、プロトタイプ、ドキュメント、コミュニケーションどれかでの仕様定義（中には両方存在しないでの難ありな仕様定義もありましたが）を受けてのテスト設計を経験してきましたが、コストを考えるとコミュニケーション＞ドキュメント＞プロトタイプと優位性が考えられますが、テストの使命はQCDを保つ事であると考えられるため、主観ではありますが、ドキュメントからのテスト設計がフィットしていると考えてます。
プロトタイプはコストが掛かる上に期待値が固定化されているのでテスト設計が有効的でなくなるかと考えられます。
コミュニケーションでは仕様を把握している人との齟齬が生じて的確なテスト設計ができなくなる上に細かい点を把握する点が人間の脳みそによりけりなので難しいと考えられます。
ドキュメントは今の時代であればリアルタイムでの指摘やフィードバックを行う事ができ（弊社ではNotionを使っている）、コスパも良くQA活動を行えているので改めて優位性は高いと考えられます。
ライフイズテックを知るイベント
ライフイズテック サービス開発部では、気軽にご参加いただけるカジュアルなイベントを実施しております。
イベントの開催予定は connpass のグループ にてご案内しておりますので、興味をお持ちいただけたましたら、ぜひ、ご参加いただけると嬉しいです！
この記事が気に入ったらサポートをしてみませんか？