こんなことをつぶやいたら、色々ご意見をいただいたので自分なりにまとめてみます。
テスト手順どこまで書くか。実行するメンバーの熟練度次第になるけど悩ましい。
— yuki shiromoto (@yuki_shiro_823) February 10, 2020
具体的テストケースと論理的テストケース
JSTQBのテストアナリストのシラバスには、具体的テストケースと論理的テストケースについて言及があり、ざっとまとめてみると次の通りになります。
具体的テストケース | 論理的テストケース | |
---|---|---|
概要 | テスト担当者がテストケース(すべてのデータ要件を含む)を実行し結果を検証するために必要な特定の情報と手順のすべてを提供する | テスト対象とすべきものに関するガイドラインを提供し、テストアナリストが、テスト実行時に実データや手続きさえも変更することを可能にする |
メリット | テスト担当者の経験が少なくてもテストケースを見れば、テスト実行可能。再現性が高い。監査にも使用可能。 | テスト実行時の変更を許容するため、具体的テストケースよりカバレッジが高い場合がある。 |
デメリット | メンテナンスに労力がかかる。テスト実行者の想像力を阻害する場合がある | 再現性が低い場合がある。 |
(Advanced Level シラバス日本語版 テストアナリスト 「1.5.1 具体的テストケースと論理的テストケース」 p13)
上記の概要は、シラバスからの引用ですが、具体的テストケースの方は、テスト実行の主語が「テスト担当者」となっているのに対し、論理的テストケースの方は、主語が「テストアナリスト」となっています。テスト実行するのが誰かによって、テスト手順や期待結果の粒度をどの程度書くかが意識されてるように思います。
具体的テストケースと論理的テストケースをどう使い分けるか
自分の使い分けについて考えると、テスト実行するメンバとの物理的距離と熟練度が大きく影響しています。
テスト実行するメンバが同じ場所にいる場合
使用するテストケース
論理的テストケースです。「××欄に任意の値を入れる」などの表現をよく使っています。
前提
テスト実行に入る前に、テスト実行してもらうメンバに、テスト対象の目的の説明やテスト対象を一緒に動かしてみるなどを行います。物理的距離が近いと、実行メンバの理解度の確認やなにかあったときのフォローが容易にできます。
ある程度複雑な手順が必要だったり、使用するコマンドなどを具体的に指定した方が良い場合は、テストケースとは別途、確認手順書を書いて具体的な内容はそこに寄せるようにしています。メンテナンスは必要ですが、テストケース一つ一つに手順を書くことに比べると、共通化できている分楽です。
良い点
テスト対象の目的、それで実現したいことを共有しておくと、こちらが想定していなかった問題を見つけてもらえることもあります。(逆に、うまく共有できていない時には、細かすぎるバグを大量に報告してしまったこともありました)
テストケースを書く量が少なくて済むので、メンテナンスが楽です。詳細にテストケースを記載する時間が浮くので、教育とかバグを見つけるための活動に時間を使うことができます。Twitterでもこのようにアドバイスをいただきました。
目的はテスト手順書通りに操作することではなく、バグを見つけることだから。
— あきやま☃️ (@akiyama924) 2020年2月11日
ですから、「最低限の手順書ってなんだ?」と考えて、余った時間を教育に充てるのが良いと思います。
テスト実行するメンバが離れた場所にいる場合
使用するテストケース
具体的テストケースの方が多いです。特にあまりフォローができない場合は、テスト実行に迷わないように具体的に書きます。
良い点
テストケースの記載通りに進められる場合は、経験の少ないメンバでもスムーズに進められます。
悪い点
ちょっとしたUI変更で、テストケース通りに進められない場合は質問の嵐になることがあります。テストケースを修正するにも時間がかかります。物理的距離が離れていたり、さらに時差がある場合はフォローがしにくいので、自分の中には、この問題への対処策はこれといったものがありません。ある程度実行メンバを教育して、修正案を出してもらい、自分はそれを判断するだけにする、とかでしょうか。。
まとめ
テスト実行メンバが同じ場所にいる場合は、論理的テストケースを作成して、メンバへの教育を手厚くするのが良いと思います。離れた場所にいる場合は、よい対応策を募集中です。
最後に、ふとしたつぶやきにアドバイスをくださった皆様、ありがとうございました!