ソフトウェアテストの７原則〜品質向上委員会の体験談〜 4レース目

私たちは2023年4月に株式会社ラクスパートナーズのQAエンジニアとして入社して、4人で活動しているチーム【**品質向上委員会**】です。
4月から3ヶ月間の研修を経て、現在は社内の月報管理システムの開発PJにQAチームとして参画しています。
私たちの活動を、JSTQB認定テスト技術者試験にでてきた<font color="DarkOrange">テストの7原則</font></font>に照らし合わせて4投稿のリレー方式で振り返ってみております。💨
本日がラスト投稿となります！！✨

👇<font color="DarkOrange">前回までの投稿をご覧になっていない方はこちらへ</font>👇
①[ソフトウェアテストの７原則〜品質向上委員会の体験談〜 1レース目](https://qiita.com/kinoshitanagisa/items/47be389520e4e037ce11)👤@kinoshitanagisa
②[ソフトウェアテストの７原則〜品質向上委員会の体験談〜 2レース目](https://qiita.com/yuikuma0420/items/853997382b5ee5ded7a9)👤@yuikuma0420
③[ソフトウェアテストの７原則〜品質向上委員会の体験談〜 3レース目](https://qiita.com/ty04sep/items/f406743d8708a5302a9b)👤@ty04sep


## 原則７｜ 「バグゼロ」の落とし穴
> テスト担当者は可能なテストすべてを実行でき、可能性のある欠陥すべてを検出できると期待する組織があるが、原則 2 と原則 1 により、これは不可能である。また、大量の欠陥を検出して修正するだけでシステムを正しく構築できると期待することも誤った思い込みである。例えば、指定された要件すべてを徹底的にテストし、検出した欠陥すべてを修正しても、使いにくいシステム、ユーザーのニーズや期待を満たさないシステム、またはその他の競合システムに比べて劣るシステムが構築されることがある。
 
### **＜経験から考える＞**
 リリース直前にクライアントの要求に応えられていないことが判明したときのお話。📖
新規機能開発の際に、クライアントに目的と機能の仕様については確認していたのですが、そのあとは開発者の判断とそれに対するQAの改善案のみで開発を進めており、テストを実施した際にも「バグ」は検出されませんでしたが、リリースの直前に仕様の最終確認を取った際に、<font color="DarkTurquoise">「もっとこうしたものが良かった」</font>と言われてしまいました、、、。

**💭原因は、、？**
機能開発の目的やリリースの判断基準が明確になっていないまま開発を進めてしまった結果、ユーザビリティに十分な配慮ができず、<font color="DarkTurquoise">クライアントの期待との相違</font>がシステム完成後に発生してしまいました。

完成した後、QAが設計したテストケースを実施し、たしかに「バグ」はありませんでした。しかし、クライアントの要求を満たせていないのであれば本末転倒ですし、いくら「良いものを作れた！」と思っても、開発者やQAの**自己満足**になってしまいます。

:::note info

仕様については初期段階でしっかりと擦り合わせておき、こうしたらいいかな？
という提案は、クライアントの要求や目的を軸に判断をすること、
判断が難しい場合はクライアントへ確認をとることが必要不可欠と言えます。

さらに、原則1でもあるように、バグゼロはあくまでも「用意したテストケースの
範囲内で」のお話なので、バグが検出されていないからと言って**完璧なシステム**とは言えないということを理解しておく必要があるのです。
:::



## 原則０｜ 〇〇の理解
> 私たちが社内PJにてソフトウェアテストの７原則を基に活動していく中で、テスターではなくQAとして**これが最も大事**！と思ったことを、原則に追加してみました。
タイトルはあえて伏せますが、皆さん分かりますか？


### **＜経験から考える＞**
まずは、私たちがPJやプロダクトの品質を向上させるために行なってきたことを挙げてみます。

**<font color="DarkTurquoise">▶早期からのQA目線での仕様擦り合わせ</font>**
上流工程からQAが関わることで、早期から機能の目的や仕様の詳細を固めて開発に取り掛かってもらう
画面上の動きだけではなく、ソースコードやDB等の内部の動きまで網羅する

**<font color="DarkTurquoise">▶機能の仕様書を作成(ドキュメント化)**
アプリケーションを実際に操作しなくとも、仕様を確認できる
誰でも、いつでもアクセスできるようにすることで、仕様や目的を統一できる


### ～QAが誰よりもサービス全体を知っている～
…という存在でありたい、、！誰にも負けたくない。という強い思いがあります！
**<font color="DarkTurquoise">開発者👤**は、その人が開発した機能にはとても詳しいですよね。(そうであってほしい)

**<font color="DarkTurquoise">QA👤**は？というと、、、
1機能について詳しいだけではなく、**その機能の影響範囲全体を把握しておくべき**だと思っているんです。
1つの機能を知っているだけでは、マージ後の結合テストを実施した際にバグが検出されてしまうかもしれないし、どこにどう繋がっているのかが分からなければ、期待結果も正しく定義することができません。
だからこそ、QAが誰よりもサービス全体を知っているべきで、それをドキュメント化してQA以外のメンバーにもその知識を共有することが必要だと思います。

:::note info

ソフトウェアテストの７原則と言われていますが、
実はQAとしての活動においては**原則０ 仕様の理解**が初めにあるべきで、
かつ最も重要であるということを提案したい、、！
:::


## 最後に
学習したことをPJでしっかりとアウトプットしていくと、ただのテスターにならずに済むと思うので、考えることをやめないようにしたいです。
QAとしてできることに制限をかけずに、幅広く品質向上のためにこれからも活動を続けて参ります。
また、原則０は「そんなの夢物語だよ📖」と笑われてしまうかもしれませんが、夢を語ってもいいじゃないか！と思いますし、**QAチームの必要性や価値を世界中に伝えたい**という我ら【**品質向上委員会**】の目的としても、ぜひ自信を持って言いたいです。

最後まで読んでいただきありがとうございました！✨
せっかくの機会なので、この私たちのリレー記事をご覧いただいた有識者の皆様からのご意見等をいただけたら嬉しいなと思いますので、コメント・いいねお待ちしております💕

👇<font color="DarkOrange">振り返りはこちらから</font>👇
①[ソフトウェアテストの７原則〜品質向上委員会の体験談〜 1レース目](https://qiita.com/kinoshitanagisa/items/47be389520e4e037ce11)@kinoshitanagisa
②[ソフトウェアテストの７原則〜品質向上委員会の体験談〜 2レース目](https://qiita.com/yuikuma0420/items/853997382b5ee5ded7a9)@yuikuma0420
③[ソフトウェアテストの７原則〜品質向上委員会の体験談〜 3レース目](https://qiita.com/ty04sep/items/f406743d8708a5302a9b)@ty04sep