シフトレフトはどこへ――テスト消化に囚われた私が気づいたこと - Cybozu Inside Out

こんにちは、kintone開発チームでQAエンジニアをしているなかです。この記事では、テスト消化に囚われた私が気づいたことについて紹介させていただきます。

シフトレフトを意識していたはずなのに…テスト消化が目的に

私が所属するチームはスクラム開発を採用しており、開発者もQAエンジニアも同じチームに所属しています。私はQAエンジニアとして、不具合や検討漏れを未然に防止できるようにとシフトレフトを意識し、できるだけ早い段階から品質に関わるよう心がけてきたつもりでした。

あるとき、開発者が一時的に増え、複数の機能開発が並行して進み、それに伴いテストの量もどんどん増えていきました。時間の確保が難しくなったため、テスト分析やテストケースの作成を最小限にし、探索的テスト中心で進めるようになりました。記録は残していましたが、チャーターは簡易的なもの、または頭の中で考えるだけで、十分な共有はできていませんでした。また、そのとき開発していたメインの機能が仮説検証を繰り返している段階だったこともあり、スピードや優先度の面から自動テストの実装を見送ったり、事前の打ち合わせがスキップされることも重なりました。

結果、早期のテスト活動は減り、「後からテストすること」が中心になっていきました。テストの時期も遅れがちだったため、フィードバックが遅くなることもありました。

「このやり方で本当に大丈夫なのかな…」と心の片隅で感じつつも、「考えるのはテストが一段落してから」と目の前のテストを優先し、本来大切にしていたはずのシフトレフトの意識が薄れ、「テストを消化すること」自体が目的になってしまっていました。

タスクが落ち着き、振り返ったときに、自分の視野がとても狭くなっていたことに気づきました。そんな私が、そのときの反省から気づいたことをご紹介したいと思います。

早めのテスト活動は改善しやすい空気づくりにつながる

前章での反省を踏まえ、以下のような改善を行いました。

実装開始時の開発者とデザイナーの打ち合わせに参加したい旨を伝え、参加するようにした（情報のキャッチ、認識合わせや懸念点の共有のため）
テスト分析を早い段階で実施し、すり合わせを開発者と行うようにした（不具合の未然防止やテスト範囲を明確にするため）
自動テストの設計のうち、優先度が高い観点については、機能実装の進行中に準備し、開発者に共有するようにした（私たちのチームではQAが自動テストの設計（観点出し）を担当し、実装は開発者が行う）

上記の一部について、忙しくなる前に実施していたこともありますが、そのときよりも積極的に行うようにしました。例えば、今までは非同期で進めていたやりとりも直接話すようにしたり、自動テストの設計はできるだけ実装中に実施するようにしました。

結果、「後からテスト」が中心だった頃と比べて、仕様の検討漏れや挙動に対する疑問、「このやり方で大丈夫かな」という感覚が減ったと感じています。今改めて考えると、仮説検証の段階であっても、動くものを待つのではなく、早い段階からできることを探り、積極的に関与していければよかったと感じています。

また、自動テストも実装期間中に対応できる機会が増えていきました。実装タイミングの調整が入る可能性があったとしても、重要な観点については早めに作成し、いつでも実装可能な状態にしておくことで、手動テストだけに依存しない状態につなげられると考えています。

テスト分析についても、簡単な箇条書きでも書き出して開発者に共有することで、頭の中が整理され、その後のテスト活動がしやすくなりました。以前のように探索的テスト中心で進めるやり方も時間短縮にはなると思います。ただ、事前の分析や準備が十分でない状態で探索的テストを採用すると、フィードバックが遅くなってしまい、後戻りが発生してしまうので、総工数の削減にはつながっていなかったかもしれないと今は感じています。

開発者とのコミュニケーションについても、テスト消化に囚われていたときは不具合の報告ばかりになりがちでしたが、早期の懸念点の共有やテスト観点のすり合わせを通して、テストについてより話しやすくなりました。開発者と一緒に考える機会があることで、品質をチーム全体のものとしてとらえやすくなり、前向きに行動できるようになったと思っています。今は、開発者の動作確認のタイミングにQAも参加したり、不具合の振り返り会の実施などの改善にも取り組んでいます。早めのテスト活動は、単なる早期発見だけでなく、テストについて話す機会が増え、改善しやすい空気づくりにもつながったと感じています。

忙しいときこそ、立ち止まる勇気を

忙しさに追われていると、どうしても目の前のタスクをこなすことに精一杯になってしまいがちです。私自身も、テスト消化に囚われてしまい、「不具合や検討漏れを未然に防ぐための動き」や「チームメンバーへの相談」といった、本来大切にすべきアクションを後回しにしてしまっていました。

しかし、冷静になって全体を俯瞰してみると、「本当に必要なのは、目の前の作業をこなすことだけではなく、早めにチームで相談し合い、問題を未然に防ぐことだった」と感じています。

前章でもお伝えしたように、チームメンバーとテストについて話す機会が増えたことで、仕様の検討漏れや不具合の未然防止など、具体的な改善につなげることができています。

例えば、振り返りや雑談の場で少し話すだけでも、状況が大きく変わることがあるかもしれません。明確な課題として伝えなくても、「最近ちょっと気になることがある」など、気軽にテストについて話す場があるだけでもよいと思います。

忙しいときほど、一度立ち止まって「今のやり方で本当に大丈夫か」「視野が狭くなっていないか」を振り返ることが大切だと感じています。

おわりに

今後同じような状況になったときの自分へメッセージも込めて、今回記事にしました。上記のような気づきを得たことで、テスト消化を第一に考えるのではなく、着手中のタスク全体を見て、何を優先するかを考えられるようになったと思っています。

まだまだ反省することばかりですが、一緒に考え、取り組んでくれるチームメンバーにはとても感謝しています。引き続きよりよい方法を探求していきたいと思います。

最後まで読んでいただきありがとうございました。