【テストを”段取”る!】 より有益なテスト結果にするために考慮するインプット情報とアウトプット情報のはなし

みなさんこんにちは。私は現在Web系のQA業務に従事しています(5年ほど。昔は組み込み系でした)。今回は日々のQA実務を通じて考えていることなどを書いてみたいと思います。(内容がWeb系寄りで経験ベースの内容となります点をご了承下さい)

普段、QAに関わっている方であれば、製品やサービスについてテストを行う際、自身でテストケースを作成しなければならないこともあると思います。

その時ケース作成の手掛かり(インプット)にするものは何でしょうか。通常は要求面では要求定義書、仕様面では各種仕様書であったりすると思います。

上記のドキュメントをもとにしてテストとして確認する必要のある箇所をケースに落としていく訳ですが、この時、先のドキュメントはそれぞれの企業や各プロジェクト、テストの対象物などによって名称や粒度などが様々で、場合によっては明確に存在していない場合もあります。

経験上、仕様書は何らかの形でそれなりのものが存在していることが多いですが、要求定義についてはそもそも明確なものが存在していなかったり、存在していても提示が行われないことも多いと感じます。
そんな状況に置かれた時に、仕様書など提供されたドキュメントのみでテストケースを実行し完了としてしまった経験はないでしょうか。

確かにテストケースを作って実行しさえすれば何らかの結果は出るため、それを報告すれば実施の目的は達成したように思えますが、要求定義を取り込んだテストはできていません。
リリースが直前に迫った中で行われる受け入れテストは、この要求部分の確認に重きを置いて、実施結果をフィードバックする必要があるのですが、ここまでのテストで担保できるのは、V字モデルでいう結合・システムテストレベルであると言うことができるでしょう。

組み込みソフトウェアの世界で出てくることが多いのですが、検証(=正しくモノを作っているか)と、妥当性確認(=正しいモノを作っているか)という言葉があります。上記ではこの妥当性確認の要素が抜けている状況と言えます。

ここでいう「正しいモノ」とは、「『利用者(お客様)が期待しているような使い方ができる』モノ」とも言い換えることができると思いますが、ではこのように要求定義が存在しない状況において、取り込めていない情報を補完するために考えられるインプット情報源にはどのようなものがあるのでしょうか。

私が思いつくものを以下に挙げてみました。
(※開発案件やプロジェクトの体制や状況等でアプローチの可否は変わります)

 a) マーケティング担当者に話を聞く
 b) カスタマサポート担当者に話を聞く
 c) 企画・制作担当者に話を聞く
 d) 過去のバグレポート・報告書・気づき提案事項(あれば)を閲覧する
 e) 自身が初めて利用する場面を想像する

a)とb)は、該当者が近い場所にいなかったり、ヒアリングできる状況にない場合がありますが、
a)は顧客のニーズと期待を定量化していますから、話を聞くことで彼らの想定する今回の利用者層やそのためのプランを把握することは非常に重要です。
b)製品・サービスに対する利用者の期待と、実際の製品・サービスが持つパフォーマンスの間にあるギャップなど、利用者の生の声から把握している知見は多いと思います。
c)は制作方針に従って決定されたユーザライクな部分などの具体的な箇所と工夫についてを聞くことができます。
ちなみに、ここではスケジュール上利用者向けの配慮が行き届かなかった所も聞ける可能性があります。
d)は過去にどのような問題がありそれに対しどのような改善を施したのかを知ることができるでしょう。
最後にe)ですが、これは自身が初めて利用する際の状況を想像して確認ポイントを挙げていくということです。

a)~d)までは必ずしも受け取れる情報とは限りませんが、e)は自身の経験に依存する部分であるため、普段から目を養っておき意識しておくことが大切だと言えます。
a)~e)間では、得られる回答が被ることはありますが、全く同じ回答ではないでしょうし、また下に行くほどアプローチは行いやすいけれども、情報として活用できる幅が狭まったり、断片的・属人的である可能性もあります。

よって、実務ではどれか1つにだけアプローチするのではなく、可能な限り全てにアプローチを行うことで、より多層的な観点を導けるのではないかと考えています。

これは、利用者の期待するポイントは状況や属性など利用者ごとで異なっているという主観的な面もあるからなのですが、そうなると、テストケースに起こすことが難しい場合もあります。
このような場合には、テストをする中で違和感を感じる箇所を理由と向上施策(提案)を添えて報告するということも有効です。

そうすることで、要求に関する情報が少なかった場合でも、アウトプットする情報が単に不具合の有無だけでなく、利用者視点での品質コメントも付加されることになり、フィードバックできる情報にも幅が出てきます。

皆さんも一度アプローチしてみてはいかがでしょうか。
最後になりますが、実務のお役に立てれば幸いです。

このエントリーをはてなブックマークに追加