テスト期間に品質強化のためにできること

結論

テスト期間に欠陥（バグ）が多く見つかり、品質強化が必要となった場合の対策は以下の通り。

　１．発生した欠陥の横展開
　２．発生していない欠陥を検出するための横展開
　３．密なコミュニケーション

＜前提＞
　筆者（私）は社内SEで設計から結合テストは外部ベンダーに委託している

詳細

１．発生した欠陥の横展開

これは当たり前だができていない開発者もいる。特に重要だが漏れる点は以下。

　（１）横展開の結果だけではなく、範囲・観点を明確にする
　　横展開は結果だけでは意味がない。範囲・観点を明確にして確認しないと手戻りが発生する。

　（２）範囲、観点は根本原因に紐づいている必要がある
　　場当たり的な対応ではなく根本原因を分析したうえで根本原因に対して横展開していないと欠陥（バグ）を検出することはできない。

（例）
DB（Integer）とElasticsearch（Boolean）の型の不一致が原因でバグが発生したとする。

これに対する横展開として、
　「DBがIntegerの箇所で不一致が他にないかを確認して不一致はありませんでした」
と報告があったとする。
これは場当たり的な対応であり、上記の（２）を満たしていない。

型の不一致が発生したのが「DBの型がIntegerだったこと」が原因だったならよいが、実際には「DBの型が何なのかをよく確認せずにElasticsearchの型を決めたこと」が原因であった。
であれば、Integerの箇所以外も確認が必要なことは容易に想像できる。

２．発生していない欠陥を検出するための横展開

　これはより深い根本原因に対する横展開と言ってもよい。例えば前工程のテストが不十分だったのなら、なぜ不十分だったのか。考えられるのは例えば以下。

　（１）テストケースが漏れていた
　（２）テストケースはあったが打鍵が漏れた
　（３）打鍵をしたが検証で見逃した

　また、上記が（１）テストケースが漏れていた、であればなぜ漏れたのか。考えられるのは以下。

　（１）設計書とテストケースの紐づけをした資料がなかった
　（２）資料はあったが条件分岐の漏れがあった

　上記が（１）紐づけした資料がなかったならなぜか。考えられるのは以下。

　（１）紐づけ資料を作るというルールがなかった
　（２）ルールを知らなかった
　（３）ルールを遵守するゆとりがなかった

　対策として、
　上記が（１）（２）なら紐づけ資料を作る指示を出せばよい
　上記が（３）なら人員を増やすよう指示を出せばよい

　このように、原因によって対策は異なるので、原因の深堀をする必要がある。

３．密なコミュニケーション

上記１，２の分析、それによって決まった対策を進める上で重要なことは密なコミュニケーションを取ることだ。具体的には以下。

（１）日次でミーティング
　認識齟齬の早期解消、悪い報告を早期にもらうために必要。今時Slackなどのツールでリアルタイムでコミュニケーションを取ればよいという考えもわかる。
　が、リリースまでの期間が限られてるのであれば些細な認識齟齬が命取りになることもある。

（２）成果物を1，2割できた時点で提出してもらう
　これも認識齟齬の早期解消のために必要。人間は自分の都合のよいように考えるものである。

　　　・委託元（こちら）：このくらいは言わなくてもやってくれるだろう
　　　・委託先（相手）　：ここまではやらなくてもよいだろう

　という認識の齟齬が発生したまま成果物ができてから気づくと、1週間分の作業がやり直しということになりかねない。

（３）ベンダーのマネジメント層にも対策の検討、報告に参画してもらう
　担当者レベルだと話にならないこともある。
　「こちらもマネジメント層から指示を受けているので・・・」と言ってベンダーのマネジメント層も巻き込むと危機感を煽ることができる。

背景

現在担当しているプロジェクトの品質が悪い。

一言付け加えておくと、途中から（すでに前工程のテストが終わってから）プロジェクトに参画したので前担当者（転職してしまった・・・）に責任があると考えている。

リリースまでに幸いにしてまだ時間があるので品質強化のために対策を実行することとなった。

蛇足

請負契約であればベンダーには品質を担保する責任が発生する。

当初見積もりに入っていない作業だとしても、上記を盾にすれば意外とやってくれる。（準委任だったら話は別）