ソフトウェアのテスト手法として、一般的に2つの手法が取られています。
その違いと使い分けについて、整理してみました。
◾︎ ホワイトボックステスト
プログラムのロジックがきちんと通っているか、想定通りの動きになっているか、プログラム内部構造にフォーカスしたテストのことです。
簡単に言うと、
「今回改修が入った部分のプログラムが、うまく動くか確認するテスト」
です。
メリット:
・改修した部分のプログラムが設計通り正常に動くかの担保を取れる。
・潜在バグもある程度検知できる。
デメリット:
・改修部分以外への影響まで確認できない。
・顧客要件を正しく反映しているか確認できない。
◾︎ ブラックボックステスト
プログラム構造は全く見ずに、顧客要件やデータパターンが反映されているかを網羅的にテストする手法です。
具体的には、操作や画面/帳票表示パターンをマトリクスで抽出し、要件やデータモデルの要素ベースで画面が正しく表示されるか、想定通りの値が渡されているか、などをテストします。
メリット:
・改修部分以外への影響までテストできる。
・顧客要件と画面表示やパラメータが合致しているかをチェックできる。
デメリット:
・全網羅するパターンをテストすると工数が大幅にかかる。
・観点の抽出レベルによって、バグの検知率が大きく変動する。
結論から言うと、
両方のメリットを活かしつつ、両方のやり方をテストに織り交ぜるのが正解です。
ホワイトボックスだけでは、今回手を入れなかった部分への無影響確認(デグレチェック)は網羅出来ないし、ブラックボックスだけでは潜在バグを検知しきれません。
なので、
機能が正しく反映されているかの確認はホワイトボックス、要件やデータパターンが網羅されているかの確認はブラックボックスで実施するのがバランスの良いテストと言えるでしょう。
何れにしても、
100%のテストなどというものは、存在しません。
それを目指すのもナンセンスです。
費用が青天井にあるなら別ですが、とかくユーザーはコストをかけずに品質を上げたがるので、その見極めのためにも確り区切りをつけなければいけません。
プロジェクト標準指標にも依りますが、一般的にテスト網羅率は60〜90%程度で品質評価をします。
ただし、「8割のバグは2割の箇所に集中する」という法則がありますので、「重点的にテストすべき2割はどこか？」という観点の抽出が、実際のテスト品質確保のプロセス管理としては重要です。
この辺りの目線は、エンジニアごとに大抵バラバラなので、まずはテスト方針とスコープを確り定めて品質確保の観点を顧客とすり合わせるのが、プロジェクトマネジャーに求められる仕事になります。
テスト品質については、まだ正解というものが存在しないので、考え方をしっかり固めておかないと議論が発散するもとになります。
つまり、
「想定通りのテスト観点でバグを抽出出来たらOK、そこからモレた重大なバグがあれば、テスト方法に見直しが必要」という部分を、ステークホルダーと認識合わせすることです。
間違っても、「バグ0を目指します！！」などと、内外で言わないように気をつけましようね。。
重要なのは、重大なバグをテストで検知し一定の品質を確保することであり、100%のテストをすることではないのですから。
本日も最後までお読み頂き、誠に有り難うございました！
