ポイント解説|探索的テストはチャーターを決めて実施しよう
はじめに
こんにちは、SHIFT アジャイルサービス部のカル♪です。
現在アジャイルの現場で、プロジェクトマネージャ、キャプテン、QAリードを担当しており、若手育成のためテクニカル記事を書いています。
今回は探索的テストについて簡単にまとめていきます。
探索的テストはモンキーテストとは異なり、実施目的をはっきりと決めて、テストをおこないます。
目的を決めて実施しよう!
テスト観点を明確にしよう!
チャーターを決めて実行しよう!
こんな目的でやってみる
参考例
機能テストでの不具合検知数が想定よりも低かったため、探索的テストを実施し品質向上を図ります。
不具合検知率の高い機能に適用することで更なる品質向上を図ります。
不具合検知率は低いものの不具合があった際に影響が大きい機能において重点的にテストを実施します。
テスト観点
テストの「道しるべ」として、ある程度のテスト観点を例として共有します。
テスト観点の構成について
テスト観点の例を次に示します。
チャーターについて
探索的テストを実施する際に、目的をしっかり持ってどうやってテストをするか決めるものです。
チャーターの考え方
「(対象)を(資源)を使って探索し、(情報)を発見する」
「ない」ことを証明しない。必ず「ある」前提でチャーターを設ける
〇 Hogeアプリケーションのある機能を仕様書を使って探索し、バグを発見する
✖ Hogeアプリケーションのある機能を仕様書を使って探索し、バグが発生しないことを確認する
※探索して見つけるテストと言うことをお忘れなく!
チャーター見つけ方
「不安な部分はどこだ」と自分に問いかけて言語化する
テストケースでバグがいっぱい出ていた機能は?
テストの7原則「欠陥の偏在」
バグ修正が多かった機能は?
デグレ発見の目的
開発するとき苦戦していた機能は?
内部構造が複雑化しがち
修正に時間がかかっていた機能は?
あと開発からのコメントに苦労話が含まれているなど
不慣れなメンバーが対応していた機能は?
ブラックリスト方式は世間的に良しとされない
レビューしていれば大丈夫なことは多い
使用の勘違い、暗黙の了解部分がおかしくなっていたりなど
経験上やっぱりバグは出る
そのプロダクト特有の特性は?
ブラウザ固定など
ユーザーがよく使う機能とは?
まとめ
次回は、「セッションベースド探索的テスト」について解説していこうと思います 。 探索的テストについては、次のとおり解説していく予定です。
ポイント解説|探索的テストはチャーターを決めて実施しよう(今回)
ポイント解説|探索的テストには、セッションベースド探索的テストを使おう
ポイント解説|探索的テストには、ツアーリング探索的テストを使おう
ポイント解説|探索的テストのサイクルはどう回すの?
参考資料
探索的テストの進め方 改訂版 杉浦 清博 (半田技術研究所)
お問合せはお気軽に
https://service.shiftinc.jp/contact/
SHIFTについて(コーポレートサイト)
https://www.shiftinc.jp/
SHIFTのサービスについて(サービスサイト)
https://service.shiftinc.jp/
SHIFTの導入事例
https://service.shiftinc.jp/case/
お役立ち資料はこちら
https://service.shiftinc.jp/resources/
SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/