📌

【出荷判定】何をもってリリースとするか

2021/09/20に公開

1年ほど前に、2年間ほど出荷判定の担当をしていました。
その際、何をリリースの基準としていたか、試行錯誤しながら実施したものとその結果を残します
よく設計できていた、というものは正直ほとんどありません。

自戒の側面が強い内容となります。

プロダクト：統合基幹業務システム（SCM系）
開発規模：３〜５人の開発チームが4つほど
出荷サイクル：2ヶ月に1度
サイクル毎の出荷チケット数：60~80件ほど
チーム体制：
- 業務領域ごとに縦割りで構成
- QE/QAなど品質保証を主な責務とするチームはなし
- フロントエンド/バックエンドなどアーキテクチャに基づいたチーム分けはされていない

プロセス管理はRedmineを使っていました。
観点としては、各チケットごとに然るべき手続きが踏まれているか、のチェックとなります。
手続きは以下を用意していました。

各手続きはチェックボックスとして用意しており、開発担当者はチェックできないように制御をしています。
必ず各手続きにおいて、複数人の関与者がいることを前提としていました。

また、レビュー実施内容の記載やテストケースに対する証跡の有無をチェックの基準としていたため事実に即したプロセスの記録がされていましたが、出荷判定前の入力漏れなどが目立ち、運用負荷が高くなりました。

カバレッジ分析
カバレッジを取得し、未通過の部分に関してはC1（branch coverage）を最低限のラインとして、1行1行「なぜ未通過のままテスト完了とするか」を確認し、残していました。

よく未通過として残ってしまっていたのは以下のパターンです。
- 自動生成された未使用のgetter/setter
- リファクタ時の既存pgm削除もれ

上記の通り基本的に致命的なバグの発覚はとても少なく、
未通過ソース1行1行確認しているのに対し、費用対効果の薄い結果となりました。

E2Eテスト結果分析
Seleniumを利用して作成したE2Eテストの結果をAllure Reportで確認していました。
ただSeleniumの実行は必ずしも同一ソースで同一の結果とならず（外部要因における失敗など）結局は手動で失敗した分を保証する、何度か実行をやり直す、など完全自動の運用とはなっていません。

そういった要因からテストへの信頼性がなくなり、形骸化していってしまった側面もあります。

ソース差分に対するテストケース数です。
もちろんこの項目のみで適切な分量のテストが実施されているかなど判断できないのですが、
こちらはあくまで「異常値の検出」、という意味で利用していました。

例えば（極端な例となりますが）ソース差分5000行に対して開発者テストケース数が10ケースだった場合、それは本当に十分な量のテストができているのか？という指摘が入ります。

時にはテスト時に発覚したバグを残したままリリースと判定することもありました。
基本的にはバグを抱えたまま出荷した方が、出荷しないよりも圧倒的に多くのメリットがあると想定されるものに対しそのような対応をしていました。

出荷判定時には残存バグに対して以下の項目を管理していました

対応を延期する、または対応を予定しない理由

基本的には発覚したバグを残したまま出荷となるケースはそうありません。
「改修リリースまでにバグの発生する運用ケースが無いと言い切れること」などが当てはまります。