テスト設計から考える現場コミュニケーションのポイント

はじめに

 こんにちは！QAチームのmmmです。

 普段は主にKINTOのWEBシステム関連のQA業務に携わっています。
扱うシステムにはお客様が目にされるフロント領域、販売店様が使用されるバックオフィス領域に加え、社内業務用のシステムが複数あり、これらのシステム間では各種データが連携されています。

 最近では「KINTO Unlimited」、「KINTOかんたん申し込み」などのアプリが増えましたが、新しい機能や要件が追加されると既存システムとの関わりや影響を整理しなければなりません。
そのため、システム単位での仕様はもちろんのことですが、その他にもKINTOのサービスにおける一連の業務を理解し、データの流れを掴む必要があります。
 システムや新しい機能要件が増えるたびに整理することが増え、QA観点にも影響するので個人的にはQA業務の中で大事かつ大変な作業と感じています。

 そこで今回はテスト設計に焦点を当て、
過去担当した案件で直面した課題から現在開発チームとやりとりする際に意識していることについてお話ししていこうと思います。

よくある課題

同じ機能の仕様が複数の資料に存在する

 プロジェクトには様々な開発チームが参加していることもあり、同じ機能に対してそれぞれのチームに資料が存在することがあります。そのため下記のようなことが発生しやすいです。

• 資料間で内容に差異があり、正しい仕様がわからない
• 資料間で文言揺れがあり、コミュニケーションにすれ違いが起きる
• 開発側でも本来考慮すべき仕様が埋もれてしまいバグに繋がってしまう

検討中ステータスの仕様が存在する

 資料を読み進めていると「確認中」や「？」など、まだ仕様が確定されていない表現で記載されていることがあります。これらはテスト設計、実施に下記のような影響があります。

• テスト設計：仮のテスト観点で進めるため、テストケース数が仮決めになる（増減する可能性がある）
• テスト実施：未確定範囲のテストは進められない、また、仕様変更が生じた際にはケースの修正作業が発生する

各システムの状態を俯瞰できる資料がない

 利用者に見えている実際のフロントエンド領域の状態表示に対して、裏側のバックオフィス領域では細かくステータスを保持していることがあるのですが、そこをぱっと見て分かるような資料が必ずしも存在するとは限りません。

 たとえば、ECサイトで商品を購入する際、大体は下記のようにお客様側のステータスよりお店側の方が（実際はおそらくもっと）細かく分かれていたりします。

 その両方を俯瞰的に見られる資料がない場合、システム間のデータ連携の観点が必要なため、テスト設計に際しQA側で整理する必要があります。

計算系の仕様がコードで記載されている

 金額や日数計算が必要なテストがある場合、開発仕様を確認しますがコードでそのまま記載されていることがあります。この場合下記のような影響があります。

• 読み解くことに時間を要する
• テスト実施までに第三者が見て分かるように仕様をまとめておかないとQA作業が属人化してしまう

開発チームとのコミュニケーションで意識していること

プロジェクトの概要を把握する

 前述で挙げた課題はプロジェクトの性質上避けられないこともあるため、
まずはプロジェクトの発足の背景などを聞き、QA側でもその目的や経緯などを理解することで仕様理解の促進にも繋がり、仕様に対して過不足がないかどうかなどの疑問を持てるようになると考えています。

一通りのシナリオオペレーションの説明をお願いする

 各システムの仕様書があるので資料に書いてあることは読めばわかる…という話ではありますが、
システムを理解している開発側から直接説明を受けることで下記のようなメリットがあります。
（一通り仕様を認識し、俯瞰できる資料はQA側の理解用に自作することが多いです。）

• 想定アクター／ユーザーの操作がわかりやすい
• データの流れのイメージがしやすい
• タイムリーに質問ができ、理解促進になる

資料の棲み分けを確認する

 この機能要件や画面デザインに対して正しい仕様が記載されている資料はどれなのか、ほかにも資料が存在するが古いメモ程度のものなのか、こちらでは判断できないので単純に確認していきます。
 各開発チームが担当している領域の内容が最新で正になることが多く、都度質問することが多いので開発側の負担も考えクローズドクエスチョンを意識して質問しています。

＜例＞
「●●の仕様については、資料Aが正しい認識でよろしいでしょうか？
資料Bにも同様の内容が記載されていましたが少し内容が異なるため確認させてください。」

制約事項を確認する

 QA作業する上で現状わかっている制約事項がある場合、事前に共有をお願いすることでQA側の対応も検討しやすくなります。

計算系などの複雑な仕様は別途説明会をお願いする

 様々な価格やプランが存在するため、その分計算式も複数存在します。
似たような計算式でも持ってくる値が微妙に違うこともあり、間違いを事前に防ぐため開発担当者の説明を求める上で下記を明確にすることを意識しています。

• そもそもの金額の意味
• 計算式に使う値の意味や参照する場所
• 日数の数え方
• テストする上で気をつけることがあるか
• 計算用ツールの存在

 計算系はテスト実施の効率を考え計算用ツールをQA側で自作することが多いため、開発担当者と都度認識合わせを行いながら仕様をまとめ最終的にツールに反映しています。
 また、今回計算系をあげましたが、理解が難しいと感じた仕様は素直に開発担当者に直接聞きに行くことが多いです。

おわりに

 今回執筆依頼があった際に内容に悩んでいると、本ブログ担当も兼務している開発チームの方から「QA依頼時にQAチームがどんな情報を欲しがっているのか分かると助かる」といった旨の言葉をいただきました。
 この内容にはあまり沿ってはいないですが、まずはQA業務のとっかかりであるテスト設計での課題に対する情報を発信することで、テスト以外のQA業務への認知に少しでも役に立つと良いなと思い執筆いたしました。

 また、今回述べた課題に対する対応は現在すでに開発チームから配慮いただいているところもあり、QA立ち上げ当初と比較すると随分整理された作業環境になっていると実感しています。

 ただ資料だけでは見えない情報を整理するのもQA業務の一つと考えているので、仕様を読むだけでなく他仕様への影響などを模索し整理する作業は引き続き頑張っていきたいと思っています。