#◆はじめに
こんにちは。
ご高覧いただいてありがとうございます。
QA歴約17年のKoです。
これまでQA業務に携わってきた経験から良くある課題やそれら課題への解決方法などを共有できたらと思います。
今回のテーマは「テストでミスを減らす方法」をお伝えできたらと思いますので、ぜひこの後もご一読いただけたら嬉しいです！
#◆テスターあるある
テストに関わっていると以下のようなことがよくありませんか？
● テストケースに書いてあるのにテスト実行ミス
● 仕様書に書いてあるのにテストケースの作成ミス
これらは結構多いし、人依存なので解決難しいと感じている人は少なからずいると思います。
今回はこれらの良くある課題について、取り組みをしましたので共有したいと思います。
###▼テストケースに書いてるのにミスをする
テストケースの項目に書いてあるかつ詳細に書かれていて、それでも見落としてしまうケースがあります。
この手の見落としは新人テスタ－より、熟練テスターまたは業務に慣れて自信のついてきたテスターの方（以降、併せて熟練テスターとします）に見られることが多いと感じます。
####●なぜ熟練テスターが多いと感じるのか？
熟練テスターはテストナレッジが高く、様々な場面でテストケースにないことなども気づいてくれたり仕組みを理解していることで、思わぬ不具合を見つけてれくれたり本当に助かる存在ですが、一方で慣れてしまったことでいつもテストはこんな感じでやっていると脳内テストケースでテストをしてしまうことがあります。
結果、テスト観点漏れが発生してしまったり、テストケースがアップデートされていた場合も見落としてしまったりすることがあります。
では逆に新人テスターについてですが、新人の頃はテストナレッジがないのでテストケースに書いてある内容を忠実に実行しているのでテストケースの完成度が高ければミスが発生しにくい状態にあります。
また新人の頃はわからないことを質問して解決することが多いため、書いてあるのにミスをするというのが少ないと考えられます。
そのため熟練テスターに良く見受けられると思われます。
###▼仕様書に書いてあるのにテストケースに項目作成ミス
テストケースの作成はテスターの中でも、基礎ができている人材が主に担当すると思われますが、そういったしっかりした方でもテスト観点の考慮漏れをしてしまうことがあると思います。
テストケースは作成する前にテスト設計をして、各作業工程でレビューを入れ段階的に進めるのが理想ですが、サイクルの早い（1日でテストケースを作成しないといけないなど）場合はそういった設計をおこなう時間も作れないのが現実です。
特に弊社のコンテンツでは施策サイクルが早く、テスト準備～テスト終了までの期間が短く、十分な設計期間やレビューによるフォロー体制が取れないのが現状です。
※レビューはしているが、ポイントを絞っておこなうことが多い
そのため、テストケース作成時には自身の脳内ナレッジから観点を洗い出している場合が多く、結果しっかりとした設計をおこなっていれば洗い出せた観点が漏れてしまったということが考えられます。
#◆テスターの見落としは個人に依存するので改善が難しい
この手のミスはテスター個人の問題もあって改善が難しく、再発防止策に良く挙げられるのは「注意喚起します！」が多いと思います。
ですが、これって本当に効果あるのでしょうか？
実際注意することで一時的な効果はありますが、テスター自身の精神的負荷が高まるだけであまり健全ではないと私は考えています。
※もちろん課題を伝えて認識してもらうことは大事ですが注意するってことは少なからず相手を責めている状態になるので、個人的には好ましいと思ってないです
そこで実際テスターがミスするロジックをよく見て改善すべき点を洗い出せてない可能性はないかと思い今回紹介する方法を導入しました。
#◆対策
これまでは個々のナレッジに頼ったテストをしてきましたが、結局のところ人間の記憶は曖昧であることが多く、何か指標がないとミスしてしまうというのは改善できないため、その指標となる観点表を作ることにしました。
###▼テスト観点表
主な目的は自身のテストやテストケースで観点として漏れている部分が無いか、振り返るために作成しています。
テスト実行前やテストケース作成後にそれぞれ基礎的な観点を再認識したり、実際にテストケースに盛り込まれているか確認するものと思ってください。
これは一部ですが、このようにどの案件でも利用できるように汎用的に基礎観点を洗い出しています。
弊社ではこの観点表を以下のルールを決め、確認するタイミングや頻度を決めて導入しました。
| 役割 | 利用タイミング/頻度 |
|---|---|
| テスター | 毎月月初：1回 |
| テストケース作成者 | 新規テストケース作成時ごと |
利用タイミングを決めることでルーチンに盛り込む目的と、回数を多くしすぎないことで負荷にならないように検討した結果このような頻度で対応しています。
例えば毎日テスト前になどおこなったりすると、本来のテストに対して負荷が高くなり、結果負荷の分だけミスが発生してしまうなど導入目的に即してないことが起きてしまったり、回数を多くすることで慣れで流し見するようになるというのを防ぐためにこの頻度でおこなってます。
もしかしたら他にもっといい頻度があるのかもしれませんが、そこは今後の結果を見つつ検討したいと思っています。
###▼導入した結果
まだ導入から間もなく結果としてはデータが少ない状態ですが、現在の実績から導入前比で約3～4割ほどテスト実行でのミスが減少しています。
データとして短い期間でしかお伝えできないのが残念ですが、少なくとも効果はある？と思いますので、良かったら参考にしてみてください。
#◆最後に
テスターは何百、何千、何万という単位のテストをしています。
テストケース作成者も同様に多くのテストケースを作成しています。
そのため、脳内からのナレッジだけでおこなうにはあまりにも物量が多くミスが発生しやすい状況です。
QAをやっていると体制にもよりますが、「テスターはなんでこんな当たり前のことを見落とすの？」と開発の方に言われることがあります。
実際はこの物量の中でミスを0にするのは難しく、十分な準備期間が本当は必要です。
ですが、十分な準備にはコストがかかりますし、事業貢献も我々の使命です。
なので、今回のようにちょっとした工夫で改善を試みてはいかがでしょうか。
今後も工夫をすることで人的なミスを減らせないか考えていきたいと思います。
もしこんな方法があるよ！とかありましたらぜひ教えてください。
またこの内容を見てほんの少しでも役に立てたら嬉しいです。
#◆宣伝
前回はテストマネージャーの育て方を共有しましたので良かったら見てください！