こんにちは。2022年1月に入社した1人目の社員QAエンジニアの須賀(@kawabeaver)です。なぜか息子に「かわちーばー（ビーバーのこと）」や「アマビエ様」と呼ばれています。
1人目のQAエンジニアとして入社したりQAエンジニアのいない開発チームに配属されたりすると、最初は何をやって良いか悩む方が多いのではないかと思います。私もその一人でした。そこで、私が1人目のQAエンジニアとして入社してから最初に行う品質向上施策を決めるまでのプロセスを紹介したいと思います。
現状の分析
まずは課題の把握や施策の優先順位を決めるために現状を分析します。
既存メンバーへのヒアリング
何も仮説を持たない状態で闇雲に分析するのは大変なので、まずは既存メンバーが感じている開発プロセスに関する課題をヒアリングします。 漠然と「課題は何ですか？」と聞いてしまうと回答者が答えにくいため、開発プロセスの各工程に対して課題を聞くようにしました。 ただし、ヒアリングだけだとメンバーが認識しやすい課題しかわからないので注意が必要です。
現状のプロセスの把握
ヒアリングではわからない課題を把握するため、実際にどのような開発プロセスで作業が行われているかを把握します。 具体的には、以下のようなことを行いました。
- 開発プロセス（ルール）が記載されたドキュメントの確認
- 実際に行なっている作業のログの確認
- チケット
- プルリクエスト
- テストに関するログ
- Slackのログ
- 既存メンバーへどのような作業を行なっているかのヒアリング
- 実際にスクラムイベントに参加
本番障害（市場バグ）の分析
前述の2つの活動は開発プロセスから課題を見つける活動でした。 多面的に課題を分析するため、実際に顕在化した問題からボトムアップで開発プロセスの課題を分析していきます。
欠陥流出原因（テスト漏れ原因）を分析する上では、テストプロセスを分割し、各欠陥流出原因がどの工程にあったかがわかるように分析していきます。
- テスト対象の把握
- リスク分析（どの機能にバグがありそうかなど。特にリグレッションテストを考える上で重要）
- テスト観点（抽象的なテスト条件）の洗い出し
- テスト観点を詳細なテスト条件にする（テスト技法を適用する、など）
- テスト手順を作成（作成するテストデータ、環境、UIの操作手順、期待結果など）
- テスト実行
なお、本来は欠陥混入原因と欠陥流出原因の両方を分析するべきですが、今回は自分だけで分析しやすい欠陥流出原因のみ分析を行いました。*1
施策の決定
会社としての成果を最大化するため、以下の3つの視点で施策を考えました。
パレート図
パレート図はQC7つ道具の1つで、データを項目別に分類して件数が多い順に並べた図のことです。 不具合原因の件数や不具合原因の割合を把握しやすくすることができます。パレート図で明らかになった不具合原因の割合が高いもの（改善の伸び代が大きいもの）から優先的に対策していきます。
テストプロセスの工程ごとに欠陥流出原因の件数を計測した結果*2、課題の原因の割合は以下のような順位でした。
- テスト観点の洗い出し
- テスト手順を作成（適切なテストデータでのテスト）
- リスク分析（いわゆるデグレード）
- テスト対象の把握（認識齟齬など）
- その他
上記の分析結果から、まずは上位2つの「テスト観点の洗い出し」と「テスト手順を作成」をメインに施策を打つことにしました。
短期的に成果を出す
品質上の課題を放置し続けると、顧客やエンドユーザーの体験を損ねて会社の損失が発生し続けます。そのため、長期的な理想を目指すのと並行して短期的に課題を解決する必要があります。
既存メンバーのスキル向上（研修など）や知識不足を補うナレッジの作成は成果が出るまで時間がかかります。そこで、短期的には、私自身がテストプロセスに直接関与することにしました。
開発スピードを落とさない
品質向上は会社が成長するための1つの手段です。品質向上のために開発スピードが遅くなった結果、会社の成長が鈍化しては意味がありません。そのため、品質向上施策は開発スピードを落とさない施策にする必要があります。
既存のプロセスを大きく変更したり、テストに必要な作業を大幅に増やしたりすると開発スピードが遅くなります。また、私自身の作業がボトルネックになると開発スピードも遅くなります。 これらのことを考慮し、以下のようにしました。
- 開発者が自分でテスト設計・実施を担当するプロセスを変えず、私が並行してテスト設計のレビューを実施する
- 漏れがちなリグレッションテストや非機能テストだけテスト設計書の見出しに追加
成果と今後の展望
開発チームの方々の協力もあり*3、顧客からの新規本番障害の報告件数は私が入社した時と比べて約50％減少しました。 しかしながら、私が目指すのは本番障害の報告をゼロにすることなので、まだまだやることは沢山あります。 具体的には、以下のようなことを行う予定です。
- テスト設計レビューでは検出しにくいUI上の問題を検出する探索的テスト
- デグレードを検出するための自動テストの強化
- 認識齟齬を減らすための仕組み作り
- UX改善（妥当性確認）のための分析と対策
- 私に依存しているプロセスからの脱却
- 開発チームのテストスキル向上（マニュアル作成、研修など）
- 知識不足を補うナレッジの作成（機能一覧、テスト観点表など）
- QAエンジニアの仲間を増やす
- そもそも欠陥が混入しにくくなる状態を作る
- 目指す品質や各工程で担保する品質の定義
We are Hiring!
コミューンでは企業とユーザーが融け合う社会の実現を一緒に目指してくれるソフトウェアエンジニア、SRE、QAエンジニアを募集しています。 コミューンに興味のある方は是非以下のページからカジュアル面談のお申し込み、またはご応募をよろしくお願いします！
