はじめに
私たちは2023年4月に株式会社ラクスパートナーズのQAエンジニアとして入社して、4人で活動しているチーム【品質向上委員会】です。
4月から3ヶ月間の研修を経て、現在は社内の月報管理システムの開発PJにQAチームとして参画しています。
私たちの活動を、JSTQB認定テスト技術者試験にでてきたテストの7原則に照らし合わせて4投稿のリレー方式で振り返ってみております。
今回は第2レース目！！
前回の投稿をご覧になっていない方は以下のリンクからぜひご覧ください！
ソフトウェアテストの７原則〜品質向上委員会の体験談〜 @kinoshitanagisa
原則３｜早期テストで時間とコストを節約
早い段階で欠陥を見つけるために、静的テスト活動と動的テスト活動の両方をソフトウェア開発ライフサイクルのなるべく早い時期に開始すべきである。早期テストは、シフトレフトとも呼ばれる。ソフトウェア開発ライフサイクルの早い時期にテストを行うことにより、コストを低減または削減できる。
＜ 経験から考える ＞
新しい開発を始めるとき、開発の初期段階からテストを組み込めないかなとQAメンバーで考えました。まだ、モノができていないのにテストを組み込むとは？と思いましたね。
ここでいう「テスト」とは、実際にモノを動かして行うテストではありません！
では、どういう事かと言うと、、、
～ 完成形を想像し、思考のテストを実施 ～
新しい機能の要件定義や仕様の擦り合わせが行われる中で、テストケースを検討するならどうする？と考えるようにしました。このアプローチにより、まだコードが書かれていない段階から潜在的な問題や仕様の改善点を発見し、よりユーザー目線を意識した提案ができたのではないかなと思います。
また、提案するという積極性も養われた気もします。
今後もこの取り組みを意識し、初期段階での働きかけの精度を上げていくことで、後の段階での修正や再作業にかかるコストを削減できると期待しています。
原則４|欠陥の偏在
リリース前のテストで見つかる欠陥や運用時の故障の大部分は、特定の少数モジュールに集中する。テストの労力を集中させるために欠陥の偏在を予測し、テストや運用での実際の観察結果に基づいてリスク分析を行う。（原則 2 で触れたことと同様）
＜ 経験から考える ＞
現在の開発PJにおいても各機能の設計や構築難易度の違いから、欠陥の発生数に差が生じています。さらに、画面数やサイトの規模が大きくなれば、多くの機能が付き、影響範囲が広がっていきます。
よって、複数の開発者やチームが作業をすることになり、その開発者・チーム毎にスキルの差も生じ、ある部分では欠陥が多発するなどの「欠陥の偏在」が生じるのかなと感じました。
だからこそ、なにをしたらよいのか、、、
～ 欠陥の集中箇所の特定 ～
欠陥が集中している箇所や機能が特定できれば、その部分を優先してテストを実施し、欠陥の数を減らすことができます。また、設計の際に指摘事項として、開発者に意識してもらうことにも繋げられます。
で！す！が！
欠陥の集中箇所の特定と簡単に言っていますが、これができていれば苦労はしないです、、、。
今できることとして、まずは過去のテスト実施や不具合報告からバグ分析等を行い、欠陥の集中箇所を特定できるようになることから始めようと計画しています。私たち品質向上委員会の伸びしろは無限大です。
最後まで読んでいただき、ありがとうございました！
次回の「品質向上委員会投稿リレー」は
12/16(土)に@ty04sep さんが、原則5,6についてお話しします
お楽しみに～