はじめに
私たちは2023年4月に株式会社ラクスパートナーズのQAエンジニアとして入社して、4人で活動しているチーム【品質向上委員会】です。
4月から3ヶ月間の研修を経て、現在は社内の月報管理システムの開発PJにQAチームとして参画しています。
私たちの活動を、JSTQB認定テスト技術者試験にでてきたテストの7原則に照らし合わせて4投稿のリレー方式で振り返ってみております。
今回は第3レース目！！
前回の投稿をご覧になっていない方は以下のリンクからぜひご覧ください！
ソフトウェアテストの７原則〜品質向上委員会の体験談〜 2レース目@yuikuma0420
原則５｜殺虫剤のパラドックスにご用心
同じテストを何度も繰り返すと、最終的にはそのテストでは新しい欠陥を見つけられなくなる。この「殺虫剤のパラドックス」を回避するため、テストとテストデータを定期的に見直して、改定したり新規にテストを作成したりする必要がある（殺虫剤を繰り返し使用すると効果が低減するのと同様に、テストにおいても欠陥を見つける能力は低減する）。ただし、自動化されたリグレッションテストの場合は、同じテストを繰り返すことでリグレッションが低減しているという有益な結果を示すことができる。
＜経験から考える＞
そもそも同じテストを何度も繰り返すのはどんな時でしょうか？
- システムのバージョンが変わった時
- 仕様が変わった時
このようなタイミングでのテストって、多くの場合でずっと同じ人もしくは、そのプロジェクトに長く携わっている人がテストを実施しますよね？
そうすると、、、
テストケースを更新しないでもシステムを知っているからこそなんとなくテストができちゃう
ですが👀
引き継ぎが発生した場合や、そのシステムの理解が浅い人がテストを実施する場合はどうでしょうか？
引き継がれたテスト実施者に十分な仕様理解の時間がないまま、リグレッションテストを実施する場合も考慮する必要があります。
新しい欠陥を見つけるどころか、テスト実施者がバグではないものをバグだと認識してしまうおそれがありますよね？
じゃあ何が大事なのか
〜 テストケースを最新時状態に保つこと 〜
特に、リグレッションテストのような繰り返し使うものに関しては最新状態に更新していくことが必要不可欠！
とはいえ、最新状態に保つのは難しいし、後回しにしがちだし、めんどくさいかもしれない。。。
ただ、QAとしてはとても大事なことだと思ってます！
最新状態に保たれているよと言い張れるためにも、QAエンジニアが誰よりも仕様を把握しておくことも大事ですね🔥
ちょっと横道
↓
原則６｜ テストは状況次第
状況が異なれば、テストの方法も変わる。例えば、安全性が重要な産業用制御ソフトウェアのテストは、e コマースモバイルアプリケーションのテストとは異なる。また、アジャイルプロジェクトとシーケンシャルソフトウェア開発ライフサイクルプロジェクトでは、テストの実行方法が異なる。
＜経験から考える＞
「〇〇機能のテストをしてください」と言われたら、その機能のテストをするためにテストを作成していくと思います。
実際に私はただなんとなくテストを作成していました。
機能によってテストが違うだけで、状況によって変わるようなテストは作成していませんでした。
ただ、テストって粒度を細かくすれば無限にできますよね？
とはいえ、時間がないからこのぐらいでいいか？ともできないですよね。
大事なのは テストをした先のことまで考えること
自分たちが取り組んでみたのは
〜 リリース判定基準を設けること 〜
テストをしたその先にあるのはリリースであることが多かったです。
状況によってリリース判定基準は変わります。
リリース判定基準に沿ったテストを作ることが状況に合わせたテストなのかなと思いました！
判定基準を設けることで、
- テスト作成の粒度が揃う
- 冗長なテストがなくなる
- テスト作成前に基準を設ければ、テストしたからリリースできるよって言える。（実際には言えてない。）
なんとなくテストを作成、実施するのではなくて、なんのためのテストなのかを考えることが大事なのだと思いました🔥
最後に
私たちはテスターとしてではなくて、QAとして何ができるのか、何を意識しなくてはいけないのかを常に考えています！
思考を続けることがなんだかんだ大事なのかなと思ってます。
だからこそ、ご意見等あれば沢山いただきたいです！
最後まで読んでいただき、ありがとうございました！
次回の「品質向上委員会投稿リレー」は
12/17(日)に@j_haru さんが、原則7と⚪︎⚪︎についてお話しします
お楽しみに～