【QA】アジャイル開発で本質的な評価をするためのテスト観点作成方法

背景

Webアプリ開発においてアジャイル開発を採用している現場は多いと思いますが、開発サイクルが早い分PMやディレクターがテスト工数をあまり割けず、リリースしたものの思っていた物と違ってすぐに修正するといったことが有ると思います。

一度リリースしたものを大きく変更するのは手戻りも大きく非効率なので極力起こしたくありません。

今回書くのは、きっちりとテストをして細かなバグをつぶす100点のテストケースではなく、短い時間でも最低限手戻りが発生しない80点のテストケースを作るための考え方です。

ユーザーのシナリオから観点を考える

まず手戻りが大きくなるケースでは基本的に仕様に不備があります。

仕様書をベースにテストケースを考える場合、仕様書に設定されていることが実装されているかを漏れなく確認するという点でとても有効な作り方ですが、そもそも仕様がイケてるかはテストケースでは確認できません。

そこをカバーするやり方が「シナリオからテスト観点を考える」方法です。

ユーザーの操作手順や業務フローを元に観点を考えるため、 仕様の検討漏れや細かい条件の考慮漏れを見つけやすいといった特徴があります。

次の項目から順に書いていきます。

シナリオから観点を考える時の考え方

1.機能の目的を整理する

まずは作ろうとしている機能がなんのために使われるのか整理して、 ユーザーの目的を理解する。

2.整理した目的を満たすために何が必要か考える

1で整理したユーザーの目的を満たすために必要な操作、条件を考える。
※ ペルソナ設定に近いです。

3.考えた操作・条件を細分化する

2で考えた操作を画面単位くらいで細分化する。
僕の場合はここで

• 必要な画面が足りてるか？
• 操作の流れが不自然じゃないか？
  を考えてます。

※ 2と3は一緒にやることもあります。

4.細分化した操作に関連する画面のテストを考える

3で細分化して出てきた画面が正しく動くことを確認する。
ここで表示崩れとかバリデーション条件とか考えます。

仕様書（機能）ベースで作る場合との使い分け

シナリオから観点を作る別の方法を紹介しましたが、こちらが優れているというものではありません。 向き不向きが有るので状況に応じて使い分けれると良いと思います。

	向いていること	不向きなこと
機能ベース	機能の漏れが出にくい	仕様自体の正当性は表現できない
シナリオベース	仕様の考慮もれに気づきにくい	仕様書の機能を網羅するときに注意が必要

まとめ

今回シナリオベースでの観点の作りかたを紹介しましたが、機能ベースでの作り方と比べてどちらが良いというものではありません。
テストケースで何を確認したいか、どちらが自分に合っているかで決めればよいと思います。

個人的には、QAはテスト設計～以降のタスクのみではなく、本当にユーザーの役に立つのかも考えるべきだと思っているので、シナリオベースのテスト作成のほうが好きです。