エンジニアが考えるべきQAは、案外ソフトスキルだ
エンジニアとして働きつつ、QAの課題解決に声をかけてもらった経験
私はゲーム開発にエンジニアとして数年携わる中で、QA責任者/QAの課題解決のPMとして呼ばれて、ゲームプロジェクトにて課題解決に当たった経験が2,3度ある。
呼ばれた理由としては
・QAとエンジニアが上手く連携出来ていない。課題特定して解決してほしい
・テスト項目消化、バグチケ起票&消化が思うのように進行していない
であることが多かった。
ヒアリングを進めると、具体的には
・QAにあたっての仕様がQAチームと上手く連携出来ていない
・実装完了の定義が甘く、QA開始時点でQA出来る状態になっていない
・テスト項目をプランナー、エンジニアが確認しておらず相違や漏れがある
・バグチケを修正したら別機能がデグレしている
・進行不能バグが点在しており、テスト項目消化がよく止まる
など要因は多岐に渡った。
一見QAのフローや手法といったハードスキルによるものに見えるが、
「結局、エンジニアの自分の実装に対する姿勢次第の話なのでは」
と思うことが多かった。
DX事業部を立ち上げてから若手エンジニアにQAについてよく分かっていないから教えてほしいと相談されるたびに、あえてテスト手法やフローの前に、下記の話をするようにしている。
QAスキルはソフトスキルだ。
エンジニアが持つべきQAスキルは、一言でいうと
「自分の実装、品質大丈夫かな？」という不安感を元に、
限られた日数と工数の中で確認作業やスケジューリングに落とし込んでいく能力
だと思っている。
要するに危険察知能力(不安感)と、計画性、遂行力が試される。
こうして見てみると、他の仕事でも変わらぬソフトスキル的な部分が強い。
いくらテスト手法を知っていても、もしかしたらバグや見落としがあるかもと実装に不安を持てなければバグはすり抜けて本番に出る。
実装に不安を持ったとしても、限られたリソースの中で計画を描く力と遂行ができなければ、バグ撲滅には至らない。
まずはエンジニアとしてこの2つを持っていることが、品質を担保するスキルとしてのQAスキルを獲得するための土台になる。
バグは怖い。本当に怖い？不安？
バグを不安に思えるかは、自分がバグを起こすことがどれだけ重みのあることと捉えられているかが起点にある。
プロジェクトを予算つけて開発に至るまでのプロセスは非常に長い。
市場調査、ユーザー仮説検証、社内投資会議、会社間の協議など多くの関門を乗り越えて、コードを書いてプロダクト開発に至っている。
エンジニアが商用コードを書けるのはそれまでの多大な努力があってこそ。
そんな中大きなバグを起こしたら、ユーザーの信頼を失って2度と使ってもらえないかもしれない。不安だ。
クライアントの信頼を失って、二度と一緒に仕事しようと考えてもらえなくなるかもしれない。不安だ。
まずはそう思えるか、バグが何かないか不安だと思える状態に立つか。
不安だから何かしなくてはと本当に思えてたら、ようやくQAに向き合う第一歩が踏み出せている状態になる。
「自分の実装、品質大丈夫かな？」という不安感を持てたとして、どうしたらいいの？
大事なポイントは以下の2点。
どちらも、限られた期間とリソースの中で、どう品質最大化のためのアクションを取るかのための指針になる。
エンジニア自身が、QAすべきポイントの濃淡を意識し、テスト項目を精査すること。
項目テスト→バグ修正→デグレ確認→最終テストという具体スケジュールを早めに引くこと。
[テスト準備段階]QAすべきポイントの濃淡を意識する
そんなにテストしなくてもいいところばかりテストされ、肝心な機能があまりテストされないかもしれない。不安だ。
一機能実装した後「何かバグがあるかもしれない」と漠然とした不安を持っただけでは、「全ての操作パターンと、実装機能以外も全てテストしてくれ」となってしまう。
一機能実装しただけなのに全てをもう一度テストする工数や期間は普通ないし、バグ修正入れるたびに毎回全てのテストをするわけにはいかない。
無理言って全てテストしたとしても、その分今回集中してテストすべきだった今回の機能実装のテストの粒度が荒くなり、結局バグが出る。
限られたリソースの中で今回の実装の目の細かいテストを実現するには、
特にテストすべき項目とそうでない項目を実装内容から見抜いて関係者に伝えることが大事。
(1) QAされるべき事項の軸を決める
「どういうところが特にバグが出そう？」に対して答えられない。漫然とテストされる。確認が漏れてバグが本番に出てしまうかもしれない。不安だ。
考え方の軸としては、
・今回の実装範囲で一番バグが出そうなところ
・バグが出るとユーザー影響が大きいかつ、改修内容的に影響が出ているかもしれないところ
に該当するような機能は何かを考える。
変更内容的にバグが出る可能性が低いところは大袈裟なパターン網羅テストはいらない。
最悪バグが出ても影響が軽微な箇所に関しては、テストこそした方が良いが、優先度上げたり時間を多く割り当てる必要はない。
QAの方や関係者とコミュニケーションするにあたり、この考え方で実装者としてのQAあるべきのスタンスをまずは決める。
(2) QA担当者との期待値のすり合わせ
QA担当者と期待値がズレていたせいで、特にテストしてほしいところがテストされずバグが出てしまうかもしれない。不安だ。
QA担当者からするとエンジニアの実装は基本ブラックボックスで、どこを特に疑うべきで、どこはバグが出にくいか分からない。
話し合いが足りない場合はQAからすると全体を薄く確認せざるを得ない。実は細かく場合分けしてテストすべき場所が正常系だけの確認になってしまうかもしれない。
実装したエンジニアがQA担当者に「特に確認してほしいポイント」と「あまり心配していない箇所」を伝えることが重要。
ここが伝えられていれば、QA期間と人数を鑑みて、一番不安が出そうな箇所に優先してQAリソースを割くことが出来る。
[テスト実施前]項目テストの品質担保
(1)テスト項目は絶対確認する
当たり前だけどテスト項目にない項目はテストされない。すなわち、誰でも気づけるような初歩的なミスや正常系がそのまま本番に出る。不安だ。
「こんなにすぐ踏むバグすら気付かず出しているの？エンジニア大丈夫？」
と思われる。不名誉この上ない。不安だ。
そう思えたのであれば、その不安心からテスト項目を見て欲しい。
(2) 外せないポイントを先にテストをお願いする
クリティカルなバグは先に検知して早く直した方がいい。QA終盤に検知されて、影響範囲が大きかったり工数が足りなくて、バグが発覚しているのに修正余力がなくなるかもしれない。不安だ。
項目テストでは、特に重要なポイントを優先的にテストするようにスケジュールを組むことが肝要。自分で定めた軸に沿って、特に重要な箇所が十分にテストされているか確認し、不足がないかを担保する。重要なポイントは早めにテストして、修正対応に余裕を持たせる。
[スケジュール]QAスケジュールの組み方
テストはしたけど、バグ修正期間が全然ないかもしれない。バグ修正したけど、デグレ確認がされずに本番に出てしまうかもしれない。不安だ。
QAスケジュールは、項目テスト→バグ修正→デグレ確認→最終テストまでを含んだ具体的な計画を早めに立てる必要がある。以下のようなありがちなミスを避けるため、スケジュールは細かく分解しておくことが重要。
(1) ありがちなQAスケジュールミス
テスト工程で必要な作業・期間が抜けているせいで、テストとバグ修正がうまくいかないかもしれない。不安だ。
特にこれらのことがQAスケジュールミスに上がりやすいので、作成したスケジュールを一度チェックしておくと良い。
バグ修正期間が足りない：名目上は取れていても、デグレ確認や他の作業を加味すると、実際の修正期間が消滅するケースがある。
デグレ確認が抜ける：バグ修正後に他の部分がデグレしている可能性があるのに、その確認をせず本番環境に反映されてしまう。
stgやprdへの反映スケジュールが加味されていない：テストとバグ修正が終わっても、ステージング環境や本番環境に反映するスケジュールが不足していることが多い。
(2)具体的な実施スケジュールまで必ず落とし込む
「QA期間」と雑に2週間おいていた結果、2週間の時間の使い方に認識齟齬が生まれるかもしれない。結局やると言っていたはずのテスト作業がされないでバグが出てしまうかもしれない。不安だ。
少なくとも
・テスト項目作成完了期日
・項目テスト開始、終了
・バグ修正期間
・バグ修正、修正確認期間
・最終テスト期間
くらいの粒度で、QA期間に行うスケジュールを明確に日付を切ってチーム全体で管理した方が良い。
まとめ: 不安であれ。
エンジニアにとってのQAスキルの第一歩は不安であること。
不安でさえあれば気になることを確認したり、他の人を巻き込んだりすれば解決できることが多い。
その過程でQAのハードスキルは少しずつついてくる。
もちろんテスト手法について学ぶことも大事だけど、必要なQAの仕方や確認項目は開発プロダクト・開発チームの体制によって異なってくる。
環境の違いが生まれる中でも柔軟に品質担保をやり切るのに必要なことは、まず不安であることだと思っている。