テスト設計に使える情報整理術のご紹介

はじめまして！QAエンジニアのたくぞーです。　

テスト設計を行う上で、必要なテスト要件を網羅できているか不安に感じる…という方は少なくないのではないでしょうか。テスト設計時の仕様把握において、内容そのものの理解はもちろんですが、情報を十分に整理できていないと必要なテストの抜け漏れに繋がります。

テスト設計業務での仕様把握をきっかけに、テスト設計で活用できる情報整理の方法はないかと思い調べてみました。今回はそれぞれの概要やメリット、筆者の経験上の活用事例を交えてご紹介していきたいと思います。

テスト設計に使える情報整理術
その他の情報整理術
- 多面的な視点から物事を捉える
まとめ

テスト設計に使える情報整理術

デシジョンテーブル

まず初めにデシジョンテーブルを紹介します。ブラックボックステスト技法の1つなので、ご存じの方も多いのではないでしょうか。複雑な条件（入力）の組み合わせによって、アクション（出力）が異なるシステムの場合に効果的です。条件とアクションの関係性をテーブル（表）に可視化することで組み合わせを整理しやすく、必要なテスト条件を漏れなく検討することができます。

簡単な活用例を交えて紹介します。ある会員限定の通販サイトの料金計算に関する下記の仕様があるとします。

会員ランクは「ゴールド」「シルバー」「ブロンズ」の3種類
購入代金から会員ランクに応じた下記の割引が適用される
- ゴールド：10%OFF　
- シルバー：5%OFF　
- ブロンズ：割引なし
クーポン適用で購入代金から5%OFFする
会員ランクによる割引とクーポンによる割引は併用可能

これらの仕様をデシジョンテーブルで表すと下記の通りです。

※存在しない条件の組み合わせ（異なる会員ランクの組み合わせ）は省略しています。

上記仕様では会員ランクの種類とクーポンの適用有無によって割引率が変動するため、各会員ランクとクーポン適用を条件部分に、各条件に対して「X」「Y」の値を記載します。その上でアクション部分に該当する割引率と「X」の値を記載します。

今回はシンプルな仕様なのでケース数は少ないですが、複雑な仕様となるとケース数も増大します。そのような時にデシジョンテーブルは効果的です。注意点としては、存在しない組み合わせなどの不要なケースを含めてしまったり、反対に必要な組み合わせを省略してしまうことが考えられるので、その点は気をつけましょう。

デシジョンテーブルは使う頻度も多く、筆者の場合はデシジョンテーブルと合わせてフローチャート部分をテスト分析・設計する時にも活用します。その際、分岐時の条件を条件部分に、その条件に応じた結果をアクション部分に入れて整理すると、必要なテスト条件を漏れなく効率的に検討でき、特に分岐が多い時はより効果的です。

また、デシジョンテーブルに関する詳細は下記の記事で詳しく取り上げられているので興味がある方はこちらも読んでみて下さい。

▼参考記事
いまさらデシジョンテーブルというものを考えてみた｜Sqripts

状態遷移図/状態遷移表

続いては状態遷移図、状態遷移表です。こちらもブラックボックステスト技法の1つですね。状態間が遷移するようなシステムやソフトウェアの場合に、状態とイベントの関係を図や表で可視化できるので全体像が把握しやすくなったり、考えうるパターンを整理することができます。

こちらも簡単な活用例を交えて紹介します。エアコンのリモコン操作に関する下記の仕様があるとします。

ボタンは「冷房」「暖房」「除湿」「停止」がある　
停止中に「停止」以外のボタンを押下すると運転中に切り替わり、各ボタンに応じた状態に遷移する
- 「冷房」ボタン：冷房　
- 「暖房」ボタン：暖房　
- 「除湿」ボタン：除湿　
運転中の各状態で「停止」以外のボタンを押下すると、各ボタンに応じた状態に遷移する
運転中の各状態で「停止」ボタンを押下すると、停止中に遷移する

これらの仕様から、各状態とイベントの関係を状態遷移図で表すと下記の通りです。

各状態はそのまま状態として表し、各ボタン操作はイベント、イベントによる遷移は矢印で表しています。

