・誰でも分かるテスト仕様書を作ろう
これまでに『誰でも分かるテスト仕様書を作ろう』と言う題目で、幾つかの内容を紹介してきました。複雑になり過ぎず、行間を詰め過ぎずといった事を意識する事で、テスト実施者の誘導を行い分かり易さを目指しています。とは言えこれらは書き方の一例に過ぎず、例に出した内容も簡単なものばかりだったので、テスト設計者として作成する内容も、テスト実施者として行う事になる内容はもっと異なる形になる事でしょう。それでもこれまでの「実施者の事を考えてテスト仕様書を作る」と言う意識を持っていれば、急に変える事は出来なくても徐々にそう言った方向に変える事が出来る筈です。
上記の内容はこれまでの内容を簡単にまとめた物になっていますが、更に少しだけ内容を追加しています。新しく追加したのは２項目ですね。それぞれとても簡単な内容にはなりますが、無いよりは有った方が良いでしょう。
・テスト実施日
こちらはそのまま「いつテストを行いました」と言う記録用になりますね。振り返りの際や再度実施する時の参考元としてこの日付があると管理がしやすくなります。
・不具合内容
本来不具合内容は別で報告を行い、そちらの方で管理する事が多いのですがそれだけだとどの様な内容だったのかを確認し辛い為に簡潔にここに記載しておくようにします。「表示内容が違う/動作が違う/仕様書の内容と異なる」等と言った内容を記載しておくと振り返りの際や、再テストを実施する時に修正点や変更箇所の確認が楽になります。因みにここに記載する内容は実際の不具合のみだけでなく、テスト実施中に気になった事等をメモしておく場としても活用出来ます。「動作的には問題無いけど微妙に異なる箇所がある」と言った事を記載しておくと、確認を取る時に開発者側にも分かり易く伝わる筈です。
・色について
一部の内容が赤字になっていたり、色付けされている箇所がありますが、これはテスト実施中に発覚した変更点やテスト不具合の個所/不具合と断定できない箇所の目印に使います。赤と言うのは目に入り易く主張が強いので「不具合があります」と宣伝するにはもってこいの色です。黄色は赤ほどではないですが、目を引く色ですので「何か問題があるかもしれない」と言う宣伝に使えます。信号機の色と同じ様な理屈ですね。この辺の色の指定についてはテスト実施者全体のルールとして決めておくと、統一性があり非常に分かり易いものになります。
赤字の修正点についてはテスト実施中に、初期の設計から変更になった事が発覚した場合に使っておくと再テストの際に同じ様な確認をしなくて済みます。本来であれば変更があった時点でテスト実施者側に連絡を入れたり、テスト設計者の方で修正を行っておくのが望ましいですが、テスト実施者側からの確認でテスト仕様書の修正を行うと言うのは多々あります。「必要な情報の更新や伝達が行なわれていない」と言う部分で言えば、良くは無いですがテスト実施者の時点で気が付けているのである程度であれば問題ないでしょう(当然「実施者側が修正するでしょう」の気持ちで放置しておくのは駄目です)。
今回の大事な所をまとめると以下の内容にになります。
・日付を入れる事で実施時の時期確認を分かり易く
・不具合内容欄に簡単に内容を記載する事で、内容の管理・不具合判定の高速化
・不具合や不具合かもしれない部分には色付けをして目立つようにする
・色付けルールについては全体で共通として誰でも色で判断出来るようにする
相変わらず細かい内容ばかりですが、分かり易い仕様書になりました。
