1人目のQAがQAチームの活動を振り返ってみた（2022年7月〜12月編）

はじめに

コミューン株式会社でQAチームのマネージャーをやっている須賀(@kawabeaver)です。

今回の記事は前回の記事の続編で2022年後半の振り返りです。本記事は前回の記事が前提となっていますので、ぜひ前回の記事も読んでみて下さい。

QAエンジニアの方やQAチーム立ち上げを考えている方の参考になれば幸いです。

はじめに
今までのおさらい
7月〜9月（オンボーディング体制構築、共通認識作りなど）
10月〜12月（イベント登壇、Gherkin記法の活用）
- イベント登壇
- Gherkin記法を用いたテストケース作成
We are Hiring!

今までのおさらい

2022年6月の段階ではQAエンジニア2名で活動、各開発チームのミーティング等に参加
開発チームはWeb3チーム、Mobile1チームある
Webの開発チームでは、QAエンジニアはテストケースのレビューを行い、Webエンジニアがテスト設計・テスト実施を行う
Mobileの開発チームでは、QAエンジニアがテスト設計・テスト実施を行う

7月〜9月（オンボーディング体制構築、共通認識作りなど）

7月に3人目のQAエンジニアが入社したので、オンボーディング体制を構築しました。また、QAチームも3名に拡大したので、QAチームの方向性やテストに関する認識合わせを行いました。その他、各QAエンジニアの強みを活かして新たな施策を実施しました。

オンボーディング体制の構築

会社全体のオンボーディングとは別にQAチーム用のオンボーディングを実施しています。QAチーム用のオンボーディングは、最初に須賀から開発組織の全体像の雰囲気などを理解するための説明を行い、QAエンジニア用のToDoリストを実施する内容となっています。
本記事ではオンボーディングの概要だけ紹介します。

開発組織全体の雰囲気などを理解するための説明
- 開発組織のこと（カルチャー、組織の構成、開発プロセスの概要）
- QAチームのこと（メンバー紹介、業務内容概要、今後やっていきたいこと）
- 新入社員の方に1ヶ月後、6ヶ月後、12ヶ月後にどのような状態になってほしいか
ToDoリスト
- 業務に関する環境構築
- ドメイン知識や事業の理解を深める（営業資料やCS向け社内資料等を読む）
- 開発プロセスの資料を読む
- テストプロセスの資料を読む
- プロダクトの理解を深める（ヘルプページを見ながら各操作を試す）
- 実際の案件で他のQAエンジニアとペアテスト設計を行う

QAチームの方向性の決定

私が入社して半年が経過し、QAエンジニアも増えたためQAチームの今後の方向性について1回目の検討を行いました。

結論としては、「Webエンジニア自身が良いテスト分析〜テスト実施を行える体制を作る」です*1。なお、ここでの「良いテスト」とは「プロダクトが期待通りに動作するかを確認する作業（検証）」の質・効率が良いという意味です。「プロダクトが顧客の要求を満たすかの確認（妥当性確認）」を誰がどのように行うかは決めていません。
本記事では上記結論に至った背景の概要のみ記載します。詳細は別の場で紹介したいと思います。

文化
- コミューンはWebエンジニア自身がテストを行う文化である*2。また、当時のWebエンジニアが自分たちだけでリリースまでの作業を行えるようになりたいと考えていた
効率
- 実装者と手動テスト実施者を分けることで生じる分業のためだけに必要なコストを減らしたい*3。例えば
  - フィーチャートグルを用いて少しずつ開発・リリースを繰り返すため、実装者と手動テスト実施者を分けるとコミュニケーションや実装者のコンテキストスイッチが頻繁に発生して効率が悪い
  - 分業すると誰でも理解できる文章で丁寧に再現手順・再現環境などを記載した不具合チケットを作成する必要がある。それなりに工数がかかる作業のため作業工数を減らしたい
- 須賀は効率的なテストを行う上でソフトウェアエンジニアの知見も重要だと考えており、Webエンジニアにもテストに積極的に関与させたい。例えば、自動テストやアーキテクチャを考慮したテスト分析など*4
テスト分析の難易度
- 基本設計（外部設計）から連想できないような複雑な条件の不具合は多くないため、職人的なテスト実施者でなくても一定の品質を担保できると考えた
- フィーチャートグルを用いて開発しているため、1リリースあたりの開発の規模が小さく、テスト漏れのリスクが比較的小さくなっている*5
組織の拡大のしやすさ、教育コスト等
- テスト分析〜テスト実施作業のリソースをQAエンジニアに依存してしまうと、組織が拡大した際にQAエンジニアのリソースがボトルネックになりやすい*6
- コミューンはフロントエンド、バックエンドの両方でTypeScriptを用いているため、Webエンジニアがテスト以外のことで学習すべき技術が少なくて済む（テストに関する学習にリソースを割きやすい）

もちろん、コミューンは朝令暮改を恐れず最適なものを目指すカルチャーなので、QAエンジニアがテスト分析・設計を行うといった方針に変更する可能性もあります。しかしながら、Webエンジニア向けの研修資料作成といった施策はそのままQAエンジニア向けに利用できるため、仮に方針が変わっても現在の取り組みは無駄にはならないと考えています。

開発者向けにテスト技法の学習資料・試験問題を作成

上記の方針に従い、3人目のQAエンジニアにテスト技法の学習資料と試験問題を作成してもらいました。学習対象は同値分割、境界値分析、デシジョンテーブル、状態遷移テストの4つです。試験問題は弊社のプロダクトのトレーニング機能を使った選択問題で、テスト技法を利用した結果どのようなテスト条件となるかといった内容を問うものになります。

なお、学習資料と試験問題作成の際には、以下の書籍を会社で購入して参考にさせていただきました。