次に、作成した状態遷移図の内容を踏まえて状態遷移表を作成します。

遷移前の状態を行に、イベントを列に入力し、イベント実行後の遷移先を表内に当てはめていきます。また、イベントを実行しても遷移が発生しない組み合わせには「-（ハイフン）」を入れます。

このように、状態遷移図では視覚的に全体の流れを把握できるため仕様を整理しやすくなり、状態遷移表では遷移しない組み合わせや無効な遷移も表すので必要なテスト条件の抜け漏れ防止に繋がります。

筆者の場合、例に挙げたような状態間の遷移を伴うシステムは当然のことながら、画面間の遷移を整理したい時にもよく活用します。画面数やイベント数が多いシステムになるほど作成や更新の手間は多少ありますが、用意しておくことで深く仕様を理解することができ、結果的にテスト分析・設計を円滑に行えた経験もあります。注意点としては、規模が大きいほど複雑化しやすく、逆に理解しづらくなってしまうことがあるので、適切に分割したり表記方法を簡潔にするなどの意識が必要です。

状態遷移図、状態遷移表に関する詳細な記事についても下記で取り上げられているのでご興味のある方は読んでみて下さい。

▼参考記事
幅広いソフトウェアとテストレベルで適用可能な状態遷移テスト｜Sqripts

ロジックツリー

ロジックツリーとは、ある課題や物事の要素をツリー状に分解して整理することにより、解決策を導き出していくフレームワークです。各要素を左から右に樹木が枝分かれしていくような形で階層化して整理していきます。
ロジックツリーにはいくつか種類がありますが、「要素分解ツリー（WHATツリー）」と呼ばれる、構成されている要素を網羅的に分解していく手法が整理しやすいかと思います。テスト対象となる画面や機能といった各要素を、WHATツリーを用いて段階的に分解（整理）していくことで、全体像を把握しやすく、テストすべき内容を整理することができます。

これまでと同様に簡単な活用例を紹介します。ログイン画面に関するテストを行うことになり、下記の仕様があったとします。

ユーザーID/パスワードを入力してログインする　
ユーザーIDは4～20文字の範囲で、半角英数字と半角記号が使用できる　
パスワードは8～64文字の範囲で、半角英数字と半角記号が使用できる
- 大文字・小文字・数字・記号の中から3種類以上含める必要がある　
ログインに成功すると会員画面に遷移する　
ユーザーID/パスワードの範囲内の文字数/文字種を入力し、ログインに失敗した時はログイン画面上にエラーAを表示する
ユーザーID/パスワードの範囲外の文字数/文字種を入力し、ログインに失敗した時はログイン画面上にエラーBを表示する
「パスワードを忘れた場合はこちら」リンクから、パスワード再設定画面に遷移する

これらの仕様からどのようなテストが必要かを分析する際、WHATツリーを使うと下記のように整理することができます。

テスト対象となる画面を起点に機能⇒観点の順に階層を分けていき、右にいくにつれてより詳細度の高い観点を記載していきます。筆者の場合はこのように、画面や機能の関係性をツリー上に展開してテスト観点を整理する際に活用していますが、実際に型に当てはめて可視化しながら整理できるので、頭の中だけで考えたり箇条書きで書いてみるよりも、観点が抜け漏れてしまう可能性がぐっと下がる印象を持っています。

検討すべき要素が多い場合はもちろん、要素が少なくても不安と感じる場合には一度WHATツリーを活用してみて下さい。

仮説思考

仮説思考は限られた情報や知識・経験から最も可能性の高い結論を仮説立て、その仮説に基づいて検証を行い正確な情報を確認する思考方法です。テスト設計においては、テストベースの情報が少ない場面で活用できます。限られた要件や仕様から仮説を立てることで、テストベースを読むだけでは一見分からない要件や仕様について検討することができます。

筆者の場合、上記のロジックツリーの例と関連しますが、あるシステムのログイン画面に関する仕様把握を行っていた時に、認証に失敗する時の入力条件や、認証失敗時に該当のエラーを表示することはテストベースに明記されていましたが、一定回数失敗した時にロック状態になるといったことは明記されていない状況がありました。

