はじめに
皆さん、こんにちは！Generosity QAチームのChoです。
最近、プロダクトごとのテスト仕様書の作成に取り組んでいるところ、「観点」って一体なんだろうという疑問がよくよく出てきました。さらに、ある画面を見て、何をテストすべきかを言語化する必要性も感じています。
この度、その観点という概念を理解しつつ、テスト観点を考え出す流れについてご紹介したいと思います。
期待読者
- これからテスト(QA)の仕事に挑戦したい方
- テスト実施だけではなく、設計にも興味のある方
観点を出す=「何をテストするのか」を考える
皆さんは、「観点」というのは何だと思いますか。
確かに、考え方 - 立場 - 見かたというキーワードと関連がありそうです。同じものを見ていても人によって思い浮かぶものはそれぞれ異なるのでしょう。
『ソフトウェアテスト教科書 JSTQB Foundation 第3版』には、下記のような説明があります。
テスト分析は「何をテストするのか」を決定し、テスト設計は「それをどうテストするか」を決定する
ここで筆者は、何をテストするのかについて、つまりテスト分析がまさに「観点を出す」段階ではないかと思っています。
実戦：ログイン画面では、何をテストすべきなのか
本記事で出す観点の範囲は、コンポーネントテストレベルでの機能テストに限っています。
PC版LINEアプリのログイン画面をテスト対象画面とします。その中で、メールアドレスとパスワードの入力欄から見ていきましょう。
さらっと見たところ、何をテストすればいいかと思いますか。簡単に、テキスト欄に文字が入力できるかどうかの確認がありますね。また隣の人から、別の観点でのテスト内容を言ってくるかもしれません。
テキスト欄に文字が入力できるよね。じゃ、文字類ごとに入力できるかどうか確認しよう
うん、パスワードは敏感な情報だから複雑で強いものにしたいね。パスワードルール仕様があるとして、その形式が間違ったらどうなるか確認しよう
画面に見える文言も大事だと思う！ユーザーに親切な文言になっているか確認しよう
というふうにですね。それらの観点を以下のようにまとめられます。
| 観点 | 確認内容 |
|---|---|
| デザイン | 文字色、文字配置、レイアウト、文字入力時のデザイン など |
| 文言 | タイトル、本文、プレースホルダ、注釈 など |
| 入力形式 | 文字類（英文、記号、スペース..）、桁数、組み合わせルール など |
| エラー表示 | エラー表示タイミング、エラー条件 - 文言とのマッピング など |
続いて、欠かせない画面要素の一つであるボタンについても観点を出していきます。
ボタンをタップすると友だちリストが見える画面に遷移されるか確認しよう
デフォルトはグレー色で押下できないんだ。では、メールアドレスとパスワードを入力すると、活性化になることを確認しよう
間違って連打してしまった場合でも二重処理されないことも確認しなきゃ
ということで、以下のようにまとめられます。
| 観点 | 確認内容 |
|---|---|
| デザイン | ボタン色、文字配置 など |
| 文言 | ボタン名 など |
| 活性／非活性状態 | 活性化になる条件を満たした場合、逆に満たしていない場合 など |
| 押下時の挙動 | 画面遷移、ダイアログ表示 など |
| 連打 | 二重処理されるかどうか など |
最後に、QRコードの観点を出していきます。
端末でQRコードを読み取ると、LINEアプリが開くことを確認しよう
QRコードの有効期限があるはずだから、有効期限が過ぎている状態で読み取ったらどうなるか確認しよう
そのQRコードをURL化して最後の1文字だけ変えて読み取るとどうなるか確認したいね
ということで、以下のようにまとめられます。
| 観点 | 確認内容 |
|---|---|
| デザイン | QRコード色、サイズ など |
| 読み取り後の挙動 | 端末での挙動、PCでの挙動 など |
| 有効期限 | 有効期限前後での読み取り可否 など |
| URL整合性 | 不正なアクセス時のエラー表示 など |
というふうに、テスト観点を出すには、画面に見える要素一つひとつに対して、表示系としてあるべき姿はなんだろうとか、動作系としてどういう振る舞いをするんだろうといった疑問を自分自身に投げる必要があります。
テスト観点を考え出すコツ
ややこしいユーザーになってみる
言い換えて、たらればの考え方ができる人になることです。サービスアプリに対して「こういう操作もあり得るわ！」と思っていくことで、テストすべき観点を見つけ出すことができると思います。
マインドマップを活用する
マインドマップを活用すると、頭の中でごちゃごちゃになっていた概念を整理することができると思います。テスト観点を出すときも同じよう、若干の頭痛を感じるほど（？）頭の中が混乱してしまう瞬間がよくありますね。そのときは、画像のようにマインドマップで概念を整理していくことをお勧めします。
まとめ
改めて、ここまでの内容をまとめます。
テスト観点の概念
テスト対象画面や機能に対して「何をテストするのか」を決める多方面の視点
テスト観点を考え出す流れ
- Step1.テスト対象画面にて、UI要素を洗い出す
- Step2.それぞれの要素に対して、確認したい & 確認すべきだと思うところを書き出す
- Step3.その内容を大きい観点とし、詳細な確認内容を挙げていく
上述で出していた観点だけで、高いカバレッジでテストができるわけではありません。表示・挙動系だけではなく、アカウント認証とか別システムとの連携といったボリュームの大きい観点も隠れているのでしょう。
また、その観点が何かによって、テストレベルやテストタイプも異なってしまうため、適切なテスト観点を決めていくのは大事な作業ですね。
ということで、本記事にて「テスト観点」という概念が少しでも整理できたら幸いです。