結論から言えば、ソフトウェアテストと品質保証は納品前の最終工程ではありません——リリース後にシステムがどれだけのコストをもたらすかを決めるものです。予算がまったく同じ二つのシステムは、ある一点で分かれます。顧客より先に不具合を見つけるテストカバレッジを備えて構築されたのか、それとも顧客自身がテストスイートになっているのか。前者なら、品質の対価は開発中に一度払うだけです。後者なら、障害、緊急修正、そして損なわれていく信頼という形で毎月支払うことになります。

QAとは「納品前に誰かがあちこちクリックすること」ではない

経営者の間でよくあるイメージは、品質とはプロジェクトの最後の週に一人の担当者が画面を開いてボタンを押すことだ、というものです。それは品質保証のごく一部であり——しかも最も効果の低い部分です。本当の品質保証は初日から動き続ける仕組みです。テスト可能なほど正確に書かれた要件、変更のたびに実行される自動テストでカバーされたコード、本番環境を再現したステージング環境、そしてこれらの関門を通過するまで変更を本番に到達させないデプロイ経路です。

実務上の違いは単純です。前者の体制では、不具合は書かれてから数分で表に出ます。後者では、一か月後に顧客がそれを見つけ、その頃にはあなたは同じ誤りの上にほかの機能をいくつも積み上げてしまっています。

意思決定者として押さえておくべきテストの層

技術的な詳細を知っている必要はありませんが、自分が何に対してお金を払っているのかは知っておくべきです。真剣な技術提案であれば、次の層を明示しているはずです。

  • 単体テスト：最小単位のロジックを切り離して検証します。最も速く安価なテストであり、小さな変更によって請求書の合計、割引、税額計算が壊れるのを防ぐのはこれです。
  • 結合テスト：各部分どうし、そして外部システム——決済ゲートウェイ、配送、請求書発行プラットフォーム、メッセージング——と正しくやり取りできるかを検証します。現実の障害の大半はコードの内部ではなく、ここで起きます。
  • エンドツーエンドテスト：ページを開くところから注文を確定し通知を受け取るところまで、ユーザーの一連の行動を最初から最後まで再現します。
  • 性能テストと負荷テスト：ほかのどのテストも答えられない問いに答えます——同じ一分間に十人ではなく千人のユーザーが訪れたら何が起きるのか？ これこそチームが省略しがちな層で、その結果、最大のキャンペーン当日にシステムが落ちるのです。
  • セキュリティテスト：一般的な脆弱性を、ほかの誰かに見つけられる前に洗い出します。実務上の基準は、Webアプリケーションの重大リスクをまとめた OWASP Top 10 です。テスト計画にこれが明記されていれば、成熟度の明確なサインです。
  • ユーザー受け入れテスト：開発者が用意した理想的な台本ではなく、実際の業務シナリオに沿って、あなたとあなたのチームがシステムを動かします。この段階はあなたの責任であり、これより前に検収を行うべきではありません。

不具合は見つかるのが遅いほど高くつく理由

ソフトウェアプロジェクトを運営したことのある人なら、この法則を知っています。要件を書いている段階で見つかった不具合は、一文を書き直すだけで直せます。同じ不具合がリリース後に見つかれば、原因調査、修正、再テスト、再デプロイが必要になり——たいていはその過程で壊れたデータの修復と、影響を受けた顧客への謝罪も加わります。問題は、この差が見積書には決して表れないことです。そのため、テストを範囲から外したベンダーのほうが安く見えます。実際には、請求を先送りし、しかも膨らませただけなのです。

自動テストと手動テスト：それぞれの使いどころ

手動テストは、ユーザー体験、境界ケース、そして人間の判断を要するあらゆる事柄を評価するうえで欠かせません。しかし、恒久的なセーフティネットにはなりえません。小さな変更のたびに二百もの画面を手作業で確認し直す人などいないからです。継続的な開発を可能にするのは自動テストです。テストを一度書けば何千回も実行され、今日の変更がチームの一年前に作った機能を壊していないかを数分で教えてくれます。実務上の原則は、お金やデータに関わる繰り返し作業はすべて自動化し、製品の使い心地に関わることはすべて人間の判断に任せることです。

テストデータに注意する

多くのチームが検討もせずに見過ごしている問題があります。開発者がテストできるように、本番データベースをステージング環境にコピーすることです。これは、顧客の氏名、電話番号、住所が、アクセス範囲が広く保護の弱い環境に置かれることを意味します。サウジデータ・人工知能庁（SDAIA）が所管するサウジアラビアの個人データ保護法は、データを保持する環境を何と呼ぶかにかかわらず、個人データの処理を規制しています。対策はシンプルでよく知られています。合成的に生成したデータを使うか、コピー前に機微な項目をマスキングした実データを使うことです。

契約前にベンダーに求めるべきこと

  • 「システムはテストします」という口約束ではなく、作業範囲に含まれた書面のテスト計画。
  • 継続的インテグレーションのパイプラインを通じて変更のたびに自動実行され、テストが失敗したらデプロイが止まる仕組み。
  • 顧客向け環境とは別のステージング環境と、そのデータの出どころについての明確な説明。
  • 割合と傾向の両面から読む定期的なカバレッジレポート。システムの成長に合わせてカバレッジは上がっているのか、それとも下がっているのか。
  • 何が無償で修正される不具合で、何が新たな開発依頼にあたるのかを定めた、リリース後の保証期間。

プロジェクトで品質が軽視されているサイン

技術的な素養がなくても見抜けます。修正するたびに別の箇所が壊れる、デプロイの前には毎回チームに目に見える緊張が走る、「動いているし、何に影響するかわからないから」と誰も古いモジュールに手を出そうとしない、そして障害を知らせてくるのが監視の仕組みではなく顧客である。これらは別々の問題ではありません——チームが自信を持って変更できるようにするテストの網が欠けていることの症状なのです。

Origamiでは、テストカバレッジをサポート費用の一項目ではなく、製品の一部として扱っています。二年後に安全に手を入れられないシステムは、納品日にどれほど立派に見えたとしても、成功したシステムではありません。

出典