#◆ご挨拶
こんにちは！QA Kooです。
ご覧くださりありがとうございます。
はじめましての方も、いつも見てくださる方もよかったら最後まで見てください。
今回のテーマはなぜテスト範囲を考慮しないのか？について書きたいと思います。
皆さんもテスト範囲として考慮されずに本番環境で障害となるケースはありませんか？
実際私の担当しているタイトルでもテスト範囲が考慮されてなく、障害が発生してしまうことは多々あります。
そんなときテスト設計者に原因を尋ねると、「仕様書に書いてないので考慮してない」という回答をもらうことが多々ありました。
今回はそういったテスト設計者の意識やなぜ考慮できなかったのかを分析しお伝えできたらと思っています。
#◆考慮漏れする設計者の意識
下図のようにマインドマップを使って、テスト範囲の考慮が漏れる要因を分析しました。
分析すると大きく分けて4つの要素になりました。
- 業務範囲外の認識 → 教育不足
- 範囲を洗い出す技術不足 → 教育不足
- 仕様を理解していない → 教育不足
- 工数不足 → 見積もりミス
上記のように、人材の教育が不足していることが主な要因と考えられます。
特に自身の業務範囲外と認識してしまっているケースが私の担当では多く、設計時にテスト範囲を考慮してないことが多く見受けられました。
そのため「仕様書に書いてないので考慮してない」という回答が行われるわけです。
#◆改善例
分析結果から教育が必要であることは見えていますが、その教育について具体的な例を一部お伝えします。
- 注意喚起
- テスト設計にはテスト範囲を考慮する必要があることを認識
- テスト設計フローに追加
- テスト設計時にテスト範囲を検討するフローを組み込み
- テスト範囲の洗い出し
- 洗い出し方法はマインドマップを使ったものなど自身にあったものを使用
- テスト範囲のすり合わせ
- 開発と洗い出したテスト範囲をすり合わせ
このように作業者に認識してもらうのと関係者で範囲の妥当性を確認するのが重要になります。
#◆最後に
テスト範囲についてはテスト設計者自身の能力に依存するため、教育によりテスト設計の業務範囲であることを認識してもらうことと、テスト範囲を洗い出したら、その範囲は正しいか複数人から意見をもらうことで漏れを軽減できると思います。
まだテスト範囲を激的に減らせるまでは至っていませんが、こういった取り組みがどこかで少しでも役に立てたらと思っています。
もし、障害発生時に状況確認をおこなったさい、テスト設計者から仕様書に書いてないので考慮してないと言われたら、ぜひ活用してみてください。