リスクとテストの計画

時間は限られているので、すべてを同じ深さでテストすることはできません。リスクベースのテストは、「壊れたときの影響の大きさ」と「壊れやすさ」から優先度を決め、リスクの高いところに時間を使う考え方です。

リスクの洗い出し

• 影響の大きさ：お金（決済・請求）、個人情報、法律にかかわる、多くの利用者が使う、元に戻せない（データの削除・送信）。
• 壊れやすさ：今回大きく変えた、複雑（条件が多い）、新しい技術や外部サービスとの連携、過去に不具合が多かった、担当者が初めて触った。

開発者・PdM と一緒に、変更点ごとに「影響」と「起こりやすさ」を高・中・低で付けると、優先度を合意しやすくなります。

テスト計画に書くこと

テストレベルは、どの大きさの単位を確かめるかによるテストの分け方です。作る段階と確かめる段階を対応させた V字モデルで説明されることが多いです。

アジャイル開発でも、各レベルの考え方はそのまま使います。違うのは、レベルごとに工程を分けず、1つの機能の中で並行して進めることです。

テストレベルとは別に、何のために確かめるかでもテストを分けます。名前が似ていて混ざりやすいので、面接でもよく確かめられます。

不具合の修正のあとは、確認テストで「直ったか」を見るだけでなく、回帰テストで「直したことで別の所が壊れていないか」も見ます。修正は急いで入ることが多く、回帰が起きやすいからです。

テスト計画は、何を・どこまで・どうやってテストするかをチームで合意するための文書です。リスクの洗い出しの結果をもとに作ります。

テスト計画には、少なくとも次を書きます。長い文書でなくてよく、チームが同じ認識を持てることが大事です。

• 範囲：テストすること・しないこと（しない理由も）。
• 方法：どのリスクをどのテスト（自動・手動・探索的・負荷など）で確かめるか。
• 環境とデータ：使う環境、テスト用のアカウントやデータ。
• 日程と担当。
• 開始・終了の基準：例「重大な不具合が 0 件、高の不具合は回避策があり合意済み、主要なシナリオがすべて通った」。

落とし穴：「テストしないこと」を書かないと、後から「そこは見ていると思っていた」となります。省いたリスクは、リリース後の監視や段階的なリリースで補うことも計画に入れます。

開始基準は「テストを始めてよい状態」、終了基準は「テストを終えてよい状態」の約束です。前もって決めておくと、期日が迫ったときに感覚で判断せずに済みます。

リリースするかどうかを最終的に決めるのは、多くの場合 PdM や責任者です。QA の役割は「止める・通す」を一人で決めることではなく、残っているリスクを事実で伝え、判断を助けることです。不具合が残ったままリリースするなら、影響・回避策・直す予定・監視の方法をセットで示します。

回帰テストを毎回すべて手動で行うことはできません。変更の影響が届く範囲をたどって、近いほど厚く、遠いほど自動テストに任せます。

毎回必ず流す主要な流れ（ログイン・検索・購入など）は自動化し、変更ごとに足す回帰テストは影響の範囲から選びます。選んだ理由を計画に残しておくと、不具合が漏れたときの振り返りに使えます。

アジャイル開発（スクラムなど）では、短い期間（スプリント）ごとに作って確かめるので、「開発が終わってからテスト」では間に合いません。QA はスプリントの最初から関わります。

テストがスプリントの最後に集中すると、次のスプリントに持ち越されて品質の借金がたまります。ストーリーを小さく分けて、できたものから順に確かめるのがこつです。

テストする環境は、本番に近いほど本番の不具合を見つけやすくなりますが、作るのも保つのも大変です。どの環境で何を確かめるかを決め、本番との差を知っておくことが大事です。

プルリクエストごとに一時的な環境（プレビュー環境）を作るチームも増えています。複数の人が1つの検証環境を取り合って、データが壊れる問題を減らせます。