私たちは2023年4月に株式会社ラクスパートナーズのQAエンジニアとして入社して、4人で活動しているチーム【品質向上委員会】です。
4月から3ヶ月間の研修を経て、現在は社内の月報管理システムの開発PJにQAチームとして参画しています。
私たちの活動を、JSTQB認定テスト技術者試験にでてきたテストの7原則に照らし合わせて4投稿のリレー方式で振り返ってみております。💨
本日がラスト投稿となります！！✨
👇前回までの投稿をご覧になっていない方はこちらへ👇
①ソフトウェアテストの７原則〜品質向上委員会の体験談〜 1レース目👤@kinoshitanagisa
②ソフトウェアテストの７原則〜品質向上委員会の体験談〜 2レース目👤@yuikuma0420
③ソフトウェアテストの７原則〜品質向上委員会の体験談〜 3レース目👤@ty04sep
原則７｜ 「バグゼロ」の落とし穴
テスト担当者は可能なテストすべてを実行でき、可能性のある欠陥すべてを検出できると期待する組織があるが、原則 2 と原則 1 により、これは不可能である。また、大量の欠陥を検出して修正するだけでシステムを正しく構築できると期待することも誤った思い込みである。例えば、指定された要件すべてを徹底的にテストし、検出した欠陥すべてを修正しても、使いにくいシステム、ユーザーのニーズや期待を満たさないシステム、またはその他の競合システムに比べて劣るシステムが構築されることがある。
＜経験から考える＞
リリース直前にクライアントの要求に応えられていないことが判明したときのお話。📖
新規機能開発の際に、クライアントに目的と機能の仕様については確認していたのですが、そのあとは開発者の判断とそれに対するQAの改善案のみで開発を進めており、テストを実施した際にも「バグ」は検出されませんでしたが、リリースの直前に仕様の最終確認を取った際に、「もっとこうしたものが良かった」と言われてしまいました、、、。
💭原因は、、？
機能開発の目的やリリースの判断基準が明確になっていないまま開発を進めてしまった結果、ユーザビリティに十分な配慮ができず、クライアントの期待との相違がシステム完成後に発生してしまいました。
完成した後、QAが設計したテストケースを実施し、たしかに「バグ」はありませんでした。しかし、クライアントの要求を満たせていないのであれば本末転倒ですし、いくら「良いものを作れた！」と思っても、開発者やQAの自己満足になってしまいます。
仕様については初期段階でしっかりと擦り合わせておき、こうしたらいいかな？
という提案は、クライアントの要求や目的を軸に判断をすること、
判断が難しい場合はクライアントへ確認をとることが必要不可欠と言えます。
さらに、原則1でもあるように、バグゼロはあくまでも「用意したテストケースの
範囲内で」のお話なので、バグが検出されていないからと言って完璧なシステムとは言えないということを理解しておく必要があるのです。
原則０｜ 〇〇の理解
私たちが社内PJにてソフトウェアテストの７原則を基に活動していく中で、テスターではなくQAとしてこれが最も大事！と思ったことを、原則に追加してみました。
タイトルはあえて伏せますが、皆さん分かりますか？
＜経験から考える＞
まずは、私たちがPJやプロダクトの品質を向上させるために行なってきたことを挙げてみます。
▶早期からのQA目線での仕様擦り合わせ
上流工程からQAが関わることで、早期から機能の目的や仕様の詳細を固めて開発に取り掛かってもらう
画面上の動きだけではなく、ソースコードやDB等の内部の動きまで網羅する
▶機能の仕様書を作成(ドキュメント化)
アプリケーションを実際に操作しなくとも、仕様を確認できる
誰でも、いつでもアクセスできるようにすることで、仕様や目的を統一できる
～QAが誰よりもサービス全体を知っている～
…という存在でありたい、、！誰にも負けたくない。という強い思いがあります！
開発者👤は、その人が開発した機能にはとても詳しいですよね。(そうであってほしい)
QA👤は？というと、、、
1機能について詳しいだけではなく、その機能の影響範囲全体を把握しておくべきだと思っているんです。
1つの機能を知っているだけでは、マージ後の結合テストを実施した際にバグが検出されてしまうかもしれないし、どこにどう繋がっているのかが分からなければ、期待結果も正しく定義することができません。
だからこそ、QAが誰よりもサービス全体を知っているべきで、それをドキュメント化してQA以外のメンバーにもその知識を共有することが必要だと思います。
ソフトウェアテストの７原則と言われていますが、
実はQAとしての活動においては原則０ 仕様の理解が初めにあるべきで、
かつ最も重要であるということを提案したい、、！
最後に
学習したことをPJでしっかりとアウトプットしていくと、ただのテスターにならずに済むと思うので、考えることをやめないようにしたいです。
QAとしてできることに制限をかけずに、幅広く品質向上のためにこれからも活動を続けて参ります。
また、原則０は「そんなの夢物語だよ📖」と笑われてしまうかもしれませんが、夢を語ってもいいじゃないか！と思いますし、QAチームの必要性や価値を世界中に伝えたいという我ら【品質向上委員会】の目的としても、ぜひ自信を持って言いたいです。
最後まで読んでいただきありがとうございました！✨
せっかくの機会なので、この私たちのリレー記事をご覧いただいた有識者の皆様からのご意見等をいただけたら嬉しいなと思いますので、コメント・いいねお待ちしております💕
👇振り返りはこちらから👇
①ソフトウェアテストの７原則〜品質向上委員会の体験談〜 1レース目@kinoshitanagisa
②ソフトウェアテストの７原則〜品質向上委員会の体験談〜 2レース目@yuikuma0420
③ソフトウェアテストの７原則〜品質向上委員会の体験談〜 3レース目@ty04sep