出荷前QA検収サービス ご利用の手引き

外部検収を入れるかどうかより先に決まるのは時期です。検収はリリース候補ビルドが出てから始めます。機能がまだ足されているビルドを渡すと、実行したシナリオが次のビルドで無効になり、その再実行分がそのまま日程に乗ります。逆算の最初の枠はコードフリーズ日です。検収の開始日は候補ビルドとアクセス準備の状況を見て合意します。基本検証は5営業日で、欠陥の修正、合意した修正分の再テスト、リリース承認の時間を別に確保します。残り期間が短い場合は主要フローと除外範囲、修正可能な時間を一緒に定め、結果を反映できる日程を確保します。契約とアクセス権限の発行にも数日かかります。社内網のアカウント、テスト環境、決済や外部連携のサンドボックスキーは、依頼した日に出ないことが多いためです。出荷日が決まった時点で検収の着手日も一緒に押さえておけば、この区間が日程の外に押し出されません。逆に出荷日がまだなら検収を急ぐ理由もありません。範囲を広く取って回帰まで扱う方がよく、それはこのサービスではなく期間型の契約が担います。継続的に出荷する製品でも判断は同じです。毎スプリントのビルドを単発検収で受けると着手手続きが毎回繰り返され、金額が実行量より速く増えます。単発検収が合う場は、日程の決まった大きなリリース、納品直前の独立検収、そして検証なしに積み上げてきた製品を一度立て直す時点です。

社内QAがあるチームも、開発から独立した視点で検証根拠を追加するために外部検収を利用します。社内と外部の結果には、どちらも合意した基準と再現可能な証拠が必要です。納品を受ける側は開発会社の結果を検収要件と照合し、独立した再確認が必要な範囲を定めます。社内チームとの分担は着手前に文書で分けます。社内が引き続き持つ領域と渡す領域を分け、欠陥の重大度の物差しと報告様式は一つに統一します。同じ欠陥に二つの組織が違う等級を付ければ、リリース会議は根拠ではなく等級を争います。社内が機能回帰を回し、外部がリリース候補だけを見る分担が最も多い形です。専任がまったくいないチームでは、判定の物差しから一緒に決めることになります。何が出荷を止める欠陥なのかが決まっていない状態では、結果表が出ても会議は同じ場所を回ります。

検収が始まるには三つが要ります。一つ目はリリース候補ビルドと、それが動く環境です。接続経路とアカウント、試験用データ、初期化の方法まで一緒に渡します。二つ目は主要フローの指定です。この製品で壊れたら出荷を延ばすフローはどれかを発注側が選びます。加入と決済、注文完了のように金と信頼がかかる経路がおおむね先に来ます。三つ目は判断材料です。要求事項の文書や画面設計があればそのまま預かり、なければ画面から逆に要求事項を復元する時間が範囲に入ります。文書がなくても検収はできますが、同じ金額で見られる幅は狭くなります。前回リリースの欠陥履歴と最近手を入れた領域の一覧があれば優先順位が変わります。直近の変更分と過去によく壊れた場所は実行順を前に繰り上げます。生成系ツールで速く作った製品ではこの材料がとりわけ効きます。コードを作った側が例外経路を説明できない状態では、要求事項に書かれていない条件から洗うことになり、その作業が実行時間のかなりを占めます。準備物が遅れて届くと、伸びるのは検証期間ではなく待機期間です。着手日の前にアクセス権限が実際に開くかを一度確かめておくのが、日程を守る最も安い方法です。

金額と日程を同時に決めるのは五つの数字です。対象ビルド数、製品領域数、主要フロー数、合意したシナリオ数、再テスト回数。最も狭い構成はビルド一つと製品領域一か所で主要フロー一つとシナリオ十件を見て、再テストを置きません。基本の構成は5営業日でビルド一つと製品領域一か所、主要フロー三つとシナリオ三十件を実行し、合意した修正分を一度再テストします。広い構成は製品領域二か所と主要フロー五つ、シナリオ五十件まで上がります。この五つの数字と金額を着手前に書面で確定するので、検証が長引くほど費用が増える構造ではありません。除外範囲も同じ文書に書きます。セキュリティ認証やコンプライアンス適合性は判定せず、コード品質も評価しません。検収の名で期待されながら実際には別の仕事である項目を手前で切っておけば、終了時点で揉めません。性能と負荷、障害復旧の検証もここで分かれます。負荷モデルを作る準備が実行より大きい別の仕事なので、同じ金額の中に入れません。

検収が終わると三つが残ります。一つ目はテストケースとシナリオの資産です。主要フローの中で何をどの条件で確かめたのかが文書として残り、次のリリースでそのまま回ります。二つ目は欠陥台帳で、見つけた欠陥ごとに重大度と再現条件、引っかかったフローが付きます。三つ目がリリース判定メモです。シナリオ別の結果と確認できなかった領域、残ったリスクを一枚に収め、READY・READY WITH CONDITIONS・HOLDのいずれかで判定します。判定には人が署名します。検証結果と除外範囲、前提と残存リスクを検討したうえで、シン・ミンギュCTOがリリースメモに署名します。READY WITH CONDITIONSなら何が満たされれば出荷なのかが同じ欄に書かれ、HOLDなら何が揃えば再び判断するのかが書かれます。確認できなかった領域を判定と同じ紙に置くことがこの文書の要です。検証していない場所を書かない報告書は、合格率を実際より広く読ませます。

検収は結果表を受け取る仕事ではなく、判定を受け取る仕事です。通過件数と失敗件数だけが渡されると、その数字を読んで出荷を決める役目が発注側に戻ってきます。提案書で確かめることは三つです。一つ、判定の語彙が文書に先に定義されているか。READY・READY WITH CONDITIONS・HOLDのように値が固定されていれば、会議で解釈が割れません。二つ、確認できなかった領域が結果と同じ文書に書かれるか。三つ、誰が署名するか。署名者の経歴と、その人が実際にプロジェクトを読むのかを尋ねれば、判定を売る先と実行だけを売る先が分かれます。見積もりを比べるときは、範囲の五つの数字が書かれているかをまず見ます。期間と人数だけで五つの数字が空なら、それはまだ見積もりではなく見込みです。問い返して数字を受け取ると、候補の間の金額差の大半が実力差ではなく範囲差だったことが見えます。再テストの有無と資産の引き継ぎ条件も同じ場で確かめます。実行したシナリオと欠陥台帳が文書ファイルと元データで一緒に渡らなければ、次のリリースで同じ金額をもう一度払います。

検証期間を尋ねる問いには、たいてい五つの数字で答えが出ます。それでも同じ五つの数字から期間が開く変数が四つあります。一つ目は環境の組み合わせの数です。ブラウザとOS、端末とアプリ版が掛け算で増えれば、シナリオ一つが何度も実行されます。金融や公共のように対応組み合わせが広く取られた製品で最も開きます。二つ目は欠陥の密度です。欠陥が多く出れば、再現条件を絞って記録する時間が実行時間を超えます。三つ目は事前条件を作る費用です。アカウントや商品、注文といった状態を毎回手で作る製品は、同じシナリオでも長くかかります。四つ目は修正が反映される速さで、再テストは開発が直して上げ直した後にしか始まりません。出荷日が迫っているなら、フロー数を減らすより製品領域を一つに絞る方がよい判断です。領域を狭めれば事前条件と環境の組み合わせも一緒に減って実行密度が上がり、見ないと決めた領域は次のリリース検収の最初の候補として残ります。