バグからリバーステスト分析

自身の経験で出たバグから逆算（リバーステスト分析？）して、テスト観点に含めるためにはどんな考え方が必要だったのかを忘備録としてまとめます。

バグの例

1️⃣既存機能の考慮漏れバグ
2️⃣機能と機能の組み合わせで起きたバグ
3️⃣別ルートのバグ
4️⃣目的を達成していないバグ

１.「既存機能の考慮漏れバグ」に関して

仕様書にも書かれていない考慮漏れは開発メンバーも把握していません。
今回は機能そのものの漏れというよりは既存の機能に対する漏れのバグでした。
これらを仕様書レビューの段階で見つけ出し検討してもらうためにはやはり既存機能のドメイン知識が必要です。
そもそもどんな既存機能に影響が与えられてて、その既存機能自体はどのような機能があるのか。踏み込んだ一歩先まで仕様を把握をしていないと漏れを見つけることができません。
正直、そこまで仕様を追う時間はありません。実装を行った開発の有識者に確認を取ると手っ取り早いのかもしれませんが体系的な資料があると役に立つのかもしれません。

2.「機能の組み合わせで起きたバグ」に関して

仕様に書かれている単体機能のテストを行っただけでは完全ではありません。
その機能の設定を行った状態で他の操作を行った時に、ちゃんと機能が動くかどうかの確認も必要です。
色々な観点を思いつく人は複雑な条件下での組み合わせを考えられています。

3.「別ルートのバグ」に関して

たとえばお店の情報などを登録する際、自ずと思い浮かぶのは「登録画面」です。しかし、本当に登録画面からしか登録ができないのでしょうか？
もしかしたら外部から情報をインポートできたり、他の操作を行うことで勝手に登録されたり、自分の手ではなくシステム側が登録するなど別ルートの登録方法があるかもしれません。
行う操作に対して、動線が複数あるかも？という疑問を持っておきたいです。

4.「目的を達成していないバグ」に関して

エラーメッセージがている状態でも次へ進めてしまうとバグに遭遇しました。
そもそもメッセージはなぜ出すのでしょうか？
「エラーメッセージが出る」ということはどこが間違えているか理解できるようにするためでもありますが、結果的に次へ進まないようにするためでもあります。その仕様によって最終的に何ができれば良いのか、何ができてはいけないのかの目的を考えることが必要でした。

やればよかったこと？

５W1Hを使用して機能の根幹、目的、使い方、洗い出せばよかったのかなと思います。

• What
  • 大まかな機能目的は何か
    • 何ができれば機能として問題ないのか
    • 逆に何ができなければやりたいことが達成しないのか
    • それが起こるとどのぐらいリスクが大きいのか
  • 個々の具体的な仕様の目的は何か
    • その仕様によって何ができれば問題ないのか
• Who
  • 誰が使うのか
    • 実ユーザーだけでなく、経理、営業、コンサルタントなど他に誰が操作をするのか
• When
  • いつその機能を使うのか
• Where
  • その機能の実装により、どこの画面や既存機能に影響が与えられているのか
    • そもそもの既存機能の仕様の理解ができているのか
  • プロダクト全体から見たときに、その機能はどのような立ち位置なのか
• Why
  • なぜその機能が必要なのか
    • ユーザの根本的な要求は何なのか
• how
  • どうやってその機能を使うのか

手法としてはマインドマップやユースケース図、３色ボールペン法などさまざまなものがあります。
さまざまな視点で機能を俯瞰することによって、さまざまな気づきが得られるのではないかと思います。