QAの本当の価値はどこにあるのか―探索力と経験が品質を左右する
QAの仕事は予定調和が崩れる瞬間を誰より先に見つけることだ
QAの仕事というと、いまだに
「テスト観点を整理して、テストケースを大量に作って、順番に実行すること」
だと思われがちです。
でも、私はそうは思っていません。むしろ逆です。
品質を本当に高めるQAは、テストケースを量産する人ではなく、
**探索し、違和感を嗅ぎ取り、経験から危険な場所を見抜ける人**
だと思っています。
今日は、私が普段感じているQA観を整理して書いてみます。
1. QAの価値の中心は探索的テストにある
私は、QAの本体はここにあると思っています。
探索的テストは、ただのアドリブではありません。
なんとなく触ることでもありません。
探索的テストの本質は、
**観察しながら考え、仮説を立て、その場で次のテストを脳内設計し続けること**
です。
ここが強いQAは、本当に強い。
なぜなら、実際のプロダクトは
- 仕様書どおりにしか使われないわけではない
- 開発者の想定どおりにだけ壊れるわけでもない
- テストケースどおりの不具合だけが出るわけでもない
からです。
品質を最後に決めるのは、予定された確認項目を何件消化したかではなく、
**誰も書いていなかった壊れ方をどれだけ先回りして見つけられるか**
だと思っています。
実際、Itkonen, Mäntylä, & Lassenius (2009) の実証研究では、手動テストの現場を観察した結果、テスターが事前に設計されたケースどおりに機械的に作業しているわけではなく、**実行中に思考し、仮説を立て、次のアクションを動的に変えている**ことが報告されています。つまり、優れたテスト活動の本質には、もともと探索的な要素が含まれているということです。
また、Afzal et al. (2015) の実験では、探索的テストがスクリプトベーステスト（事前定義されたテストケースの実行）と比較して、**同等以上の欠陥検出率**を示したことが報告されています。事前にケースを緻密に設計しなくても、経験あるテスターが探索的に取り組めば、品質担保において十分な成果が出せるという実験的な裏付けです。
探索的テストが強いQAは、
- 違和感に気づける
- 挙動のズレを嗅ぎ取れる
- 仕様の穴を見つけられる
- ユーザー視点で「これ危ない」を言える
- 複数機能のつながりで起きる事故を見抜ける
この力がある。
私は、ここがQAの価値の中心だと思っています。
2. 品質を分けるのは、経験から蓄積された知識と判断力
探索的テストの質を左右するのは何か。
最後にものを言うのは、**経験から蓄積された知識と、そこから生まれる判断力**だと思っています。
この画面、なんか危ない。
この導線、ユーザーは迷う。
この実装、組み合わせたら壊れそう。
この入力条件、たぶん抜けてる。
この修正、別の場所に副作用が出そう。
こういう感覚は、教科書を読んだだけでは身につきません。
実際に見てきた不具合、
踏んできた地雷、
仕様の曖昧さで起きた事故、
リリース後に表面化した問題、
その蓄積が、判断力になります。
研究でも、テスターの知識と経験が統合されたとき、探索的テストの欠陥検出力が大きく上がることが示されています（Itkonen et al., 2013）。
私が「直感」と呼んでいるものの正体は、経験を通じて圧縮された判断力です。
そしてQAの価値は、この判断力に一番出る。
3. だからこそ、QAの時間はもっと高い価値の活動に集中させたい
ここまで書いてきた探索的テストと、そのための判断力。
これがQAの価値の中心だとすると、私たちの時間の使い方にも自然と見直すべきポイントが出てきます。
テストケースの起票は、仕様を決めた人・実装した人が最も自然にできる
テストケースのベースを最も効率よく作れるのは、QAよりも
**仕様を決めたプランナー**や**挙動を実装した開発者**です。
どんな入力を想定しているのか。
どの分岐が重要なのか。
何を正常と見なすのか。
どこに実装上の制約があるのか。
こうした前提知識を最も持っているのは、やはり作った側です。
QAがゼロから仕様を読み解き、観点を起こし、ケース化していくと、
- 仕様理解のための時間
- 観点整理の時間
- ケース作成の時間
- 認識ズレの修正時間
が積み重なります。
私は、QAが最初にやるべきことは「テストケースを起票すること」ではなく、
**そのケースでは拾えないリスクを見つけにいくこと**
だと考えています。
事前の観点整理だけでは、品質担保には十分ではない
もちろん、すべての整理が不要だと言いたいわけではありません。
ただ、現場でよくあるのは、QAが丁寧に観点を整えても、最終的には
- 既に仕様書に書いてあった内容だった
- 開発者の頭の中では当然の前提だった
- 実際の検証ではそこまで細かく見なかった
- 実装変更で大半が作り直しになった
ということです。
Itkonen et al. (2009) が示したとおり、テスト活動には本質的に探索的な要素が含まれています。事前の設計だけで品質が担保されるわけではなく、**実際にプロダクトに触れながら考え、反応し、次のアクションを選ぶプロセス**が品質を支えています。
品質を上げるために必要なのは、ドキュメント上で観点を増やすことよりも、
**実際に壊れそうなところへ早く触ること**
です。
シナリオの再構築より、想定外の探索にQAの時間を使いたい
シナリオ確認が不要だと言いたいわけではありません。
ただ、仕様の流れはすでにプランナーが描いており、画面遷移や利用フローは開発側も把握しています。実装後であれば、実際に触れば流れはすぐ見えます。
そのうえでQAが別にシナリオを起こし、文章として整え、ケース化していくのは、多くの場合、重複した作業になりがちです。
私はその時間を、
**探索的テストで仕様の穴・想定外の操作・操作ストレスを探すこと**
に使いたい。
品質を落とすのは、予定通りの一本道ではなく、たいてい
- ちょっと順番がズレた操作
- 想定外の戻る/再読込
- 複数機能の組み合わせ
- 入力の揺れ
- 状態遷移の食い違い
のような"設計されたシナリオの外側"です。
Afzal et al. (2015) の研究が示すように、探索的テストはスクリプトベーステストと同等以上の効果を発揮できます。であれば、QAは一本道を美しく書く人ではなく、
**道を踏み外したときに何が起きるかを見る人**
であるべきだと考えています。
📓まとめ
私のQA観を一言で言うと、こうです。
**QAは、テストケースを作る人ではない。
テストケースでは拾いきれない品質リスクを見つける人だ。**
だから私は、
- 一番重要なのは探索的テスト。観察し、仮説を立て、脳内設計を続ける力がQAの核心
- 品質を分けるのは経験から蓄積された判断力
- テストケースの起票は仕様を決めた人・実装した人が最も自然にできる
- 事前の観点整理だけでは品質担保に十分ではない。早く触ることが品質に近い
- シナリオの再構築より、想定外の探索にQAの時間を集中させたい
そう考えています。
もちろん、これは「何でもかんでもケース不要」という話ではありません。
回帰確認、契約条件、監査対応、説明責任が必要な場面では、整理されたテストは必要です。
それでもなお、
品質を本当に一段上へ持っていくのは、ケースの枚数ではなく、QAの探索力と判断力だ
という考えは変わりません。
QAの仕事は、予定調和を確認することではない。
予定調和が崩れる瞬間を、誰より先に見つけることだ。
参考文献
Itkonen, J., Mäntylä, M. V., & Lassenius, C. (2009). *How Do Testers Do It? An Exploratory Study on Manual Testing Practices*. 2009 3rd International Symposium on Empirical Software Engineering and Measurement (ESEM).
Itkonen, J., Mäntylä, M. V., & Lassenius, C. (2013). *The Role of the Tester's Knowledge in Exploratory Software Testing*. IEEE Transactions on Software Engineering, 39(5), 707–724.
Afzal, W., Ghazi, A. N., Itkonen, J., Torkar, R., Andrews, A., & Bhatti, K. (2015). *An Experiment on the Effectiveness and Efficiency of Exploratory Testing*. Empirical Software Engineering, 20(3), 844–878.
