致命的な不具合がリリース後に発覚する原因とは | Never・Must・Wantの思考法で品質を体系化する

システムが仕様通りに動作することを確認してもなお、リリース後に不具合が発覚し、対応に追われる開発現場は少なくありません。

こうしたトラブルの背景には、「必要なテスト観点やその優先順位をチーム内で整理できていない」という問題があります。

特に観点の整理が不足しやすいのが、誤操作や例外的な環境下での挙動を確かめる「異常系」のテスト。システムの破壊や金銭関係のエラーといった重大な不具合を事前に発見するためには、開発者が想定していない手順での操作や不正な入力などを含めた広範な検証が求められます。

本記事では、品質保証の土台となる「Never・Must・Want」の考え方を軸に、必要なテストを網羅するためのテスト設計の方法を解説します。

第三者検証の重要性｜資料ダウンロード

「異常系テストの不足」が起きるのはなぜなのか？

「本番稼働で深刻な不具合が発覚する」という事象の背景には、正規の手順・入力内容に対する出力を確かめる「正常系」以外の条件下での挙動を確かめる異常系テストが不足しているという問題があります。

まずは、異常系テストの不足をもたらす典型的な原因について整理します。

開発者による先入観

プログラマーは、自分が設計・実装したシステムについて「こう組んだからこう動くはず」という前提が頭にあることがほとんどです。そのため、開発者がテストを兼ねる体制下では、想定外の状況に対する検証が抜け落ちやすく、テストが不十分なまま次工程に進んでしまうケースが少なくありません。

一方で、近年のシステムは、複数のシステムが連携したり、データベースの構造が複雑化したりと、単純な前提ではとらえきれない挙動を示すことがあります。

特に不特定多数のユーザーが使うBtoCアプリでは、開発者が意図していない操作が予期せぬトラブルを引き起こすことも多く、開発者視点から離れた観点の設定が欠かせません。

開発の長期化によるスケジュールの圧迫

品質保証体制が確立されていない現場では、開発スケジュールの遅延によってテスト期間が予定より短縮される傾向が見られます。

特に、開発者がテストを兼ねている場合、開発者判断で実装の工程が長期化し、テストに使える時間・リソースが最低限しか残らないことが少なくありません。結果として、「正しく入力すれば動作する」といった正常系の確認に終始し、誤操作時や例外的な環境下での挙動の検証が不足してしまうのです。

「何を優先してテストすべきか」基準がない

正規の手順に沿って動作確認を行う正常系テストに対し、異常系テストでは検証すべき入力パターンが無数にあります。例えば、ログイン機能をテストする場合、正常系テストでは「正しいログインIDとパスワードを入れたらマイページに遷移する」という単一のテストケースを実行すれば十分な場合がほとんどです。

一方で異常系テストでは、「ログインIDが違う場合」「パスワードが違う場合」「ログインボタンを2回押した場合」「通信が途切れた場合」など、さまざまなパターンを検証する必要があります。

このため、多くの開発会社が、異常系テストの重要性を認識しながらも「限られたリソースのなかで、何を優先してテストすればいいかわからない」という状態に陥っています。

テスト設計の土台となる「Never・Must・Want」のフレームワーク

これまで述べてきたような問題を解消し、プロダクトの品質を確保するためには、品質要件を体系的に整理したうえで、「何を優先的にテストすべきか」を明確にする必要があります。

そこで取り入れたいのが、品質要件を「Never・Must・Want」の3つに整理する考え方です。

Never（起きてはならないこと）
システムの安全性・信頼性に直結する重大リスクに関する項目

Must（必ずできるべきこと）
システムが本来の目的を果たすために必要な項目

Want（必須ではないが、できるとよいこと）
ユーザー体験向上のために確認したい項目

ここからは「Never・Must・Want」それぞれの品質要件について、具体例とともに解説していきます。

Never＝起きてはならないこと

Neverは、該当プロダクトの運用にあたって「起きてはならないこと」を指します。システムの安全性や信頼性に直結する要件であることから、異常系テストで検証されることが多い領域です。

Neverに含まれる品質要件としては、主に以下の3つが挙げられます。

• 生命に関わる事項（医療システムや自動車など、人命にかかわるシステムでの誤作動）
• 金銭に関わる事項（二重決済、金額計算の誤り）
• データベース・システムの破壊につながる事項

そのほか、セキュリティや通信障害時の挙動など、プロダクトの目的や性質に応じてさまざまな観点を考慮する必要があります。

Must＝必ずできるべきこと

Mustは、「そのプロダクトが本来の目的を果たせること」を指し、主に正常系のテストケースで扱われる品質要件です。

具体例には、次のような例が挙げられます。

• 温度表示システム
  →該当時刻での正確な温度が表示される
