私が所属する事業会社では自社サービスを運営しており、受託開発のような決められた納品日や予算（テストにかけられる工数）が殆どありません。どの程度テストを実施するかはQAエンジニア自身が最終的に意思決定をすることになります。テスト量を増やせば欠陥を検出できる可能性は高まりますが、その分リリースが遅れて機会損失が発生します。そのため、会社の利益を最大化するためには、なるべく最低限のテストで品質を担保しなければなりません。そこで、本記事では私が最低限のテストを選ぶために行なっている工夫を紹介します。なお、必ずしも記載している順番で行う必要はありません。*1

目指す品質（テストで担保する品質）を決める

最初に目指す品質を決めてテストでどこまで品質を担保するかを決めます。例としては、以下のようなことを決めます。

売上とテスト実施コストの損益分岐点を探す
- Webサイトのアクセスシェアが0.5%未満のブラウザはテストしない
想定ユーザーが行う操作方法の境界を探す
- ユーザーはITリテラシーのある社内の人なので、通常のオペレーション以外の組み合わせはテストしない
リリース時のプロダクトの目的を達成するために必要な品質を目指す
- ユーザーインタビューのためのプロトタイプなので、ハッピーパスのみテストすれば良い
本番障害時のユーザー影響度合いに応じて目指す品質を決める
- ユーザーの業務に支障が発生する本番障害は生じさせないようにテストする。軽微な表示崩れは細かく見ない
- 高級ブランドのWebサイトなので、ブランドイメージを損なう表示崩れは軽微なものでも許容しない
- ECサイトなので常にサイト表示は1秒以内に完了する
  - 参考：サイト表示が2秒遅いだけで直帰率は50％増加！ DeNA事例から学ぶWebの自動最適化手法／日本ラドウェア | 【レポート】Web担当者Forumミーティング 2014 Spring | Web担当者Forum

プロダクトリスクの大きさや予測される障害を分析してテスト量のメリハリをつける

不安なところをなるべくテストするというのは感覚的にも考えると思いますが、不安なところ（プロダクトリスク）を言語化すると

プロダクトリスク = 欠陥混入時の損失 × 欠陥混入の確率

などのような計算式でプロダクトリスクの大きさを分析し、以下のようにテスト量のメリハリをつけることが多いと思います。

プロダクトリスクの大きい箇所には手厚いテストを実施する
プロダクトリスクの小さい箇所には少しのテストを実施する
プロダクトリスクがほとんどない箇所はテストを実施しない

私の場合は、コードの品質が一定以上という前提ですが、上記に加えてコードの具体的な改修箇所や改修内容から予測される障害も考慮します*2。修正されたコードを確認せず想像でテスト量を削減するのはリスクが高いのでやめましょう。

例としては、以下のようなものがあります。

CSS, HTML, JavaScriptの修正はないのでブラウザ依存の障害は発生しないと予測。そのため、クロスブラウザでのテストは実施しない
商品の表示内容を出し分けるロジックの前に修正を入れたので、障害が生じるとしたら条件に関係なく商品が表示ができなくなると予測。そのため、商品の表示内容出し分けの各条件を網羅的にテストはしない
商品の表示内容を出し分けるロジックの前に修正を入れた場合でも、欠陥混入時の損失が大きいので念のため各条件も網羅的にテストをする。

テストはなるべく小さい部品単位で行う

部品とは、関数、API、1つの画面、機能（購入フローなど複数画面で構成されるもの）などサービスを構成する要素のことです。

部品単位で正常に動作することを確認できた場合、部品を結合させても部品単体の処理は正常に動作するということを期待します。各部品同士で出力内容の依存関係がない（疎結合である）という前提がないと、上記の期待は成立しないので注意してください。また、内部構造を把握しないまま想像で部品を決めてテストをするのはリスクが高いのでやめましょう。

部品単位でテストを行う例は以下の通りです。

購入代金の計算処理はユニットテストで網羅的にテストしているので、UIでのテストでは代表的な購入条件のみテストを行う
画面Aの商品一覧と画面Bの商品一覧は同じロジックを利用しているので、画面Aの商品一覧のテストでロジックを網羅的にテストできれば画面Bの商品一覧のテストは少なくて良い
- 「テストは単純作業ではなく創造的な活動だ」という意識を浸透させた物語 #RSGT2021 / Testing is the creative activity - Speaker Deck
画面Aの商品一覧と画面Bの商品一覧は表示内容は殆ど同じだが、商品一覧のロジックは各画面で個別実装されている。そのため、画面Bの商品一覧のテストと画面Aの商品一覧のテストは両方網羅的にテストする必要がある。というパターンもあるので注意が必要。
膨大になったデシジョンテーブルの圧縮
- 参考：http://www.jasst.jp/symposium/jasst19tohoku/pdf/S5-1.pdf

小さい部品単位でテストを行うと、以下のようなメリットがあります。

テスト実行環境を用意するコストが少ないことが多い
テスト実行工数が少ないことが多い*3
テストする条件が複雑にならない
- 部品Aの入力は5パターン、部品Bの入力は4パターンある場合に、部品ABを結合してテストする場合は20パターン（5*4）、部品ABを別々にテストする場合は10パターン（5+4+結合時の確認で1パターン）となる

なお、部品単位で確認できないこと（例えば、外部のSaaSとの連携、想定されるユースケースを実現できるかなど）は部品を結合した状態でテストを行います。