「バグ出しのテスト」をすれば品質が保証できると思いがちですが、そうではありません。
ソフトウェアの品質は、テスト工程ではなく開発工程で高めるものです。
[参考]Foundations of software testing ISTQB certification
言い換えると、品質向上に貢献できるのは機能の実現に関わるエンジニアです。
つまり、品質向上には「エンジニアが品質意識を持ち取り組む」事が大切なのです。
じゃぁ、ソフトウェアテストの目的って何？
従来から言われている目的
- ソフトウェアに潜むバグを検出し、修正
- 求められる要件を満足していることを確認
情報を収集し，アクションにつなげる活動とした捉え方
- バグの発生状況から、未だ潜むバグの存在を推測し 品質の成熟度を判断
- バグの作込み要因と、より上流の検証フェーズでの流 出要因を分析して、開発プロセスの問題を特定・対策
要するに、「テストして収集した情報」を使わず、現行のスケジュールを進めるのであれば、テストをする必要がありません。
それはテストをしていないのと同じことになります。
だからこそ、エンジニアに「品質説明力」スキルは不可欠
「品質説明力」とは、ソフトウェアが重要な役割を果たす製品・システムにおいて一定の品質確保が達成されている事実を、供給者側が利用者に対して十分に伝える「スキル=力」です。
火災、落下、故障など多くの品質問題を如何にお客様に安心・理解してもらうか？は、このスキルにかかってますが、エンジニアは軽視傾向があります。
その結果、「テスト結果」だけで「品質は安定している」と説明するエンジニアがいます。
- バグカーブが収束した
- テスト実施100％完了
- ○起因の不具合を発見
- などなど
テストケースは仕様書から生成されるものであり、エンジニアに品質説明を求められる場合は「上流工程の成果物が十分でない」事を疑われると思った方がよいでしょう。
問「なぜ、仕様書の網羅性が不十分なのに、テストを行ったから大丈夫だと言えるの？」
ようするに、エンジニアが説明する必要があるのは、
- 網羅性が不十分なのテストを実施して、何が確認できたのか？
- 何が確認できなかったのか？
- 目標としていた品質に対してどこまでできたのか？
- 不具合が○件発見されたことは分かったが、で、どうなの？
です。
答「発見＆流出した不具合を数でなく、不具合の中身から分析し、既に必要なリカバリプランを立てているので大丈夫です。」
このためには、発見した不具合（バグ）を分析して、要因の特定と品質成熟度を判断することが重要です。
じゃぁ、不具合（バグ）分析って何するの？
バグ分析とは、バグを織り込んだ時期の事実の把握を行い、「要因工程」の絞り込みと「バグの織り込み要因」の特定を行うことです。
バグ分析の目的は主に2種類あります。
| 品質成熟度を判断する（現品質の推定、後工程・最終品質の予測） | バグの発生傾向を分析して、未だ潜むバグの存在を推測し品質の成熟度・後工程や最終品質を判断する。それにより後工程の作業内容や作業スケジュールの調整を行い、最終品質が要求レベルに達するようにする。 |
|---|---|
| バグを再発防止する（開発プロセスのカイゼン） | なぜ作り込んだのか＜作り込み原因＞と、なぜ作り込んだバグをレビューやテストで見逃してしまったのか＜見逃し原因＞の分析から真因を特定し、改善＆未然防止を行う。 |
※ 独立行政法人 情報処理推進機構(IPA)より
品質を語る上で必要なのは「品質成熟度を判断する」ためのバグ分析です。
ですが、重篤問題に関しては「バグを再発防止する」観点での分析結果を求められる事もあります。
品質成熟度を判断するためのバグ分析とは？
不具合分類で全体傾向と深堀り不具合を把握
最近の流行に「ODC分析（直交欠陥分類：Orthogonal Defect Classification）」があります。
ODC分析を利用すると、偏在する障害領域を特定するだけではなく、それが作り込まれた開発工程を特定する事ができます。
これによりテスト結果だけでは分からない不具合の特徴は見えてきますが、これだけでは足りません。
- リファクタリングにより発生した不具合なのか？
- 新機能実装により発生した不具合なのか？
- 潜在バグなのか？
- ハードウェア変更起因なのか？
- OSアップデート起因なのか？
エンジニアには、要因分類手法を用いた上で「何起因（何の要件）の不具合が何故発生したのか？」が求められます。
不具合分析による真因発見と改善・未然防止
次に、なぜなぜ分析等を行い「その不具合が発生した真因」は何なのか？を分析します。
抽象的な真因に辿り着かぬように、具体的な不具合例で行いましょう。
| CPU Post processorとAudio Driverの間で、Shared memoryのStatusのミスマッチが発生した状態でリリースされた |
| ↓なぜリリースされたか？ |
|
〈エンジニア観点では？〉 [why1] Suspend/Resume機能の処理を守る必要があったが、タイミングにより順序性が守れなかったため 〈テスト観点では？〉 （省略） |
| ↓なぜ順序性が守れなかったか？ |
| [why2] 終了処理をしたと勘違いし、返信していなかったため |
| ↓なぜ勘違いしたか？ |
| [why3] 終了処理に対する他のモジュールの順序性を考慮できてなかった |
| ↓なぜ考慮できてなかったか？ |
|
〈設計者観点では？（作り込み原因）〉 [why4] 順序性を守らなければならないThread間のエンジニアの理解（意識）が欠如していたため 〈レビュー者観点では？（見逃し原因）〉 （省略） 〈エンジニアテスト観点では？（見逃し原因）〉 （省略） |
| ↓なぜ欠如していたか？ |
| [why5（真因）] エンジニアがThreadを理解（意識）した開発ができる仕組みがない |
なぜなぜ分析で個人の問題にすることは止めましょう。
真因は個人ではなく設計、組織、プロセスにあります。
最後に、真因に対する対策を出します。
| 【今回のプロジェクト向け】 Audio関連の探索テストや信頼性評価、ランダム試験を拡充し、個別の不具合修正することで乗り切る |
|
【今後のプロジェクト向け】 設計者がThreadを理解（意識）した開発ができる仕組みを作る →Multi-Thread Warrant Designを利用したアーキテクチャにリファクタリングする |
すぐに「○○の観点をレビューに追加する」という対策になりがちですが、これはレビュー者が疲弊するだけです。
また、ヒューマンエラーは必ず発生します。
真因として辿り着くべきは、「不具合を出さない、あるべき設計構造って何？」です。
まとめ
品質は、適切な開発プロセスと技術的な根拠を、事実に基づき示し、目標を満足していることをロジックをもって説明する必要があります。
このためには「開発工程でどのように作り込んでいくのか」が重要であり、品質保証は開発している責任者（エンジニア）の義務です。
大切なのは、事前にプロジェクト特性を加味した品質計画があってこそ、品質説明に納得・安心が生まれます。
- どんな設計をしたら品質目標を達成できるか？
- どんなテストをしたら品質目標を確認できるか？
言い換えると、明確な品質計画や品質目標なくして、品質説明が妥当か判断はできません。
