テストの目的を再考する
「なぜテストを行うか?」を改めて考えてみる
最近ソフトウェアに関する研修を受けた際、テストの目的について学ぶ機会があったので、これまでの自身の業務経験と照らし合わせながら自分なりの考えを発信していく。
テストの目的の定義
テストを行う目的については、ISTQBが発行しているシラバスから引用する。
- 要件、ユーザーストーリー、設計、およびコードなどの作業成果物を評価する。
- 故障を引き起こし、欠陥を発見する。
- 求められるテスト対象のカバレッジを確保する。
- ソフトウェア品質が不十分な場合のリスクレベルを下げる。
- 仕様化した要件が満たされているかどうかを検証する。
- テスト対象が契約、法律、規制の要件に適合していることを検証する。
- ステークホルダーに根拠ある判断をしてもらうための情報を提供する。
- テスト対象の品質に対する信頼を積み上げる。
- テスト対象が完成し、ステークホルダーの期待通りに動作するかどうかの妥当性確認をする。
テストの目的と自身の経験を交えた見解
要件、ユーザーストーリー、設計、およびコードなどの作業成果物を評価する。
ソフトウェアそのものというより、ソフトウェア開発で発生するドキュメントをはじめとした成果物も品質評価の対象ですよ、という認識。これらの成果物の出来次第でテストの不具合の多寡が決まる感じがする。
JSTQB FLを取得する以前は、テストはソフトウェアを動かすことでのみ実現できないものと思っていましたが、要求仕様書を作成していた時に、要求仕様の抜け漏れが開発の実装漏れの根本原因となりうることを実感したことで、ソフトウェア開発で目に見えるもの全てが評価対象になるという意識を持って今の仕事に臨んでいます。
故障を引き起こし、欠陥を発見する。
テスト担当者が故障を検出
↓
開発担当に不具合報告
↓
開発担当が欠陥の修正に着手
という流れは不具合検出から修正までのよくあるプロセスであり、テストを行う上で直感的に分かりやすい目的の1つである。
求められるテスト対象のカバレッジを確保する。
カバレッジというとテストの実施状況を評価する方法で、ホワイトボックステストで用いられる印象だが、ソースコードだけでなく、テスト活動においてもカバレッジを測定しようと思えば実行可能なはず。
例えば、要件一覧とテスト設計の成果物の間でトレーサビリティを確保することも1つのアプローチであり、これをするとしないでは大きな差がある。過去にあったのが、テスト実装の際に要件の抜け漏れからテスト設計での手戻りは何度が発生していた。
特にソフトウェアテストに関する知見があまりない人がお客様だと、この辺りの問題は起こるかもしれない。
(どうやって成果物のトレーサビリティを確保していますか?の話は頻出テーマだと思う)
ソフトウェア品質が不十分な場合のリスクレベルを下げる。
テストをやったらやった分だけ不具合が検出され、リスクレベルは下がっていく。
とはいえ、テストの進捗に影響が出るほど不具合がある場合は、そもそもテストを行う品質に到達していないという問題があるかもしれないので、ありのままの事実をPM層に伝えるのもテストを担当する人やチームの仕事である。
仕様化した要件が満たされているかどうかを検証する。
言葉のまんま。要件が実装されているかを検証を通じて確認するのはテストの大きな目的である。
テスト対象が契約、法律、規制の要件に適合していることを検証する。
どのプロダクトにも言えるかもしれないが、リリースする地域や国によって守るべき法律や規制が存在する。
一番怖いのがそれらを違反した時に発生するリコールと、リコール改修まで販売停止といった経済的損失・将来の機会損失である。
カーナビの案件で、海外の国や地域によって独自の法規があったため、均一に同じ仕様となることの方が稀で、この辺りの仕様の厳密さはシビアだったなと思い返しています。
ステークホルダーに根拠ある判断をしてもらうための情報を提供する。
テストの結果を基にリリース可否を判断をするプロジェクトもあるので、テストは重要な役割を担っている。過去に参画していたPOSレジアプリの案件では、リリーステストで所定の基準(主要導線に関わる不具合が検出されない等)を満たせばリリース可能と判断していたらしい。
テスト対象の品質に対する信頼を積み上げる。
テストレベル毎(CT→IT→ST→UAT)にテストを進め、品質を積み重ねていくことでテスト対象の品質の向上させる。どのテストレベルにおいても、リリースするに値する品質を確保しなければならないので、ステークホルダーへの情報提供にも通じる部分がある。
テスト対象が完成し、ステークホルダーの期待通りに動作するかどうかの妥当性確認をする。
テストは仕様通りに実装されている「検証」という観点と、ユーザーが期待するものとなっているかの「妥当性確認」の観点があるが、いくら仕様通りに実装されていてもユーザーが満足するものを提供できなければ品質が良いとはいえない。
テストを担当する者として、仕様だからという理由だけでテスト結果をOKとせず、ユーザー目線で見た時に違和感があると感じたら、改善要望としてあげるのもまたテスト担当の重要な役割であると考えている。
おわりに
この記事書くのに2時間位かかったので、物凄くしんどかったです。
ただ、テストについて漠然と感じていたことを言語化したことで、自分のテストへの向き合い方を改めて考える機会となりました。
また、近い内にテストに関して発信するようにします。
Discussion