QA経験の少ないチームが良い探索的テストを行えるようになるための障害と、ナイトメアヘッドラインゲームの紹介

私が現在所属しているスクラムチームでは、チームとしてQAを行えるようになるべく、定期的に勉強会を行っています。 QAチームや、スクラムのQA担当者(のようなロールを担ってしまっている開発者)に品質保証を丸投げするのではなく、全員が品質保証に取り組み、自信を持ってリリースできるようになることを目標にしています。

今回は、QA経験の少ないチームで探索的テストを行う場合の障害と、それらを改善するためのナイトメアヘッドラインゲームというレクリエーションについて紹介したいと思います。

開発者が探索的テストを行うために障壁となること

探索的テストでは、探索したい項目をチャーターに書き出して、そのチャーターを指針としてテストを行なっていきます。

良いチャーターを作ることが、探索的テストを成功させるための要点だと考えており、これを専門のQAチームではないチームが行う上で、障壁となるポイントが2点あると考えています。

  1. チャーターの抽象度が揃わない
  2. 「作る」発想から抜け出すことができない

順番に説明します。

1. チャーターの抽象度が揃わない

開発チームに限った話ではありませんが、主に複数人でチャーターを作るときに起こりがちだと感じています。

そもそも、良い抽象度のチャーターを作ることは難しいです。 具体的すぎるチャーターを作ってしまうと、テストできる範囲を狭めてしまうことになり、自由に探索できる探索的テストの利点を損ねてしまいます。 逆に、抽象的すぎると、今度はテストの焦点が定まらず、探索が終わった時に、結局何がしたかったのか分からなくなってしまうこともしばしばあります。

抽象的すぎることや具体的すぎることの問題もさることながら、それ以前に、QAに慣れていない開発者が探索的テストを行う場合、開発者間でチャーターの抽象度が揃わないことがより大きな問題なのではないかと思っています。 少なくとも抽象度が揃っているならば、テストをたくさんすることで具体的すぎるチャーターの問題をカバーしやすかったり、あるいはテストの途中でチャーターが良い指針になっていないことに気づきやすいと思います。

しかし、抽象度が揃っていないチャーターだと、チャーターのダブりや指針としての良し悪しに気づきにくく、探索は終わったけど結局何をテストしたかったのかわからない、探索したかったものを全て探索できたかもわからない、意味のないテストになってしまいがちです。

2. 「作る」発想から抜け出すことができない

メインで開発を行っているチームが探索的テストを行うとき特有の問題だと考えています。 開発者やPOなど、普段「作る」ことを中心に考えている人たちは、なかなか「脆弱性を発見する」や「何がいけないのか」といった考え方に切り替えるのが難しいです。 また、特に開発者は、テスト対象となる機能を自身が設計、実装していることも多いため、コードベース中心の発想から抜けきれず、結果として他の機能と組み合わせた時に発生するバグや、非機能要件を見逃しがちだと思っています(スプリントレビューで、何故こんなことに気づかなかったのか、という初歩的な誤りを指摘されるのはこのケースの見逃しが結構多いと感じます)

ナイトメアヘッドラインゲーム

上記2点を改善するための取り組みとして、ナイトメアヘッドラインゲームがかなり良かったので紹介します。

ナイトメアヘッドラインゲームは、Explore it!という探索的テストの書籍で紹介されているレクリエーションで、チームで行います。(私が知らないだけで、ひょっとしたら初出は別の文献かもしれません)

自分の関わっているソフトウェアが起こしてしまった最悪のニュースの見出しを考え、そこから探索的テストのチャーターを作っていくというゲームです。 ゲームをしていく過程で、チャーターの抽象度に関する認識を揃え、「作る」発想から「脆弱性を発見する」という発想に切り替える練習ができるようになっています。

手順を説明します。

1. メンバー全員で最悪のニュース見出しを考える

例えばこんな感じです。 - 機密情報を含むA社宛のメールがB社に届いてしまった - 顧客管理画面から出力した社員情報が実は全て間違っていた

Explore it!ではニュースのヘッドラインを考えることになっていますが、toB向けサービスだと考えづらかったりもするので、必ずしもニュースぽく書く必要はないと思います。

2. 出揃ったニュース見出しの中から投票で、最も深堀りたい見出しを選ぶ

過去実際に起きてしまったことがある障害や、発生した場合影響の大きいものを選ぶと、その後のブレストが活性化しやすいと感じました。

また、私のチームは新しく加入したメンバーが多かったので、新メンバーが以前の案件で経験した障害なども取り入れながら進めました。

3. 2で選ばれた見出しが、現実になってしまった場合の原因を考える

  • 機密情報を含むA社宛のメールがB社に届いてしまった -> 複数タブを操作していて、誤操作をしてしまった

  • 顧客管理画面から出力した社員情報が実は全て間違っていた -> 出力したCSVのヘッダが消えており、内容が1行ずつずれていた

4. 3で出された原因を探索できるチャーターを考える

  • 複数タブで操作し、メールを誤送信してしまう方法を探る
  • CSVをダウンロードして、行をずらしてしまう方法を探る

まとめ

実際にやってみた感想として、初めから良い抽象度のチャーターを作ることはかなり難しいと感じました。 ですが、少なくともチャーターの抽象度を揃えことと「作る」思考からの切り替えにはすぐに役立つものだったと思います。

さらに、実際にチャーターを作るところまでやり切ることができると、次に探索的テストを行うときの心理的ハードルがだいぶ軽くなるようにも思います。

すでに探索的テストを行なっているチームや、これから品質保証活動をやっていこうというチームは、レクリエーションの一環としてやってみると面白いかもしれません。

また、余談ですが、経験豊富なメンバーがいるほどナイトメアヘッドラインが面白くなるので、そのようなチームにはぜひお勧めしたいです。

参考

Explore it!