不織布のようにQAをする

現在QA(品質管理/保証)としてテスト自動化・手動テスト設計・チームのマネージメントなどをしている石塚です。
QA歴10年ですが最近意識するようになったことを共有します。

それは
「QAのプロセスそのものにもバグは存在する」
です。

無駄のないプロセス、無駄の無いテストケース、無駄のない実行。
これらを目指すのは大事なことです。
（自分がいかに無駄が嫌いかはこの記事に書きました）

しかし人間が絡んでくる以上、下記を意識する必要があります
 - 人間はミスをする
 - 人間のモチベーションは上下する
 - 人間はそれぞれ別の経験値を持ち、別の行動をする

これらを踏まえてあえて一見無駄に見える「ダブり」や「ゆらぎ」を考慮したオペレーションを組むことで逆に効果的なQAができるようになりました。

この狙いはマスクの「不織布」に近いです。
ガーゼのような布はきれいに織られていますが隙間があります。
不織布(wikipedia)は一見雑に絡みあってますが隙間がなく、マスクとしては有能です。

不織布的QAの狙い

やったこと（ざっくり）
- 複数人複数プロジェクト体制
1プロジェクトに1人専任QAの体制をやめ、複数プロジェクト(プロダクト)を複数人チームで見る体制にしました。

- 作業の中でダブり・ゆらぎを許容(利用)する 
下記に具体例を上げていきます。

ミスが起きる前提で手動テストの設計・実行プランを組み立てる
詳細かつ網羅性も完璧なテストケースの作成は、コストを考えると現実的ではありません（仮に作れても結局読み間違えや記録ミスが起きる可能性はあります）。

ここはある程度粒度の大きいテストケースで許容します。
しかしそうなると解釈の違いや勘違いが発生しやくなります。
そこで特にバグを出してはいけない機能などは、同じ観点・テストケースであっても複数人で並列実行します。この一見無駄な作業で大きなバグを防いだことがあります。
当然すべてをダブルチェックをするという話ではなく、プロダクトやメンバーの特性を把握してリスクが高いところを狙って複数人実行してもらいます。

開発者が見た箇所をQAが再確認することも
開発者とQAで確認箇所がきれいに分担できているのがプロセスとしては美しく、それを目指すのは当然です。
ただ、これもリスクの高い箇所は開発・QA両方が同じチェックをすることを許容します。
例えばPull Requestで開発者が「こういう動作確認をしました」と書いた箇所もQAが再チェックすることでバグを防ぐこともよくあります。これは開発者とQAの頭に中にある前提条件の違いや実行条件の違い（ゆらぎ）が影響したと思われます。

モチベーションを考慮する
人間なので得意不得意、好き嫌いは存在します。自分もプロとして認めたくないですがやっぱりあります。なのでメンバーの適正・好き嫌い・体調を考慮した作業分担（もしくはあえてダブらせるなどの考慮）が必要です。

また「仲間と働いている」という意識によるモチベーションアップもチームの成果に大きく影響します。
「体調が悪いときには休めるんだ」「思っていることを言える仲間がいるんだ」という心理的安全性も担保できます。

仲間意識を利用する例としては、メンバーが同時に探索的テストをするイベントがあげられます。スクラムでいうスウォーミングみたいなものです。
たしかにテストは個別にできるものだし、むしろ無駄な重複が発生しそうな気もしますが、実際ワイワイとやることで一体感を感じ、集中力も出てトータルでは時間帯効果が高くなります。

経験・能力のばらつきを考慮する
現場では経験の少ないメンバーは常に存在します。その方たちの成長には仲間の存在が必要です。一人でドキュメントを読む研修もあっていいですが、実際に仲間と作業する時間のほうが集中力も出て研修としては非常に効果的です。
前述した「得意不得意」の話でいうと、あえて不得意なことを克服してもらうためにチャレンジしてもらうケースもあるでしょう。
これも複数人によるダブリ実行などを使うことでリスクを許容し、成長の場を提供できることになります。

不織布的QAによるその他の効果

メンバー離脱時のリスクを低減できる
人間なので仕事は休みますし辞めることもあります。担当1人の専任体制だと離脱時のインパクトが大きくなります。その人特有の知見・能力が消えてしまい、開発チームと築いた関係性がなくなることで、仕切り直しのコストがかかることになります。
 
負荷の波が分散できる
1人で1つのプロジェクトを見ると、開発都合の負荷の波をもろに受けてしまいます。閑散期にただドキュメントを読むだけの日々になってしまったり逆に忙しくなって残業続きになることもあります。
これを、例えば3人チームで3つの並行するプロジェクトを見ている状態にすると、波が分散されるイメージがつくと思います。
また複数人いることにより、1人の大きな勘違いや行き違いによる開発/QAの手戻りが起きる確率も減ります。

「知見の幅広さ」でQAのバリューが出せる
特定のドメイン・機能の専門知識を持ったQAメンバーは非常に頼もしいですが、そこまで成長するにはかなりの時間がかかります。特にその機能の開発者を超える専門知識をつけるのはかなり大変です。

複数人体制だとより多くの機能に幅広く触れることになります。それにより視野の広さで貢献できるようになります。これは比較的短期間で身につけられる武器です。
例えば「あのプロジェクトでバグが起きた時と状況が似てないか」「あっちのプロダクトに似た機能あったけどそこは影響しないか」などの知見は蓄積しやすいものです。
プロダクトが大きくなったり増えてくると一流の開発者でも影響範囲を誤ることはあります。そこを指摘することでQAとして貢献できます。

トータルで見ると生産性は上がる
不織布的QAはあえて無駄を増やしているわけではなく、現実に取りうる最善の手段を取るという話です。なので上述の利点が重なった結果、トータルでみると生産性が高いチームになります。

ただしプロセス改善・成長のための努力をやめてはいけない

今回は「雑に仕組みを作ってもマンパワーでカバーできるよ」という話ではありません。
毎回ダブリ作業が必要になっている工程や、結果的にバグを見つけたもの危なかったケースなどは、結果オーライとするのでなく改善していくことが必要です。

また、そもそも詳細なテストケース作成を諦めずに低コストでいいケースが作れるようなシステムを作る、という方向性もあるかもしれません。

専門的知識をつけるのは難しいと言いましたが、個人個人では諦めずにドメイン知識・開発知識を身につける努力は続けるべきです。

また担当QAの人数の話は社内外の事情も絡むでしょうし、専門性の高いプロジェクトなどを考慮するとかならず複数にすべきという話ではありません。

まとめ
「手を動かすのは人間である。人間の能力はバラバラで、気分が落ちこむこともあるし、ミスもする。そこを「仲間」の存在がカバーしモチベーションも高めてくれる」

この「人間らしさ」を意識しつつ日々プロセスの改善を続けていきたいと思います。