• 在庫管理システム
  →リアルタイムで正確な在庫数を反映できる
• 予約システム
  →ユーザーの予約情報がデータベースに登録され、画面に表示される

一見すると、言語化するまでもない要件にも思えますが、開発側として目の前の実装に集中していると、こうした本来の目的を見失ってしまうことも珍しくありません。最低限の商品価値を確保するために、テスト設計の段階であらためて要件定義書に立ち返ることが重要です。

Want＝必須ではないが、できるとよいこと

Wantは、ユーザー満足度を高める“プラスアルファ”の観点であり、競合プロダクトとの差別化や商品の訴求ポイントにつながります。ターゲットユーザーの属性や利用シーンなどに基づき、「どんな要素があればより使いたくなるか？」を考えてテストを設計していきます。

具体的には、次のような観点があります。

• 応答速度は十分か
• 表示がわかりやすいか
• ユーザーに無駄な手間をかけさせる部分がないか

Wantの品質は、競争優位性を高めるために重要な項目ではあるものの、理想に達していなくても商品としては成立します。テストに使えるリソースがひっ迫している場合には、Wantに関わるテストは後に回し、Never / Mustに該当するテストから実行していくことになります。

致命的な不具合を残さないテスト設計のポイント

最後に、「Never・Must・Want」のフレームワークを踏まえ、本番稼働時に致命的な不具合を残さないテスト設計のポイントを解説します。

異常系を含めて必要なテストを抜け漏れなく実施するには、主に以下3つのポイントが重要です。

NeverとMustの明確化

致命的な不具合を防ぐためには、設計段階で「何が起きてはならないか」と「必ずできるべきことは何か」を明確にすることが重要です。

Neverに関しては、「システムの破壊」「生命に関わる事項」「金銭に関わる事項」といったシビアな観点を中心に、そのプロダクトで発生してはならない事象を洗い出していきます。Mustについては、ユーザーがプロダクトを通じて達成したい目的を明確にしたうえで、達成に向けて欠かせない要件を整理します。

NeverとMustのテストを抜け漏れなく実行することで、開発工程で多少のトラブルや遅延があっても、一定の商品価値を確保した状態でユーザーに届けられます。

発想の転換

重大なインシデントを防ぐNeverのテスト設計では、開発側が持つ「こう使ってほしい」という視点から一度離れて、実際に発生しそうな誤操作や通常は行われない操作を試してみる必要があります。

例えば、「Android用に作られたシステムに、iPhoneを接続してみる」「ドロップダウン形式で選択させるフォームに、直接文字を入力してみる」「本来1回しか押さないボタンを10回押してみる」といった異常な操作をあえて実行し、さまざまな状況下でのエラーハンドリングを確認していくのが効果的です。

特に不特定多数のユーザーが使用するBtoCプロダクトのテストでは、「こんな使い方はしないだろう」という思い込みを排除し、多様な使い方を想定することが網羅性の高いテスト設計のカギとなります。

設計段階からのリスク回避

非正規的な入出力による重大な不具合を回避するためには、そもそもテスト以前に設計段階で適切な対策が講じられている状態が理想的です。はじめから事故を起こしにくい設計にすることで、テストの工数を抑えつつ、安全性の高いプロダクトに仕上げられます。

具体的な対策の例としては、以下のような施策が考えられます。

• 異常な入力を受け付けないバリデーション機能の実装
• リスクの高い操作（削除、決済など）に対する確認ダイアログの表示
• 誤操作を防ぐUI設計（ボタンの配置、色の使い分けなど）

プロジェクト初期から開発チームとQAチームが連携し、品質保証の観点を取り入れて設計を進めることで、根本的な問題の解消につなげられます。

異常系テストの網羅性を高め、品質の高いプロダクトを作る

「テストを実施したにもかかわらず、本番稼働で不具合が起きる」という問題の背景には、テスト観点の漏れ、特に異常系テストが十分に行われていないという原因があります。

Never・Must・Wantのフレームワークに基づき、「起きてはならないこと」「必ずできるべきこと」の整理から始めて、優先度の高いテストを確実に実施することで、致命的な問題を未然に防いでいきましょう。

なお、正規のフローを実行する正常系テストに対し、異常系テストには無数の観点があり、抜け漏れないテスト設計のためには一定の知見が求められます。テストケースの網羅性に不安がある場合は、専門的な知見を持った第三者機関との協業も有効な手段の一つです。

AGESTでは、テスト戦略の立案から設計・実施まで、お客様の状況に合わせた品質保証活動を支援しています。自社のテスト設計に課題をお持ちの方は、ぜひ一度AGESTにご相談ください。

ソフトウェアテスト サービス詳細ページ

TFACT (AIテストツール)

関連コンテンツ