『テストの7つの原則』〜 パート④ 〜
はじめに
現在、アプリ開発者としてプロダクトの持続的な成長や
ユーザーへのコミットに寄与するためにも、
SDLC全体を見渡して開発をすること、
および、それにはテストに関する体系的な知識が必要だと考え、
それを効率良く学べるJSTQB Foundation Levelの資格試験の勉強をしており、
そこでのインプットを記事にしたいと思います。
今回はその中でも「テストの7つの原則」の一部について
記事にしたいと思います。
なお今回は
欠陥の偏在
こちらの原則について記事にしてみようと思います。
欠陥の偏在とは
皆さんはこんな場面に遭遇したことはありますか？
『この機能、なるはやで欲しいって言われたけど、期日めっちゃ短いやん。。。』
『この機能、レビューのリソースが殆ど無かったんだよなぁ。。。』
『この機能、他の機能と比べるとめっちゃ複雑なんだよね。。。』
『しかも作るのめっちゃムズいし。。。』
『新しく入ったAさんはまだ開発経験が浅いんだけど、全然フォロー出来てない。。。』
『ほぼ一人で作ってレビューもない。。。』
きっと何処かでこんな場面に遭われた方もいらっしゃるかも知れませんね😅
このような環境で作った機能やプロダクトには、
そうではないものと比べても欠陥が生まれやすくなることは
容易に想像出来るかと思います。
この特性のことを『欠陥の偏在』と言います。
まとめ
欠陥のこのような特性を鑑みるにつけても、
実施されるテストには効率性や合理性が求められます。
現実のプロジェクトには様々な制約がつきまとうからです。。。
この制約の中で最大のパフォーマンスを発揮するためには、
チームや個々人が開発時に培ってきたノウハウ、経験値、
またはよりドメイン性の高い知識に基づいてリスク分析を行い、[1]
よりリスクレベルが高くて優先度の高いものへテスト工数を割いていくことが
求められるものと思われます。
このリスク分析についてはまた別の機会で記事にしてみたいと思います。
参照
-
ここで言うリスク分析とはプロダクトリスク分析のことを指しています。 ↩︎
Discussion