テスト設計チュートリアル（U-30版）に参加してきました
JaSSTを主催しているASTERでは、毎年「テスト設計コンテスト」というコンテストを開催しています。
コンテスト開始前には「テスト設計チュートリアル」が開催されていて、テスト設計の考え方を紹介していただけます。JaSST’16 Tohokuでは「テスト設計」をテーマに開催しましたが、このチュートリアルは残念ながら東北では開催されていません。東京会場に行って聞いてきましたので、JaSST’16 Tohokuのワーク内容と紐づけながらレポートしたいと思います。
ASTER-テスト設計コンテスト'17-U30 クラス チュートリアル
テストケース作成を成功させるために
「テストケースを挙げてください」と言ったとき、以下のような状況に陥ることが多々あります。
- 思い付きでテストケースの羅列をする
- 粒度がバラバラ
- よく読まないと分からない
テストケースを作成するとき限りませんが、情報を整理する必要があります。そうすることで、テストすべきことが見えやすくなります。大事なことは、自分が納得して、自分で説明すること。伝えてフィードバックをもらうことで、いいテストができるようになります。
それを実現するために、4つのステップを踏みます。
- テスト観点（テストすべきこと）を整理して、網羅的に挙げよう
ピンポイント型のテスト観点もきちんと挙げよう - テストフレーム（テストケースの構造）を考えよう
- テストコンテナ（テスト観点やテストフレームをまとめたもの）とその間の順序関係を網羅しよう
リスクベース度な優先順位付けをしよう - テスト観点からテスト値（テストケース）を網羅しよう
1.テスト観点（テストすべきこと）を整理して、網羅的に挙げよう【テスト要求分析】
トップダウンとボトムアップを循環させながらテスト観点を網羅していきます。
最終的に、階層型の記法を用いると、様々な抽象度のテスト観点を俯瞰的に整理することができます。同じ階層の粒度は揃えることが大切です。分解については、WACATE2016夏の「分解について」という資料を参考にするとよいでしょう。
【図：テスト観点図の例】*3
ピンポイントの観点も忘れずに
- 起きてほしくないこと
危険事象やハザードなどいろいろ - バグ
絶対に入ってほしくないバグやよく作りこんでしまうバグ - 後工程でバグを引き落としそうな罠や弱点
構造が歪んでいるところや分かりにくいところ
プラットフォームや言語使用に潜む罠や弱点
JaSST’16 Tohokuのワークショップの前半では、テスト観点の洗い出しとテスト観点ツリーの作成を行いました。テスト観点は仕様書を伏せて出して行きました。そうすることで、仕様書に書かれていることに捕らわれず、「自分が使うなら」「自分が開発するなら」「こんなバグに出会ったことがある」といった幅広い観点が出せるようになりました。
チームで行うことで、他の人が持っている観点を共有することもできます。ツリー構造にする時には、粒度や言葉の意味を合わせるのが難しくはありますが、相手に伝え、フィードバックをもらい、納得しあう、というフローは、説明力が求められる「テスト技術」を高める練習にもなるのではないかと思います。
2.テストフレーム（テストケースの構造）を考えよう【テストアーキテクチャ設計（テストフレームモデリング）】
"テストケースの構造"には単純なものから複雑なものまでいろいろあります。テストケースの構造を、テスト観点やテストパラメーターで表したものを「テストフレーム」と呼びます。
【図：単純なテストフレームの例】*4
【図：複雑なテストフレームの例】*5
テストフレームはテストケースのスケルトン（骨格）です。テストフレームの要素を見出しとして表にすると、テストケースになります。テストには様々な観点がありますので、テストフレームは1パターンのみでで表現できるとは限りません。
【図：テストフレームとテストケース表の例】*6
【図：組み合わせのテストフレームとテストケース表の例】*7
テストフレームについては、情報交換会の質疑応答で話題にあがりました。今回はワークの提供ができませんでしたが、その後、勉強会を開催して理解を深めているところです。
3.テストコンテナとその間の順序関係を網羅しよう【テストアーキテクチャ設計（テストコンテナモデリング）】
テストコンテナ（テスト観点やテストフレームをまとめたもの）にまとめる
テスト観点やテストフレームが増えてきたら、「テストコンテナ（テストの箱）」にまとめてあげると見通しがよくなります。テスト設計をする人は、「なぜこれらのテスト観点やテストフレームをまとめて、このテストコンテナにしたのか」きちんと説明できないといけません。社内標準のようなもがあり、それを適用する場合であっても、きちんと説明できる必要があります。もし説明できないのであれば、理解が浅いか、その社内標準とテストがマッチしていない証拠です。
＜テストコンテナの例＞
- テストレベル
- テストタイプ
- テストサイクル
【図：テストコンテナの例】*8
テストコンテナ間の順序関係（テストアーキテクチャ）を考える
後工程や後プロジェクトでテストしやすいようにテスコンテナをまとめ、前後関係や並列関係を考える必要があります。テストコンテナを適切に配置しないと、開発がやり直しになるような不具合が出荷間際に見つかったりする羽目になります。
テストコンテナを用いてテストアーキテクチャを設計すると、テストの全体像が俯瞰しやすくなり、チームで共有しやすくなるというメリットもあります。
【図：テストコンテナの例】*9
テストコンテナ間の結合度を低め凝集度を高めるようにしつつ、テストアーキテクチャ設計の品質特性を高めていくのが王道…ということですが、これがテスト設計の腕の見せどころでもあります。テスト設計コンテストでも特に重要視されており、出場経験のある私としては、ここが一番難しく、評価を分ける部分だと感じています。
※リスクベースドな優先付けをしよう
リスクベースドテストとは、「もしこのテストケースを実施しなかったらどのくらい困ってしまうのか？」と推測し、困ってしまう程度（品質リスク）の高い順に優先順位をつける方法です。テスト担当者はリスクを明らかにした上で、後回しにできる品質リスクを顧客や開発側と相談し、合意を取ります。テストアーキテクチャ設計では、品質リスクに合わせて厚みやバランスを決めていきます。リスクの高さによっては網羅基準を変えることもあるでしょう。
テスト詳細設計では、品質リスクの高い順にテストケースを実施するとよいです。
JaSST’16 Tohokuでは、テストコンテナの作成と並び替えのワークも行いました。私が担当したグループでは実際の業務を意識し、「この不具合はいつの時点で見つかってほしいのか」という視点でコンテナを並び替えました。例えば、「ユーザビリティの観点については、テストの最終段階（リリースの直前）になってから言われても直しようがないので、実装をするもっと前、設計レビューで指摘されたい」といった感じです。テストは実行に目が行きがちですが、レビューも大事なテストの一つ。テストコンテナを作成し並び替えることで、レビューの観点ができあがったのは大きな発見でした。
4.テスト観点からテスト値（テストケース）を網羅しよう【テスト詳細設計】
テストケースの導出までは、以下の流れで行っていきます。
【図：テスト値の導出】*10
青の四角に書かれたものをインプットとし、丸の中に書かれたことを行います。オレンジの四角に書かれているものがアウトプットです。次のインプットにもなっていますね。丸に書かれていることを、1つずつ見ていきましょう。
1.モデルの特定
モデルには以下の4種類があります。
【図：モデルの種類】*11
①範囲：連続性があるもの
②一覧表：因子水準表など
③マトリクス：組み合わせを表現する
④グラフ：画面遷移図や状態遷移図など
グラフは全体を俯瞰しやすい一方で表現するための技術が必要であったり、マトリクスは簡単に作れる一方で巨大化しやすいという難点があったりします。どれを使うのが正解、というわけではなく、その時に整理したい内容や好みに合わせて活用していくのがよさそうです。
2.詳細化する
これ以上細かくならないところまで細かくします。洗い出してしまえば理由を付けてテストの量を減らすことはできますが、洗い出しが不十分な場合、テストが漏れてしまいます。
3.基準を決める
テストの厚みや幅を調整するための基準を決めます。このとき必要になる情報としては以下の2つです。
- カバレッジ基準：説明材料として必要なもの
- 状況、条件、制約：現場や案件の現状に合わせた形にするために必要な情報
これらはプロジェクトやテストの計画時に用意されていることもありますが、ない場合は、様々なテストベースから導き出す必要があります。 リスクベースの考え方を用いてみましょう。
4.基準に沿ったテスト値を導出する
テスト値を作成します。テスト値には、直接テスト手順の一部（テストデータ）として実施できるものと、テスト値からさらにテストデータを導く必要があるものに分かれます。前者の場合、そのままでテスト実行できるかもしれませんが、後者の場合はテストデータの抽出が必要になってきます。
このように、テストケースを作成するときには、詳細化やモデリングを行います。闇雲にテストケースを作成したのでは、このテストが十分かどうかの説明もできませんし、効果的なテストに間引くこともできません。最後まで、自分が納得して自分で説明することを意識するとよいでしょう。
テスト観点図やテストコンテナの作成も、詳細化とモデリングという作業を行っていました。これがテスト設計の肝なのだろうなと感じています。
まとめ
東京で開催されたテスト設計チュートリアル（U-30版）のレポートをお届けしました。テスト設計チュートリアルは全国各地で開催されています。東北のみなさんから「テスト設計やりたい！」というたくさんの声が届けば、来年は東北でも開催されるかもしれません。JaSST東北の実行委員と一緒に、勉強していきましょう！！
お知らせ
10月29日（土）に仙台にて、「ソフトウェアテスト勉強会～テスターと創る開発現場～」が開催されます。JaSST'14 Tohokuで講演いただいた@miwa719さんにお越しいただき、テスターやチームについて語り合います。参加費はお菓子＋会場費として300円のみとなっていますので、ぜひみなさん、ご参加ください！
記：めい
