はじめに
私たちは、2023年4月に株式会社ラクスパートナーズのQAエンジニアとして入社して、4人で活動しているチーム【品質向上委員会】です。
4月から3ヶ月間の研修を経て、現在は社内の月報管理システムの開発PJにQAチームとして参画しています。
そこで、JSTQB認定テスト技術者試験の学習で誰もが一番に覚えたといっても過言ではない「ソフトウェアテストの7原則」に照らし合わせて振り返ってみたいと思います。
4投稿のリレー形式で書いていきますので、ぜひ全部ご覧ください！
@kinoshitanagisa 12/8(金)
@yuikuma0420 12/9(土)
@ty04sep 12/16(土)
@j_haru 12/17(日)
原則１| テストは欠陥があることは示せるが、欠陥がないことは示せない
テストにより、欠陥があることは示せるが、欠陥がないことは証明できない。テストにより、ソフトウェアに残る未検出欠陥の数を減らせるが、欠陥が見つからないとしても、正しさの証明とはならない。
＜ 経験から考える ＞
〜 テスト対象の裏の顔（見えないところ）に注意 〜
私たちは仕様や影響範囲の抜け漏れを最小限にするため、機能単位で仕様書を作成し、テストケース作成時には綿密なレビューを行ったり、テストケースの作成と実施を異なるメンバーが担当するなどの対策を講じてきました。
しかしながら、これでも抜け落ちるテストケースがあります。全てのテストをパスした場合でも、それはあくまで「用意したテストケースの範囲内で」の話にすぎないんだなあと、、
確かに、テストだけで完璧なシステムであることを保証することは難しい！！
しかし、テストを実施し、発見されたバグを改修することで、本番環境での重大なバグが発生するリスクを抑えることができます。
そのために、影響範囲の理解、重要な機能におけるバグ発生の防止策の検討、バグが発生した場合の迅速かつ適切な対応策の考慮が必要になるのではないかなと思います。
原則２| 全数テストは不可能
すべてをテストすること（入力と事前条件の全組み合わせ）は、ごく単純なソフトウェア以外では非現実的である。全数テストの代わりに、リスク分析、テスト技法、および優先度によりテストにかける労力を集中すべきである。
＜ 経験から考える ＞
〜 ナントカ2世さんへの配慮？ 〜
PJチームに参画するまでは、「全数テストは不可能」なんてただの言い訳だろうと思っていました。確かに、入力欄のテストケースなんて私でさえ何通りも思いつく。全て実施するのは気が遠くなると思う。でも、やればできるだろうと思っていました、、、
そして、思いつく限りのテストケース全てを実施することが、ユーザーのためになると思っていました、、、
しかし、PJチームに参画して、納期という時間の制約、かけられる人員の制約など、やる気だけではなんとかならないことがあると知りました。実際の現場では、これに費用の問題も絡んできます。いろんな制約がある中では、すべてのテストを行うことは、やる気以外の面から見ても不可能だと痛感しました。
・・・全数テストが不可能なら、どのように品質を保証するの？？
私たちが意識していることを以下に示します！
▶︎ 優先度をつける
機能の追加によって、一番あってはならない不具合はなにかを明確にし、その項目についてのテストケースをより丁寧なものにしました。
▶︎ 冗長なテストをしない
PJチームに参画する前にも、研修の一環として同じシステムに対してテストを実施していました。その際には、ユーザー検索時にナントカ２世さんが検索されるか（数字も入力できる仕様になっているか）を確認するテストケースを作っていました。これはもしかしたら今後ナントカ２世さんが入社するかもしれないという、私なりの配慮でした！（当時は、心の底から私ナイスっ！！と思っていた）
今思えば、なんの根拠もない自己満テストケースだなあと、、、お恥ずかしいです😂
今回のPJでは、利用者やクライアントが求めている仕様（機能やシステムの目的）を把握することで、冗長なテストケースを省くことができました。
さいごに
現在のPJチームに参画して、３度のリリースを経験しました。
どうしてあのテストケースを実施しなかったんだろう、、と後悔することもありました。
今後、実施するテスト内容、実施しないテスト内容どちらにも、なぜ実施する必要があるのか、なぜ実施する必要がないのか、根拠を持たせることを意識していきたいです。
最後まで読んでいただきありがとうございます！
明日（12/9)は@yuikuma0420さんが、原則3,4についてお話しします！ぜひご覧ください！