こんにちは。QAエンジニアをしているポポラスです。私はコールセンター等でサービス受付をするシステムの受入テストを担当しております。
私の現場では、ユーザーの実際のオペレーションの情報が少なく、テストベースは要件定義書のみでテスト設計を行っております。そのような状況において、ユーザー観点を出し、実際のオペレーションに沿ったシナリオを設計するために私が工夫した3つのことを、経験事例を交えてご紹介させていただければと思います。参考になりましたら幸いです。
前提
私が経験していた現場は、システムの操作方法に関する情報が乏しく、また実際の利用者からのヒアリングが出来ない状態でした。そのような中で第三者検証として受入テストを担当させて頂いた際の経験です。
工夫したこと
以下の内容は、実際に私が現場で工夫したことになります。もし実際のオペレーションの情報が無く、設計にお困りの場合、観点出しのお役に立てることがあるかもしれません。ぜひご覧ください。
その１：機能の目的を考える
機能の目的を考えることで、実際のオペレーションに近いシナリオを導き出せることがあります。
以下は実際に私がテスト設計を担当した機能での経験事例になります。
<経験事例>
■機能
サービス対象端末の特殊在庫の表示
■機能の目的を考えなかった場合のシナリオ
まず、機能の目的を考えなかった場合のシナリオは以下になります。
前提条件：なし
シナリオの流れ：
①端末Aの画面に遷移し、特殊在庫を表示する
②特殊在庫を選択し、オーダーを完了させる
■機能の目的を考えた場合のシナリオ
特殊在庫機能の目的は、通常在庫が切れた場合かつサービス利用者がどうしてもその端末を希望する場合に、予備の在庫を臨時的にサービス利用者に提示すること、と考えられます。
上記の目的から、以下のシナリオが導き出せます。
前提条件：端末Aの通常在庫なし
シナリオの流れ：
①端末Aの画面に遷移し、通常在庫切れ表示となることを確認
②特殊在庫を表示する
③特殊在庫を選択し、オーダーを完了させる
機能の目的を考えたことで、「前提条件」と「シナリオの流れ①」がより実際のオペレーションに近い条件として導き出すことができました。
その２：3w1h
機能の目的を考えることで実際のオペレーションに近いシナリオを導き出せましたが、この「3w1h」では、そのシナリオに対して観点のバリエーションを持たせることができます。
今回ご紹介する「3w1h」は以下の要素となります。
- Who（だれが）
- When（いつ）
- Where（どこで）
- How（どのように）
実際に私の現場で実践した3w1hは以下になります。
<経験事例>
■機能
サービス対象端末の特殊在庫の表示
■「Who（だれが）」の考察
これは「システムを使用するユーザー」という理解で考察します。実際にサービス受付システムを使用するユーザーは以下3つのタイプが存在しますので、観点のバリエーションに加えることができます。
- コールセンターのオペレーター
- 店舗の担当者
- サービス利用者
■「When（いつ）」の考察
これは機能が使われる「状況」という理解で考察します。状況として以下4つのパターンが考えられます。
- 通常在庫が切れた時
- 通常在庫が補充された時
- 特殊在庫が切れた時
- 特殊在庫が補充された時
■「Where（どこで）」の考察
これは場所ではなく、私の現場の場合は機能を使用するプラットフォームという理解で考察します。プラットフォームは以下3つのパターンが考えられます。
- コールセンターのオペレーターが使う受付システム
- 店舗の担当者が使う受付システム
- サービス利用者が直接Webサイトからオーダーする受付システム
■「How（どのように）」の考察
これは「どのように機能を実行するか」という理解で考察します。以下4つのパターンが考えられます。
- デスクトップPCから特殊在庫を確認する
- ノートPCから特殊在庫を確認する
- スマートフォンから特殊在庫を確認する
- タブレットから特殊在庫を確認する
その３：UMLを使ったアプローチ
工夫その１と２は、ユースケース図やアクティビティ図といったUMLを、テスト視点で活用することで導き出すアプローチもあります。UMLを使うことで、機能の目的や3w1hの観点を整理することができ、整理した観点を俯瞰的に見ることで、観点の抜け漏れや新しい観点の気付きにも繋がります。
ユースケース図
アクティビティ図
その４：顧客から情報を引き出す
顧客から市場での実際のオペレーションの情報を引き出すことで、シナリオの設計に活用できます。これは最もシンプルな方法ですが、最も実際のオペレーションに近い情報となりえます。
その５：観点のフォーマット化
工夫その１～４で導き出した観点をフォーマット化することで、他要件の観点出しにも流用が可能となります。更にフォーマットをチーム内で共有し、ユーザー観点を蓄積していければ、フォーマットのブラッシュアップを行っていけます。
結果
上記の工夫を行うことで、受入テストのユーザー観点不足を緩和することができ、より実際のオペレーションに近いシナリオを充実させた受入テストを行うことができます。
まとめ
実際のオペレーションの情報がほとんど無い現場でも、機能の目的や3w1hを考え、UMLを活用することで、ユーザー観点を導き出していけます。更に、導き出した観点をフォーマット化してチーム内で資産化することで、今後の他要件への流用やユーザー観点のブラッシュアップなどの付加価値を生むことができると思います。
本記事の内容は、受入テストのテスト設計としては当たり前の内容かもしれませんが、私の経験事例が皆様の参考になれば幸いです。
最後まで読んでいただき、ありがとうございました。
