リリース判定メモ・シナリオ結果表の様式

リリース判定メモは一枚の文書です。最上段の欄が対象で、検証したビルドと製品領域、検証期間、実行した環境の組み合わせを書きます。二つ目の欄は合意した範囲です。着手前に書面で決めた主要フロー数とシナリオ数、再テスト回数をそのまま移し、その横に除外すると決めた項目を並べます。三つ目がシナリオ別の結果、四つ目が確認できなかった領域、五つ目が残存リスク、最後が判定と署名欄です。欄の順序は変えません。どこまで見たのかを知らないまま判定から読むと、その判定がどこまで有効なのかが分からないからです。対象欄の環境の組み合わせは、ブラウザとOS、端末とアプリ版のように結果が分かれる軸だけを書きます。ここにない組み合わせで出た事象は今回の検収の結果ではなく、次の範囲の候補です。

シナリオ結果表は八列です。シナリオ番号、属する主要フロー、事前条件、実行手順、期待結果、状態、紐づく欠陥番号、実行者と実行日時。状態列に入る値は四つだけです。PASSは期待結果と一致したもの、FAILは食い違ったもの、BLOCKEDは前の手順が塞がって実行そのものができなかったもの、NOT RUNは範囲内にありながら実行できなかったものです。後ろの二つをFAILにまとめると製品欠陥の数が実際より膨らみ、PASS側に混ぜると検証の幅が実際より広く読まれます。四値を分けておけば、結果表一枚がそのまま次回の実行リストになります。事前条件と実行手順の列は、別の人が同じ結果を再現できる分量までにとどめます。アカウントとデータ、入口画面を事前条件に置き、手順は番号を付けた短い文で区切ります。欠陥番号の列は欠陥台帳の項目と一対一で結びます。FAILの行から欠陥番号をたどれば重大度と再現条件、担当と対応状況が出て、欠陥台帳から逆に来れば、その欠陥がどのフローで引っかかったのかが出ます。

四つ目の欄には、範囲外で見なかったものと、範囲内でありながら見られなかったものを分けて書き、後者には理由を一行ずつ添えます。五つ目の残存リスクは欠陥一覧ではなく判断材料です。直さずに出すと決めた欠陥、再現条件を絞り切れなかった事象、運用中に見ておく地点を重大度とともに記します。この二欄が空だと合格率だけが残り、合格率は通過しなかった分がどこにあるかを教えてくれません。理由は短く書きます。環境を用意できず、先行欠陥で塞がれ、合意範囲の外。三つに分けておけば、次回に何から解くのかが文書の中で決まります。

判定欄にはREADY・READY WITH CONDITIONS・HOLDのいずれかが入ります。READY WITH CONDITIONSなら何が満たされれば出荷なのか、保留なら何が揃えば再び判断するのかが同じ欄に書かれます。リリース会議はこの文書を読んで日程を確定するか先送りし、先送りした場合は四つ目の欄が次回の範囲になります。時間が経って監査や障害調査で取り出すときにも、要求事項とシナリオ、欠陥と対応、承認記録が一本につながります。様式として渡すとき、判定欄と署名欄は空のままにします。署名は検証結果と除外範囲、前提と残存リスクを検討した人が実際の検収の後に入れます。誰が署名したかが残るからこそ、承認が意見の応酬ではなく根拠の確認で終わります。