・誰でも分かるテスト仕様書を作ろう
システム開発を行う際には「テスト」工程は必ず行われるものであり、多くの場合そこには「テスト仕様書」が存在します。言うまでもない事だとは思いますが、「テスト仕様書」とはテスト実施者に対する「指示書」の役割を果たしていて、特定の機能についての「テストで確認すべきこと」が列挙されているものになります。テストの自動化が一般化して久しいシステム開発業界ではありますが、すべてを自動化することが難しいケースは現実的にはまだ存在していて、人間の手によるテストについても、「維持すべきクォリティ」というものが存在しています。
今回から「テスター」の目線で、「『こういうテスト仕様書』があれば、初めてテストを実施するシステム系であっても、テスト品質を一定以上に維持しやすい」と言う話をしたいと思います。つまり「初めてそのシステムや機能に触れる人でも分かるテスト仕様書を作ろう」と言う題材です。
世の中には色々なテスト管理ツール等があります(TestRail等)が、今回は一般化するために単純な表形式で自作する場合で行きましょう。
まずは、どんな項目があれば分かり易いのかと言う点。
基本的な項目を並べたのが此方になります。
・テストNo/テスト項目/動作/結果
それぞれの内容の意味は、以下となりますね。
・テストNo.→テスト項目の管理番号
・テスト項目→確認しなければいけない内容
・動作→期待する動作や挙動について
・結果→動作確認の結果欄
これだけあれば一先ず最低限の内容は分かりますね。
実際に表形式で簡単に作ってみるとこんな感じになります。
今は簡単な内容なのでこのままでも分かるかもしれませんが、
実際のテスト仕様書はこんな簡単に書かれていませんし、これだけで分かる物は基本的にありません。
例えば「Aと言う画面にてBの動作を実行時に、Cと言う結果が返される事」と言う確認項目があったとしましょう。すると以下の様になります。
どうでしょうか、途端に分かり辛い感じがしてきましたね。
この場合、[テスト項目]に全ての内容が一括で書かれているのが原因になっています。
なのでもっと項目を増やして内容を分割し、テスト実施者を誘導できる様にしてみましょう。
どの様な項目を増やしていくかと言うと、『何が/どうなって/どうすると/こうなる』と言った内容です。
幾つか項目を増やしてみました、こうなると何をどうしたら良いのか分かり易くなりましたね。
増えた項目は、カテゴリ/種別/条件/備考となります。
それぞれの内容の意味は、以下となります。
・カテゴリ→テスト項目の何を確認するとかと言う点の補足
・種別→動作に対して結果や確認の種類
・条件→何をすれば確認したい内容が行なえるとのかと言う点
・備考→実際にどの様な結果が表示されるかの補足や記載されていると助かる情報等
こうなった事で左から順番に見ていく事でテスト実施者が、
「A画面でB操作を行うと"B動作を実施されました"(結果C)がA画面に表示されるのを確認すれば良い」と理解出来ます。更に上の場合だと備考欄に詳細な期待結果が記載されている事で、この内容以外が表示された場合にNG動作だとテスト実施者が即座に判断できる訳です。
もう少し具体的な画面を例に出してみましょう。
例えば以下の様な画面の表示や動作を確認するテストを作成する場合はどうなるでしょうか。
画面の機能として、「入力された言語を判定し、その内容が何語であるか結果を返す」とします。例を挙げると、『判定元にfrançaisを入力し判定を行うと結果欄にフランス語と表示される』と言った具合です。実際のテストでは、この様な機能の場合は複数の言語判定を行うのが基本ですが、今回の例題なのでフランス語のみに絞った確認項目にします。
実際に確認する分には足りない項目がまだまだありますが、一旦これ位にしておきましょう。
最初の黄色部分の書き方に比べて、各内容が詳細に書かれているので『テスト項目、カテゴリ、種別、条件、動作、備考』と順番に見て行く事で初めてシステムに触れる人でも理解出来る筈です。
条件等に書かれている内容を少しだけ補足しておきます。
・条件：初期状態→対象の画面を表示した状態(何の操作も加えない)
・種別：正常動作→正しい動きを確認(逆にあえて間違っている動きを確認する時は不正動作となります)
これらの書き方は色々ありますが、やはり分かり易いものが良いでしょう。
(例えば初期状態を画面無操作状態等としても良いかもしれません)
「初めてそのシステムや機能に触れる人でも分かるテスト仕様書を作ろう」と言う目的に対しての第一段階として、テスト実施者をテスト仕様書の内容でしっかりと『テスト実施者を誘導する』事が大事です。例え手順が複雑な内容でも多機能的なシステムであっても同様で、テスト項目を細かに分割する事で段階的に確認出来るようになります。
更に①～③の様に連番を振られているものは「これらの番号が振られているのは一つの機能なのだ/連続して確認しなければならないものだ」と直感的に分かりますし、動作部分でも一番確認しなければならない重要な部分を""等で囲む事で強調しています。また表示確認テスト項目から動作確認テスト項目に移る際に、空白を開ける事でも意識の誘導を行っています。
これはテスト項目が連続で続いている中で、何かしらの空白等が登場すると自然と最初の内容に視線が向くからですね。無意識的に連続して項目が続いている場合、段々とテスト項目欄を読み飛ばしてしまう事への対策です。「結果があっていれば良し」ではなく、テスト実施者が「自分が何の項目を確認しているのか」と言う意識を維持してもらう事は重要になります。
今回の大事な所をまとめると次の3点になります。
・一つのテスト項目に内容を詰め込みすぎない事
・『何が/どうなって/どうすると/こうなる』と誘導を行える事
・流れ作業とならない様に、意識のリセットを行う場所を入れる事
今回は導入的な部分になりましたが、次回はよりテスト確認の動作部分にも踏み込んだテスト仕様書にしていきたいと思います。
