こんにちは。流浪のQAエンジニア @illypon です。ふと気が付いたらソフトウェアテストや品質保証の仕事に関わって20年が経っていました。もう十分働いたと思うので早いところ引退したいものですね。もうええでしょう。

さて、この記事では、常々まわりで「テスト観点をまとめるのが大変だ」という声を聴くので、今の自分の考えをまとめてみることにしました。誰かのお役に立ったら幸いです。

テスト観点という言葉の定義

テスト観点という言葉の定義をGoogle先生に聞いてみました。

テスト観点とは、特定の機能に対してどのようなテストを行うことが有効なのかを考えることを指します。テストケースを作成するうえで必要不可欠な要素であり、テストの精度を高めて効率的に作業するために必要とされています。

これでは抽象的で何のことかよくわかりませんね。なぜテスト観点が必要なんでしょうか。テスト観点がなくても、基本設計書・要件定義書をテストベースとして結合・総合テスト設計を進めていけばそれで十分なようにも思います。テスト観点というのは、仕様書に記述される期待動作をコピペしただけのものなのでしょうか。そんなわけないですよね。

ということで、ChatGPTに聞いてもうちょっと具体的に答えてもらいましょう。

テスト観点とは、仕様書そのものに記載された内容をそのまま確認するのではなく、仕様書やシステム要件を元に、実際の利用状況やリスクを考慮して抽出される具体的な視点です。観点抽出の目的は、仕様書に基づかないリスクや曖昧さを補完し、テストケースを効率的かつ網羅的に設計することにあります。

ご指摘いただいたように、観点を仕様書そのものと混同しないことが重要です。

ちょっと調教をして期待する結論を吐くように仕向けましたが、およそ期待する回答を得られました。つまり、総合的な視野をもって考えることで、テストベースから漏れてしまいがちな部分を効率的に補完して網羅性を高めていくための手段ということですね。

なぜテスト観点が必要なのか

テスト観点およびそれを作成する作業が必要な理由ですが、およそ以下の通りです。

人間には文章を完璧に書く能力はない
言葉は人の意図を完全に表現するほど万能なツールではない
どんなドキュメントもかならずなにか記載漏れ（記載過剰）や更新忘れがある

つまり、設計ドキュメントはどんなにがんばって書いてもけっして完璧にはならないということです。これを補完するものはなんでしょうか。

代表的なものはコミュニケーションです。現場では「文書のどこにも書いてないけど、こういうときどういう動きが仕様として期待動作ですか？」といった会話が大量にされていますよね。とても大切な仕事です。

ただ、そういう会話は無限にできてしまいますし、あまりにも細かい質問をするのも相手の時間を奪ってしまいますし、コスト面からも歓迎されませんね。かといって、大事な質問も遠慮して出てこなくなると大変です。

そこでテスト観点が登場します。テスト設計の補完に役に立つ、具体的で効果的なテストの要素・条件の一覧がテスト観点だといえるでしょう。

テスト観点の分類と習得

私のいままでの経験によると、テスト観点には以下の3種類があると整理できそうです。

（典型観点）そこに着目してテストするとありがちなバグが見つかりやすいというノウハウ
（安全観点）インパクトの大きいバグが発生しないことを確認するためのノウハウ
（行間観点）テストべースとなるドキュメントなどへの記載が漏れがちなものを拾うためのノウハウ

テスト観点というのは種類の違いこそあれ、経験に基づいたノウハウです。テスト観点は再利用可能なことが多いので、一番良いのはやはりたくさんプロジェクトの経験を積むことです。

未経験でのテスト観点の抽出

とはいえプロジェクトの経験が少ないけれどもテスト設計をしなくてはならないということもあるでしょう。そういった方はまずは安全観点、すなわち、「起きたら困る結果とそこに至る手段」 に着目して観点を出していくとよいでしょう。これならば、サービスの利用者の気持ちになればいくつかは絞り出せるはずです。（典型観点のバグは誰かが見つけるでしょうし、行間観点のバグは見つけても後回しになることが多いのでいったん置いておきましょう。）

以下に簡単に書き出した例を記述します。

起きたら困る結果

認証できなくなる
接続できなくなる
起動しなくなる
主たる機能が使えなくなる
今までのデータが消える／壊れる
動作がものすごく遅くなる
次に何をしたらいいのかわからなくなってしまう
その他、運用回避できない不具合で、かつ、影響の大きいもの

起きたら困る結果につながるユーザーの操作や処理

ソフトウェアアップデート
バージョンが古すぎるアプリからのアクセス
サポート外のデバイス
サポートから外れたOS
ストレージフル
破損データ
標準仕様を満たしていないデータ
意図しない操作
同一リソースへの競合操作
過負荷
低電圧
電源ロス
弱電界
圏外
ハードウェアの意図しないタイミングでの取り外しや接続
断線などの故障・破壊、またそのようなデバイスとの接続

テスト観点とは、設計観点のことでもある

テスト観点をたくさん知っている人がプログラムの設計をすることで、ロバストなシステムになります。つまり、テスト観点はそのまま設計観点になります。なので、「こういうテスト観点を考えてますよ」というのをVモデルの左上のところでプロジェクトメンバーの間で共有しておくのが大事です。これはドキュメントの品質を上げていくことにもつながるはずです。

抜き打ちテストをしてバグを見つけるはのではなく、はじめからバグを発生させないようにするのが理想ですよね。

テスト観点は品質基準の決定にも役立つ

テスト観点の整理をすると、そのサービス・製品の品質基準の決定にも役立ちます。わかりやすい例を以下に記載します。

例）動作中に電源断した場合の動作は保証しなくてよい
例）仕様で決まっている以上の添付ファイルを受信した場合、そのメールを正しく表示できなくてもよい

このように過剰な品質になってしまうのを防いだり、めったに起きないイレギュラーに対してどこまで動作保証するのかを明確にすることができます。

テスト観点だけあればいいわけではない

テスト観点はあくまでテスト設計を補完するための考え方であって、テスト観点だけをたくさん書き出せばいいということではありません。

テストには品質目標に合わせた目的がありますから、「どのテストレベルで、どのようなテストタイプを実行するか」という点をテスト計画にしっかり盛り込むことがなによりも大切です。

テスト観点はあるテストタイプの中で利用可能な手段のうちのひとつにすぎません。テスト観点をたくさん出して満足してしまいがちですが、大局を見るということから目を背けないようにしてくださいね。