本番障害の再発防止策が「テストが漏れたテストケースをリグレッションテストに追加して毎回確認します」となる場面を何度か見かけます。しかしながら、上記の再発防止策では欠陥流出原因（テスト漏れ）の根本原因を解決していないため、別の機能における改修で同じ原因によるテスト漏れが発生する可能性が高いです。
そこで、本記事では私が行っている欠陥流出原因を分析する方法を紹介します。私の方法はSEIテクニカルレビュー「ソフトウェアバグ発生時の真因分析手法の策定」を参考にさせていただいております。主になぜなぜ分析だけでは分析が上手くいかない方の参考になれば幸いです。
なお、不具合分析では欠陥流出原因だけでなく欠陥混入原因の分析と再発防止策の検討も行いましょう。欠陥混入自体を防ぐ対策も行った方が望ましいです。
目次
欠陥混入工程と欠陥検出工程の特定
欠陥流出原因の分析・再発防止策の検討対象は、欠陥が混入された工程から欠陥が検出された工程までの間の欠陥を検出するチャンスがあった各工程です*1。本番障害に素早く気づけば本番障害による損失を軽減できるため、本番障害を検出する工程も分析対象に含めています。
以下の工程の例においては、実装工程で欠陥が混入し、エラー監視で本番障害となる欠陥を検出した場合、4行目から11行目までの欠陥検出工程が分析対象です。ただし、欠陥の性質により欠陥の検出が困難な工程もありますので、そのような工程は分析対象から外してください。*2
工程の順番や工程の内容はご自身の組織に合わせてアレンジして下さい。
| 行数 | 欠陥混入工程 | 欠陥検出工程 |
|---|---|---|
| 1 | 要件定義 | 要件定義書のレビュー |
| 2 | 基本設計 | 基本設計書のレビュー |
| 3 | 詳細設計 | 詳細設計書のレビュー |
| 4 | 実装 | 静的解析ツール等によるチェック |
| 5 | コードレビュー | |
| 6 | コンポーネントテスト*3 | |
| 7 | 統合テスト | |
| 8 | システムテスト | |
| 9 | 受け入れテスト | |
| 10 | リリース | リリース手順のレビュー・テスト*4 |
| 11 | デプロイ | 本番環境でのテスト*5 |
| 12 | エラー監視 | |
| 13 | KPIなどのモニタリング*6 | |
| 14 | 顧客からの問い合わせ |
欠陥検出工程における問題のある工程の特定
必要に応じて欠陥検出工程の開始から終了までの工程を更に細分化し、どの工程に問題があったかを分析します。
例えば、ASTER-テスト設計コンテスト'21-テスト設計チュートリアル テスコン編の工程をベースにしたテストに関する工程は以下の通りです。*7
| 工程 | 問題の例 |
|---|---|
| テスト要求分析 | 修正内容や仕様の誤認、リスク分析の誤り*8、テスト観点漏れ |
| テストアーキテクチャ設計 | テストレベルの誤り |
| テスト詳細設計 | 網羅基準の誤り、テスト技法の利用方法の誤り |
| テスト実装 | テスト手順の誤り、期待結果の誤記 |
| テスト実施 | テスト手順通りに実施していない、テスト漏れ |
決まった工程がない場合などでは、単に作業の時系列を並べて事象の問題点を洗い出します。
- プロダクトマネージャーが要件を決める
- 開発チーム（Dev、QA）が基本設計書を作成する
- Devが実装中に上記2の基本設計書に問題があると気づく
- Devとプロダクトマネージャーが相談して新しい仕様を決める
- 新しい仕様を基本設計書に反映し忘れる
- QAが基本設計書をもとにテスト設計を実施
欠陥流出原因の分析
問題のあった工程に対してなぜなぜ分析を実施して欠陥流出原因の分析をします。 ゼロからなぜなぜ分析を行うよりも1つの原因に対する分析範囲が絞られているため、分析しやすいと思います。
なぜなぜ分析が上手くいかない場合は、特性要因図の考え方が参考になるかもしれません。 navi.dropbox.jp
再発防止策の検討
まだ再現性の高い方法を言語化できませんが、抽象的には以下の点に気をつけています。
仕事のやり方（プロセス）を変える
注意する、ルールを徹底するなど本人の意識に期待する再発防止策は意味がありません。今までの仕事のやり方では注意ができない原因、ルールを徹底できない原因があるはずです。そのため、今までの仕事のやり方を変えて注意やルールの徹底が行われるように改善するか、注意やルールそのものを不要にする改善を行う必要があります。
ルールの徹底が行われる例としては、以下のようなものがあります。
- BTSのチケットのフィールドを必須項目にして情報の伝達漏れをなくす
- テスト計画書のテンプレートに非機能要件のテストの項目を入れて非機能要件のテスト漏れをなくす
なお、作業者の能力や業務理解を向上させる再発防止策は仕事のやり方を変える（教育方法を変える）ので問題ありません。
継続的な工数があまりかからない方法にする
ダブルチェック、膨大なチェックリストの活用、ドキュメントのメンテナンスといった継続的な工数がかかる再発防止策はあまり継続しません。忙しい、急いでいるといった場合に、再発防止策の作業品質が落ちたり作業自体をやらなくなります。 ダブルチェックやチェックリストに頼らざるを得ない場合は、チェック対象を以下のようなものに限定すると良いかもしれません。
- ミスが発生しやすいもの
- ミスが発生した時のインパクトが大きいもの
いきなり工数がかかり過ぎる方法にしない
原因分析が正しく行われても再発防止策の方向性が誤っている可能性があります。 また、再発防止策の方向性が正しい場合でも、理想の対策ではなく少しの工数をかけた対策で十分な効果が得られる場合があります。 そのため、再発防止策の方向性を決めた後は、まずは少ない工数で取り掛かれる方法を試してみましょう。
例えば、チェックリストを運用して再発防止策の方向性が正しいようであれば、チェックリストのチェックを自動化する。
これは絶対正しいと自信が持てる再発防止策であれば、最初からある程度工数をかけても問題ありません。
再発防止策の効果測定
再発防止策が本当に効果があったのかを測定します。定量的な効果測定に工数がかかり過ぎる場合は定性的な効果測定でも構いません。 再発防止策が期待通りの効果が得られなかったのであれば、再発防止策を改めて検討しましょう。
また、一時的には再発防止策の効果が出ても、事情が変わって再発防止策の役目を終えることもあります。そのため、再発防止策は定期的に棚卸ししましょう。
例えば、情報伝達漏れを解決するために詳細なドキュメントを作成していたが、ドメイン知識の理解が深まり口頭での情報共有が上手くいくようになったので、詳細なドキュメントの作成を不要にする。
その他参考資料
本記事を書くにあたり、以下の資料も参考にさせていただきました。 欠陥流出原因の分析方法は他にも様々な方法があります。よろしければ試してみてください。
- IPA「情報処理システム高信頼化教訓集（ITサービス編）」別冊Ⅱ：障害分析手法
- ソフトウェア品質管理研究会「バグの流出防止を考える －どんなテストをすればバグを見つけられたのか？－」
- JaSST'13 Tokyo 「過失に着目した欠陥のモデリング～バグ分析はなぜうまく行かないのか？～」
終わりに
本記事では欠陥流出原因を分析する方法を紹介しました。 本記事の方法は、なぜなぜ分析だけするよりも工数はかかるが、なぜなぜ分析だけするよりも分析の成功率が上がると考えています。 なぜなぜ分析だけで上手く分析できている場合は本記事の方法は必要ありませんが、なぜなぜ分析だけでは分析が上手くいかないと悩んでいる方は試してみてください。
*1:例えば、仕様の考慮漏れは設計書のレビューだけでなくシステムテストでも検出できる可能性があったので、各工程で再発防止策を考える。全ての再発防止策を実施するか否かは工数次第
*2:例えば、ブラウザ依存の欠陥はシステムテスト以外では検出しにくい
*3:コンポーネントテスト＝ユニットテストと定義し、TDDを行なっている場合は「コードレビュー」より前の工程になる
*4:特にゼロダウンタイムデプロイを目指す場合はユーザに影響しないリリース手順が必要。手戻りのリスクを考えると、もう少し前の工程で実施した方が良さそうです
*5:主にテスト環境と本番環境で差異のある箇所に関してテストを実施する。例えば、インフラ周りの設定、社外のサービスとの連携など
*6:ユーザのアクセス数、商品の注文数など。注文できないエラーがあれば注文数の激減で欠陥に気づける
*7:テスト実施より前の工程は、例えば基本設計の段階で実施するなど前倒しで実施しても問題ありません
*8:改修の影響範囲の予測を誤るなど
