はじめまして、QAコンサルタントのヤスゴロウです。今回は私の経験に基づくテストのアプローチ方法をご紹介させていただきます。
テストベースがないシステム
昨今のシステム開発事情
デジタル化が進んだ昨今では新規システム構築は稀で、既存システムのマイグレーションや既存システムの改修・保守開発(※2）が多いと感じております。例えば、システム利用者のフィードバックを受け、改善のための改修・保守開発を繰り返してサービス向上やユーザビリティ向上等をおこなっているようなケースです。
こういった背景の中、弊社へいただくQAコンサルタントやテスト実施のご相談は、既存システムの不具合に悩まされている場合が多い気がしております。
しかもその既存システムに対して改修・保守開発を繰り返しているうちに、サブシステムが増えたり機能間の関係や仕様が複雑になったりする等の理由で、現在の開発担当者が全仕様を把握できていない状況をお見かけすることがあります。
とはいえ、競争の激しい現代においてビジネスを成功するためには、改修・保守開発をスピーディかつ不具合なく実施しなければいけないという使命があるため、大変な世の中だなと改めて思ってしまいます。
私も前職で15年程SE/PGや開発PMに従事しておりましたので、システム開発に携わっている方々の痛みに共感しております。
また、改修・保守開発は長期に渡っている場合があるため、ずっと同じ担当者が開発しているとは限らず、有識者の退職により全仕様を把握している方がいないというようなことはよくあることです。
このような事情から
・改修箇所の影響範囲の特定がうまくできない。
・隠れ仕様に気づかず、設計、実装、テストの考慮漏れが発生する。
等の原因で本番障害が発生し、既存システムの品質改善や品質向上に悩みを抱えている企業様もいらっしゃいます。現代は避けたくても避けられない道なのかもしれません。
なぜテストベースがない場合があるのか
前述のような昨今のシステム開発事情より、テストベースとなるシステムの最新ドキュメントがない理由は大きく2つあると私は解釈しております。
1.引継ぎ情報不足
長期に渡り改修・保守開発を繰り返していると、開発担当者の入れ替えがあり、引継ぎがうまくできないケースがあると思います。
システムが大きくなればなるほど全仕様を理解することが難しいため、既存ドキュメントを改修する知識が不足し、また正しく更新する自信がないことにより、その時の改修箇所（差分）のみしかドキュメントを書かなくなってしまうのではないかと思います。
2.時間
ビジネスの機会損失を避けるためにシステムリリースのスピードを優先することがあります。動くもの（プログラム）は必須で新しくなっていきますが、そのベースとなる要件定義書や設計書等のドキュメント修正は「時間がないため後回し」にしてしまう場合があります。後で修正しようと思っていても、次のリリースの開発に追われ、ずっと修正できなくなってしまうケースもあると考えます。
また、ちょっとした改修の場合は、簡単なメモ程度で仕様を決めて済ましてしまう場合もあるかもしれません。理想は既存システムのドキュメントを更新して常時最新仕様を理解できるドキュメントを保持することですが、上記のような理由によりドキュメントを最新化できなくなっているのではないでしょうか。
テストベースが無いとどう困るのか
改修・保守開発を繰り返しているシステムにはテストベースとなる最新ドキュメントがない場合があることをお話してきました。では、なぜQA担当者はテストベースが無いと困るのでしょうか。
テストを実行するためには、まずシステムの正しい仕様を理解する必要があります。そして仕様に沿ってテストケースを作成し、「何を以って合格とするか」の基準となる「期待する結果」を定義する必要があるため、そのよりどころとなる情報が無いということになってしまいます。
特に、第三者検証の会社にテストを依頼する場合は、仕様を把握するためのテストベースとなる最新ドキュメントが原則必要となります。
必要なテストベースは実施するテストレベル(※3)にもよりますが、例えば利用者目線で業務の流れを一通りテストしてほしいというご依頼であれば、業務フローや業務ルール（処理の分岐条件等）を理解できるドキュメントをご提供いただきたいです。ですが「テストを実施してほしいが、最新仕様を理解できるドキュメントは無いです」と言われてしまった場合、どうすればよいでしょうか？
どういうアプローチがあるか
アプローチのアイディア
私が担当したWebサイトのプロジェクトでテストベースがなかった時のアプローチをご紹介します。
私はJSTQBで学んだ「テストオラクル(※4)」が使えるのではないかと考え、探してみることにしました。テストオラクルになりそうなものはないか調べた結果、以下3つのものを使用しました。
(1) Webサイト上に公開されている説明やFAQ
(2) 運用担当者やシステム管理者向けの業務マニュアル
(3) 過去の障害事例
テストオラクルを使ってみる
まずは、「利用者に公開している(1)Webサイト上に公開されている説明やFAQの通りに動作しなければ不具合である」とする作戦が良いと考えました。幸いお客様にも良いアイディアだと言っていただけたので、早速テストエンジニアに実践してもらいました。残念ながら(2)は最新なのか分からないものが多かったのですが、Webサイト上に書いていない条件分岐になる業務ルールは正解と見立てて参考にしました。(3)からはテストしたい業務に関係する実際にあった障害をピックアップし、障害が発生した画面操作手順や業務の流れを理解して、テスト条件や期待する結果を検討するための参考にしました。
設計書等のドキュメントに書かれた仕様通りに開発されていることだけが正解ではなく、Webサイト上で利用者向けに告知していることが期待通りにできなければNGにしようと考えたら、あとは意外とスムーズに進みました。
テスト設計の具体例
では、どのようなテスト設計の考え方があるのか一例としてECサイトを例にご紹介させていただきます。皆さんもECサイトで買い物をすることがあるかと思いますが、注意して読んでみると以下のような「業務ルール」と思われることが書かれている場合が多いです。
・XXXX円以上購入すると送料無料
・当月XXXXX円以上購入すると翌月顧客ランクアップ
・離島など地域によって特別送料を課金
・配送方法（種類）を選択
・決済方法（種類）を選択
・在庫切れの場合
・到着前にキャンセルする場合
・返品する場合
等です。
前述の「(1)Webサイト上に公開されている説明やFAQ」を読み込むと、たくさんの業務ルールがあることに気が付きます。業務ルールをデシジョンテーブルのようなマトリクス表に整理するとテストケースを作成できるようになります。
具体的なイメージをもっていただくために以下に簡単な例を挙げさせていただきます。
例）ECサイトで送料無料になる条件
・顧客ランクがプラチナの場合
・顧客ランクがゴールドの場合、かつ１注文あたりの購入金額が5000円以上の場合
・顧客ランクがシルバーの場合、かつ１注文あたりの購入金額が10000円以上の場合
得られるテスト結果の例（メリット）
私もプロジェクトにおいて、前述のような考え方でテストオラクルから業務ルールを洗い出してテストケースを作成し、テストを実行したら、それなりに不具合を挙げることができました。不具合を一覧にしてシステムの有識者に確認していただいた結果、「サイト上に公開されている説明やFAQ」の方が誤っている場合もあり、サイト上の表記を修正することで、品質向上につながりました。。
その他、長期に渡り立ち止まることなく改修・保守開発を繰り返しているシステムの品質を認識できる良い機会にもなりました。「思っていた以上に潜在不具合があったのだね・・・」というような感想をいただくこともありました。また、最新のテスト設計書ができあがったことにより、システムの有識者以外の方が仕様理解に活用できるようになりました。
まとめ
・長期に渡り改修・保守開発を続けている既存システムのテストはテストベースとなる最新ドキュメントがない場合が多く難易度が高いが、工夫すれば品質向上のための強化テストを実施することができる。
・テストベースが無い場合は、いかに適切なテストオラクルを見つけ出して妥当な「期待する結果」を導出するかが重要である。
・場合によっては仕様理解用のドキュメントとしてテスト設計書が利用できることもある。
今回ご紹介したWebサイトのようなフロントシステムの場合はテストオラクルが探しやすいと思いますが、目に見え辛いバックエンドシステムの場合にはどのようなテストオラクルを見つけ出せるのか、今後の課題として取り組んでいこうと考えております。
APPENDIX:用語の説明
※1 テストベース
「テスト分析と設計のベースとして使用するあらゆる情報」（ISTQB Glossaryより引用）具体的には、以下のようなものである。
・要件仕様。ビジネス要件、機能要件、システム要件、ユーザーストーリー、エピック、ユースケースの他、コンポーネントやシステムに期待される機能および非機能の動作を指定する類似の作業成果物などがある。
・設計および実装情報。システムやソフトウェアに関するアーキテクチャー図もしくはドキュメント、設計仕様、コールフローグラフ、モデル図（UMLやER図など）、インターフェース仕様、コンポーネントもしくはシステムの構造を指定する類似の作業成果物などがある。
・コンポーネントまたはシステム実装そのもの。コード、データベースのメタデータやクエリー、インターフェースなどがある。
・リスク分析レポート。コンポーネントやシステムの機能、非機能、構造の各側面を考慮する。
出典：ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018V3.1.J03「1.4.2 テストの活動とタスク」
※2 改修・保守開発
IPAのソフトウェアデータ白書「表 開発プロジェクトの種別の選択基準」中段「スクラッチ開発」の「b:改修・保守」に該当する開発プロジェクト
出典：独立行政法人情報処理推進機構 (IPA) 「ソフトウェア開発分析データ集2022」 2022年9月26日 発行 P.197
この表の通り、母体となる既存システムの規模に対して、どの程度「機能仕様の追加・変更があるか」により、開発プロジェクトの種別を判断してステークホルダー間で共通認識を持つことができる。
※3 テストレベル
「具体的にインスタンス化したテストプロセス」（ISTQB Glossary より引用）具体例としては、単体テスト、結合テスト、総合テストのようなテストプロセスの段階。
※4 テストオラクル
「テスト対象のシステムの実行結果と比較する期待結果のソース」（ISTQB Glossary より引用） 具体例としては、実在するベンチマーク用のシステム、他のソフトウェア、ユーザーマニュアル、個人の専門知識等など。コードであってはならないと言われている。
