テスト観点出しは難しい？

最近担当チームのエンジニアさんから「テスト観点出しが難しい」という話をよく聞きます。QAエンジニア視点だとテスト観点の洗い出しってテストを作る工程で必ずやることなので、難しいとか簡単とかいう概念すらなかった（卵料理作りたいならまず卵の殻をわりますのレベル）のですが、難しいと言われると難しく感じてきたここ最近です。

いい機会なのでテスト観点について考えてみることにします。

テスト観点とは

観点という言葉の定義は以下。

物事を観察、考察するときに、判断の根拠となる一定の立場。見地。」

精選版　日本国語大辞典

テスト観点を端的に言い換えると、「テストを考察、設計するときに、判断の根拠となる一定の見地」となりそうです🤔
なるほどなんとなくわかります。（たぶん）

テスト観点作り隊

これをもうちょい実用的にすることを考えると、以下の説明が一番しっくりきました。

テスト観点とは、テストにおける「(テスト目的)のために(対象)の(部品)の(何)を確認する」の「何」にあたります。

https://service.shiftinc.jp/column/5029/

上記を踏まえて会員登録という機能でテスト観点を考えてみるとこんな感じです。テストの目的については「プロダクトが機能適合性を満たしているかを判断するために」としておきます。

• 会員登録後にログイン後の画面に遷移できるかを確認する

• 会員登録時に入力した情報でログインできるかを確認する

• 入力フォームでバリデーションチェックされるかを確認する

テスト観点と機能仕様の関係

仕様＝テストの期待値です。

遷移できるか（観点）
　- 会員登録後、どの画面に遷移するのか（仕様）

ログインできるか（観点）
　- 入力したどの情報でログインできるのか（仕様）

バリデーションチェックされるか（観点）
　- どんなバリデーションがあるのか（仕様）

この時、仕様が曖昧だと、テストの期待値が書けません。よって、テスト設計は仕様のレビューでもある、というわけです。また、テスト設計を担当エンジニアが実装前に行うことで、仕様の抜け漏れにも早い段階で気づくことができるはずです。

ただし、観点の抜け漏れがなく、仕様の抜け漏れもないテストや仕様書を作成し続けられる人はこの世にいないと思っています👼なので、作った人以外がレビューするという工程がとても大事です。

いろいろ書いてますが、実際には何回もテストを作ってみたりしないとパッとしないと思っていますので、テスト観点出しを楽しみつつできるようなワークを企画中です😊

そのお話はまた後日！