ソフトウェアテスト技法練習帳
 ソフトウェアテスト技法ドリル ※当時は第2版はなかったので第1版を購入しています

テストの十分性に関する共通認識作り

QAエンジニアの人数が増えたため、QAチーム内でどの程度テストすべきかの認識合わせを行いました。また、その内容の概要をWebエンジニアにも発表しました。そうすることで、テストの過不足に関する認識齟齬を減らせると考えています。

結論としては、テストが十分か否かを決めるのは「納得感」*7なのですが、なぜそうなるかの説明や「納得感」を醸成するための工夫を紹介しました。

テストの7原則を用いて説明

テストの7原則を用いて、以下の点を説明しました。

全ての条件をテストすることはリソース的に不可能。また、欠陥がない事は示せない。なので、どこまでテストすれば十分かは自分で決めないといけない
テストは状況次第。プロジェクト毎にテストすべきものは変わるので、プロジェクト毎に上記判断が必要

コードカバレッジや機能カバレッジ等の長所、短所の紹介

上記カバレッジだけでは確認できない視点があることを紹介しました。

長所
- 各成果物の記載内容を網羅的にテストしたことがわかる
短所
- 各成果物にテストすべきものが全て正しく記載されている可能性は低い。例えば
  - そもそも基本設計書といった文書に全てのことを記載する工数がない*8
  - 文章で表現しにくいものもある。例えば、UIのアニメーションの詳細など
  - コードカバレッジだけだと実装漏れや仕様誤認には気づけない

テストの費用対効果の考え方の紹介

テストの費用対効果の考え方として、品質コストとリスクベースドテストを紹介しました。ただし、これらの数値を厳密に算出することは難しく、ある程度定性的に判断せざるを得ないことも説明しました。

カバレッジ以外の納得感を醸成しやすくするための工夫の例を簡単に紹介

ISO/IEC 25001の品質モデル（ただし、品質モデルはテストのために作られたものではない*9）、論理的機能構造、ラルフチャートといったモデルがあることを紹介しました。

統計的手法の運用が難しい話を紹介

バグ密度・テスト密度などの統計的手法は各プロジェクトの前提条件を整えるのが難しくて使いづらい話をしました。*10

QAチーム内で不具合分析の開始

3人目のQAエンジニアはメーカー系出身で不具合分析の経験が豊富でした。そこで、3人目のQAエンジニアの経験を活かし、QAチーム内でポストモーテム対象以外の不具合分析を実施しました。不具合分析で生まれた施策により、障害を1件防ぐことができました。

不具合分析のやり方の以下の記事をご参照ください。

tech.commmune.jp

テストケースのレビューをスキップできる運用ルール作成

テストケースのレビューをプロセスに追加した結果、どのような修正でもレビュー待ちが発生するので気軽に軽微な修正を行いにくくなっていました。そのため、リスクの少ない修正に関しては、テストケースのレビューをスキップする運用ルールを作成しました。

今はルールのバージョン2をトライアル中で、以下のような修正をレビューのスキップ対象としています。

プロダクトに影響のない修正（自動テストの修正、開発作業用のファイルなど）
軽微なリファクタリング
テキストやCSSなど静的な要素の修正
仕様変更を伴わない軽微な不具合修正。ただし、修正の影響範囲はコードレビューで確認する

E2Eテスト拡充計画の立案

テスト分析漏れの不具合を削減した結果、次に優先順位が高い不具合はリグレッション（デグレード）となりました。

コミューンでは既に開発時にCypressの自動テストを実装するルールになっていましたが、このルールが適用される前に実装された機能にはCypressの自動テストが実装されていないものがありました。そこで、開発経験のある2人目のQAエンジニアが不足しているE2Eテスト拡充の計画を立てました。

E2Eテストでどのようなテストをするかの方針については、正常系の基本的なユースケースのフロー（ハッピーパス）のテストを広く浅く網羅する方針に決めました。なぜならば、過去の不具合を分析した結果、リグレッションの不具合の大半はハッピーパスのテストで防げる内容だったからです。

10月〜12月（イベント登壇、Gherkin記法の活用）

2人目のQAエンジニアが残念ながらプライベートの事情により退職することになりました。そのため、E2Eテスト拡充計画を一旦中止し、今までの活動を維持しながら採用活動をすることになります。

イベント登壇

たまたまお誘いをいただき人生で初のイベント登壇を行いました。

test-talk.connpass.com

私が発表した内容は以下のスライドになります。

speakerdeck.com

上記内容を発表した理由ですが、私の思考過程を公開することで世の中から新たな手法が生まれるきっかけになればと考えました。

今のところテスト分析やテスト設計のやり方について正解はなく、開発プロセスやプロダクトの性質によってもテスト分析のやり方は変わると考えています。また、私個人の経験として、人によって合うやり方、合わないやり方があると考えています。*11

そのため、発表を見てくれた皆さんが、自分のコンテキストにあったテスト分析のやり方を生み出すきっかけになればと考えました。

Gherkin記法を用いたテストケース作成

今まではテストケースの書き方は殆ど自由でしたが、Gherkin記法を用いるようにしました。背景としては、コミューンのプロダクトでは管理者やユーザーの所属グループなどユーザー属性によって行える操作が異なるので、機能開発時に誰が何をできるか・できないのかを決めなければいけません。この「誰が操作を行うか」の考慮漏れを削減するために、Gherkin記法で誰が操作を行うかを必ず記載するルールとしました。
個人的な体感ですが、Gherkin記法の導入により誰が操作を行うかの考慮漏れはかなり減ったと思います。ただし、記載する手間が増える、テストケースが縦長になり見づらいといったデメリットは発生しています。