📌

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

2021/09/20に公開

はじめに

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

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

前提

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

プロセスの判定

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

  • 要件定義レビュー
  • 設計レビュー
  • コードレビュー
  • 開発者テストケースレビュー
  • 開発者テスト実施確認
  • 評価者テストケースレビュー
  • 評価者テスト実施確認
    (※)評価は専門部隊がなかったため、開発者同士で担当を割り振って相互テストをしていました。

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

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

テスト品質の判定

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

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

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

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

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

  • 手動テストの結果確認
    カバレッジ分析やE2Eテストの結果確認は出荷物全体に対するテスト品質の保証であったため
    各チケットに対して不十分なテスト分量となっていないかの判定をここで実施していました。
    判定に用意していた項目は以下です。
    • ソース差分行数
    • 開発者テストケース数
    • 評価者テストケース数

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

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

残存バグの判定

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

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

  • 対象チケット(発生元チケット)
  • バグの内容
  • 対応を延期する、または対応を予定しない理由
  • 延期する場合の出荷時期

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

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

GitHubで編集を提案

Discussion

ログインするとコメントできます