自動テストを考慮したテスト設計　〜概念〜

# テスト設計において何を考えてますか？
　テスト設計の時、何を考えていますか？テスト対象の機能のこと。テストすべき観点のこと。テスト技法を適用すること。期待値を明確にすること。テスト条件を満たす手順や環境を定義すること。最終的にテストケースに落とし込むこと。色々と考えることはあると思います。
<img width="600" alt="スクリーンショット 2019-11-30 9.37.10.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/541693/4c87481f-3944-bcca-e283-e01ffb98aac3.png">


# テスト設計のWhatとHow
　これら考えていることは大きくWhatとHowに分けることができます。Whatというのは、「何をテストするか？」を考えることです。一方、Howというのは、「どのようにテストするか？」を考えることです。普通テスト設計で考えることと言えば、何をテストするか、いわゆるテスト観点を抽出したりすることが大事と思われがちですが、Howのどのようにテストするかも同じくらい必要です。これは、これまでの経験上そうしていたといったことや、過去のプロジェクトのやり方を流用するなどして暗黙的になっていることが多いかもしれません。
<img width="600" alt="スクリーンショット 2019-11-30 9.37.20.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/541693/cfcff12f-97f9-54c1-c5f4-e60af9e10150.png">


# テスト設計のプロセス
　ASTERが示しているテスト開発プロセスを知っていますか？それには、以下の４つの工程が定義されています。

　1.テスト（要求）分析
　2.テストアーキテクチャ設計
　3.テスト詳細設計
　4.テスト実装

　テスト要求分析では、テスト対象を把握し、様々なステークホルダーを意識しながらやるべきテスト（テスト観点）を抽出していきます。
　テストアーキテクチャ設計は、テストの種類、品質特性、テストの実施方法や順序、リスクなどを考慮してテスト観点を整理し、テストの全体像を表します。例えば、自動テスト、ニアショア、経験の浅いテスター、テスト対象物の開発状況などを考慮してテスト観点を整理し、テストの実現性、ドキュメントの粒度、テスト環境、テスト実行の進め方などを決めていきます。
　テスト詳細設計は、テスト条件や期待結果を明確に定義し、テスト観点を満たすことのできるテストケースを生成していきます。ここでは、入力値などを決めるための同値分割、境界値分析、条件の組み合わせを決めるためのデシジョンデーブル、オールペア法などのテスト技法を活用します。
　テスト実装は、テストスクリプトを書くことです。テストスクリプトは、テスト手順書、テストシナリオ書など呼び方は色々あるかもしれませんが、テスターがそれを見てテストを実施し、結果を記入するようなものにあたります。（なので、テストケース=テスト手順書の場合もあると思います）　そして、自動テストでいうと自動テストのためのテストコードの実装もここにあたります。
（詳しくは、テスト設計コンテストのチュートリアル資料を参照してください）
http://aster.or.jp/business/contest/tutorial.html#tutorial_material

# WhatとHowに分けてみる
　このプロセスをWhatとHowに分けるとするなら下図になるのではないかと思います。
<img width="600" alt="スクリーンショット 2019-11-30 9.37.26.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/541693/73837fa8-f621-2732-e144-6cccb88b421e.png">

　このように、左側のテスト要求分析やテスト詳細設計は「何をテストするか」を考えていて、右側のテストアーキテクチャ設計やテスト実装は「どうテストするか」を考えているものとして分けることができます。左と右でそこまで明確な区切りはありませんから、実際はそれぞれを交互に考えを巡らして最適なものを見つけることになります。例えば、テストアーキテクチャを検討している時に、意図が明確でないテスト観点に気づきテスト要求分析を再検討するようなことです。
　また、上下の括りで見た場合、上は抽象レベルが高い状態でのテストの検討で、下は具体的にテストすべきことを明確にしていると考えることができます。

# それで自動テストを考慮するとは？
　テスト自動化というのはテスト実施の手段ですので、自動化を考慮したテスト設計ということは右側を意識するということになります。つまり右側で考えるべきこと、やり方などが変わってくるということです。（左側は自動テストだからといって変わらないものです）
　それでは、テストアーキテクチャ設計では何が変わってくるでしょうか。テストアーキテクチャは色々な切り口でテストを分割するようなものです。なので少なくとも、手動テストか自動テストかという切り口が加わることになります。全てのテストを自動テストで実現できるというものでもありません（そういう話が出ることもありますが。。）自動テストでやりたいテスト、自動テストでは実現が難しいテストなどがありますので、この区分けや整理は必要になってきます。このような検討すべき点が加わるということが違いになります。またその考え方は自動化に限らず、例えばニアショアとかいった場合でもそういう切り口で同様に考えるべきものです。（環境的にニアショアでテストが実現できるか、難易度・重要度的にテストをやらせたいかという検討）
　次に、テスト実装についてです。ここはテストコードを書くわけ（プログラミングするわけ）ですので当然違うわけですが、その中でもより前提条件やテストデータ、操作手順や方法、期待結果の確認方法とその値や内容の明確さが非常に要求されてきます。テストコードでは曖昧な記述など当然できませんから（機械は書かれた通りのことをテストするので）、この点が異なるところです。テストケースの順番などもしっかりと検討してからテストコードを書かないといけないというものもあります。手動テストの場合は、複数のテストケースをみて、同時にできそうなもの、順番でできてしまうものをテスターが解釈して効率よく実施することができますが、自動テストの場合に事前にそれを検討してテストコードに実装する必要があります。このように内容的には手動テストのみの時と変わらないのですが、より明確な、厳密な定義が求められるという点がテスト実装における違いになると思います。

# まとめ
　今回はテスト設計で考えることをその内容からWhatとHowで分けました。その上で、自動テストを考慮した時に変わってくるところについて考えました。そして右側のテストアーキテクチャ設計やテスト実装に違いが出てくることを解説しました。左側のテスト（要求）分析やテスト詳細設計については、分析のフレームワーク(6W2Hや意地悪漢字などのガイドワード）、蓄積されたテスト観点、そしてテスト技法などがありますが、右側のテストアーキテクチャ設計やテスト実装の考え方、ノウハウ、手法はまだ事例等が少ないのではと思います。こういったところも今後ノウハウの共有や蓄積ができていくと良いのかもしれません。