こんにちは、yassanです。
今回は「テストケースの作り方【機能テスト仕様書】」を紹介します。
テスト工程ではテストを行うためには、機能テスト仕様書を作成する必要があります。
このような、テスト工程に関するドキュメント作成は、新人エンジニアにとっては登竜門かと思います。
（もちろん、テスト工程が肌にあってQAエンジニアになる方もいますが、いきなり設計・開発に取り組むよりかはテストから入るケースが多いと思っています）
そこで、
「先輩社員に機能テストの仕様書を作るように言われたけど、作り方がわからない」
「テストケースを作るように言われたけど、何が必要なのかがわからない」
こういった問題に直面することでしょう。
今回は、そんなシステム開発やテスト工程の初学者に向けてテストケースの作り方を紹介します。
この記事を読むことで、機能テスト仕様書のテストケースがどのようなものかわかるようになります。
正しく網羅できるテストケースの作り方や、少ない工数で効率的に作ることについては、別の機会で紹介したいと思います。
私もITベンダーに入社して最初の仕事がテスト工程の仕様書作成やドキュメント管理でした。
わからないなりにも先輩に聞いたり書籍を読んだりして勉強してなんとか仕上げることができました。
その経験を活かして、新人エンジニアさんの足がかりになれるように、仕様書のテストケースの書き方を共有したいと思います。
仕様書に必要な項目
（繰り返しにはなりますが、項目の洗い出し方は別の機会でご紹介します。）
テストケースに必要な情報は、以下の通りです。
・テストの対象となる機能
・確認項目
・期待結果
・事前条件
・入力値
・実施手順
・参考資料
・テストログ
これらを、例えばExcelなら、項目として作ってそれを埋めるようにテストケースを作成したら良いです。
それでは、一つ一つ説明していきます。
テストの対象となる機能
テストの対象となる機能とは、その名の通りです。
機能テストというからには、何かしらの機能が予想通りに動作しているかどうかのテストになります。
そのテストケースで何の機能をテストしたいのか、きちんと明記する必要があります。
（もっと言えば、何の機能のどの部分のテストをしたいのか）
例えば、写真撮影機能。撮影写真保存機能。撮影写真加工機能。など、〜機能と記載しましょう。
当然ながら、ここの項目の内容は重複するとは思いますが、それはOKです。
1つの機能を1つのテストケースだけでテストするのは現実的ではありません。
機能が何階層かに分類されている場合は、一番細かい単位の機能を書くようにしましょう。
確認項目
確認項目とは、そのテストによって確認したいこと指します。
機能の中でもその機能を実現するための要素であったり、その他の制限事項を記載します。
先ほどの写真の例だと、
写真撮影機能の中でも、確認したいことはいくつか思いつきます。
写真が撮影できること。暗所では撮影時に一時的にフラッシュをたくこと。撮影ボタンを押すことで画面が暗転すること。カメラが搭載されていない端末では撮影ができないこと。などなど
期待結果
期待結果とは、その結果を得られれば機能を満たしたことになるテストによって得られる結果のことです。
言葉の通り、正常に動作することを期待するので、期待結果です。
期待結果では、事前条件・入力値・実施手順を実行した時に得られる具体的な結果のことを指します。
したがって、確認項目よりかは抽象度を下げて具体的に書く必要があります。
写真撮影機能の場合だと、
写真が撮影できること←（期待結果）撮影した写真が画面に表示されること。
写真が撮影できること←（期待結果）「写真を撮影しました」のポップアップが表示されること。
暗所では撮影時に一時的にフラュシュをたくこと←（期待結果）0.2秒ライトが点灯すること。
事前条件
事前条件とは、テストを実行する際の事前の条件のことです。
実施手順と分けて書いておくことで、事前条件が同一のものを固めることができ、テストを効率的に進めることができます。
（先ほどの「暗所では撮影時に一時的にフラッシュをたくこと」に対して、実施手順にいちいち暗所に移動することや容量に空きがあることを確認するなどを書いていたらまどろっこしいですよね）
写真撮影機能の場合だと、
・撮影機材が故障していないこと
・容量に500MB以上の空きがあること。
・バッテリーが総量の10%あること。
などが挙げられますね。
入力値
入力値とは、テストを実行するために入力する値のことです。
これを明確にしておくことで、テストの準備がしやすくなり、結果的にテスト自体も効率よく進みます。
写真の例だとわかりにくいので、メッセージアプリのメッセージ受信を例に考えてみましょう。
・テキスト
・スタンプ
・写真
・URL
・ファイル
などが挙げられます。
試験を実施する前に、ここで挙げられたものが必要であることは、試験担当者ときちんと連携するとGoodです。
実施手順
実施手順とは、テストを実施する手順のことです。
テスターの人は、この実施手順にしたがってテストを実施します。
それ以外のことは一切せず、手順にしたがってテストをするので、文言は明確かつ具体的に書くことに十分に配慮しましょう。
写真の例だと、
・撮影ボタンを押す
ですね。
写真を撮影する。など、曖昧に書くことはやめましょう。
参考資料
参考資料とは、その機能をテストするに至った資料を書きましょう。
そのほかにも、期待結果が期待結果となりうる根拠なども書きましょう。
基本的に、設計書や仕様書になるかと思います。
テストログ
テストログとは、テストの実施結果のことです。
これはテストケースの作成方法とは異なりますが、おまけ程度に。テストする時にはこれらも記載しなくてはいけないと頭に置いておいてください。
テストの結果と一言でいっても、最低でも以下のことを記載しなくてはいけません。
・テストの結果 期待結果が得られたかOKかNGの2値で
・テスト実施日 テストを実施した日
・システムのバージョン バージョン管理ツール上でのバージョンを記載しましょう
・担当者 テストを実施した人
・不具合No. 結果がNGだった場合、不具合を管理しているファイルと整合性を持たせるようにしましょう。
・エビデンスフォルダ テストのエビデンスが保存されている場所を記載しましょう。
以上が、仕様書に必要な項目です。
基本設計や詳細設計のドキュメントに目を通して、これら1つ1つの項目を埋めていくことで完成します。
注意事項
上述の通り、基本的には項目を埋めていくだけで良いのですが、以下の注意点は頭に入れておいてください。
1つのテストケースあたり1つの確認項目にすること
1つのテストケースに複数の確認項目を設けることは望ましくありません。
例えば、「写真が撮影できストレージに保存されること」を確認項目にしてしまった際に、「写真は撮影できたけどストレージに保存されなかった」場合にNGになってしまいます。
この場合は、「写真が撮影できること」と「ストレージに保存されること」と分けた方が良いです。
（この場合、「ストレージに保存されること」の事前条件は写真撮影後になります）
このように、複数の確認項目を設けてしまうと、一部だけNGになってしまった時に、備考欄に書くことが増えますし、不具合管理も煩雑になってしまいます。
できるだけ細かくかつ適正な粒度でテストケースを作成するようにしましょう。
手順や条件には番号をつける
事前条件・入力値・実施手順が複数ある場合は、①②...など、番号を振ってあげると見やすいです。
また、それぞれを記述する時に、番号を参照することで記述が楽になります。
例えば実施手順に、「①入力値①の値をテキストボックスに入力する」という書き方をします。
私見を混ぜない
また、機能テストに関しては、「その機能があることによって要件を満たせているのか」「機能は実現できているが他の実装方法があるのではないか」といった要件定義や開発の話は担当外のことになります。
自分個人の主張やポリシーでテストケースを作成するのはNGです。
テストケースの粒度は統一する
機能ごとにテストケースを作成すると思うのですが、この時粒度を合わせることに注意しましょう。
例えば、写真再生機能と音楽再生機能があった場合、音楽再生機能には、「音楽を再生できること」「スキップボタンを押すことで次の音楽を再生できること」「プレイリストボタンを押すことでプレイリストに再生中の音楽を登録できること」が確認項目にあるのに、写真再生機能には「写真を表示できること」だけだとテストの粒度としては全然違いますよね。
（実際には、写真もスキップボタンを押すことで次の写真を表示でき、お気に入りボタンを押すとお気に入りフィルダに登録されるなどのことができるのならば、粒度を合わせて確認すべきです）
粒度が荒いから悪いと言いたいわけではなく、全体を俯瞰してみて粒度が異なることが悪いのは一貫性がなく推奨できません。
その辺りは、クオリティと工数のバランスをみて考えましょう。
まとめ
いかがでしたでしょうか。
テストケースに必要な項目が理解できたなら幸いです。
テストケースの洗い出し方法などは、また別の記事で書きたいと思っています。
最後に、参考とした書籍を紹介いたします。
テストに関する基本的なことが学べますし、土日や通勤中で読める量ですので、まずは買ってみてざっと目を通すのがおすすめです。
ここまで読んでいただき、ありがとうございました。