過去に類似機能のテストを行った時はロック状態に関する仕様が存在していた経験から、その仕様が考慮されていない可能性があるといった仮説を立てて関係者に確認を行い、結果的にはそのシステムの性質上考慮は不要という結論に至りましたが、もし考慮が必要である場合には、何回失敗するとロック状態になるか、ロック状態はどのように解除されるか、という疑問も連想できるので仕様の有無と合わせて確認しておきましょう。

注意点としては、知識や経験に依存しすぎて仮説に頼ってばかりでは、返って柔軟なテスト設計ができない場合もあります。そのため、仮説は適切な場面に応じて立てて検討したほうが良いでしょう。

フェルミ推定

フェルミ推定は予測することが困難な数値を、既知のデータや情報から論理的思考に基づいて概算を推定する手法です。限られた情報から答えを求めるという部分は、仮説思考と共通する部分になりますね。

テスト設計においては、数値に関する情報が不足している状況で活用することができ、限られた仕様や知識から概算を推定し、テストベースには記載されていなかった仕様について検討することができます。

筆者の場合、ある大企業向け業務システムのユーザー登録機能の仕様把握を行っていた時に、どれくらいのユーザーを登録できるかといったテストを検討する必要があったのですが、テストベースとして参照できるものに登録上限数が定義されていないという状況がありました。一見どこまでテストするのが妥当なのか見当が付かない数値でしたが、日本で最も従業員の多い企業が約35万人で、ここ5年で約3万人増加というデータを知っていたため、バッファ分を考慮しても50万人登録できるようであれば十分と考えることができます。

もちろん関係者に上限数を確認する必要はありますが、確認する際にただ確認するのではなく、上記の様に妥当性を提示することで客観的な根拠を得ることもでき、仕様の誤りの修正や仕様の決定を関係者がスムーズに行えるようになります。

その他の情報整理術

多面的な視点から物事を捉える

ここまではテスト設計に活用できる各情報整理の手法について紹介してまいりましたが、その他にも意識的な技術として、多面的な視点から物事を捉える重要性についても紹介いたします。　

例えば、ある物事を特定の視点からしか捉えることができないとすると、他の視点から捉えることができる部分を見落とすことになり、その物事の本質を捉えることができません。これはテスト設計においても同様で、テスト対象の本質を捉えることができないと見当違いなテスト内容を検討してしまったり、考慮漏れという事態にも繋がります。

様々な視点から物事を捉えるために「鳥の目、虫の目、魚の目、コウモリの目」といった4つの視点を表す言葉が存在するため、概要について説明いたします。簡潔に表すと下記の通りです。

これらの視点はいずれも仕様把握において重要と考えています。

多少の主観を含みますが、テスト対象に関する理解を効率よく深めるには、はじめに鳥の目を意識する必要があると考えています。筆者の場合、テスト対象の全体像を把握しきれていない状態で詳細部分の分析から進めてしまったことで、より理解に時間がかかってしまったり、見当違いのテスト内容を検討してしまったという経験もあります。

まずは、テスト対象の全体を俯瞰して見ることを心がけ、その上で虫の目を意識して詳細部分の分析を行いましょう。そうすることで効率よく理解を深めるだけでなく、テストベースに明記されていない要件や仕様に気づける可能性も向上します。

また、その時にコウモリの目を意識してユーザー視点で仕様について考えることも必要です。ユーザー視点で考えてみると妥当ではないと捉えることができる仕様や、要件や仕様の誤りに気づける可能性もあります。

他にも、時間に特性を持つテスト対象においては魚の目を意識して、過去→現在→未来といった各時間軸でどのような違いがあるかを検討し、テストベースに明記されてなければ関係者に確認しましょう。

また、仕様把握を行う際には、下記の記事の記載内容と合わせて実践することでより高い効果が得られると思いますので、こちらの内容についても合わせて読んでみて下さい。

▼参考記事
良い仕様把握は良い品質に繋がる〜仕様把握をする時のコツ 5選を紹介〜｜Sqripts