こんにちは、テックタッチで QA PM (Quality Assurance Project Manager)をしている shutty です。先日はテストエンジニア向けの合宿型ワークショップ WACATE2023 冬に初めて参加してきました。実行委員をはじめとして参加者全員の熱量を全身に浴びてきました。 弊社では、効果的なチーム運営を目指すために Team Topologies を参考にしています。 スクラムガイドでは、開発業務に必要なメンバーを『開発者』と表現しており、もちろん QA も『開発者』ですが、 本記事で扱う 『開発者』は、フロントエンドやバックエンドのエンジニアを指します。 プロダクトチームは Four Keys の Elite を目指し、リードタイムの短縮に取り組んでいます。その施策の一つとして、E2E テストの自動化を部分的に適用していく施策を進めています。しかし、まだ安定性や既存のテストケースとの整合性の問題から、全面的な運用には至っていません。 開発者はテストカバレッジを上げられるように単体テストを作成します。 一方で、QA はユーザーストーリーと仕様書を基に E2E テストを行ってきた結果、重複するテストが生まれ、E2E のテストケースが増大しました。これにより手動でのリグレッションテストが膨れ上がり、工数が大幅に増えてしまいました。 現状では、チーム全体で修正範囲を共有し、都度テストスコープを調整・確認する方法をとっています。 テックタッチではスクラム開発を採用し、事業の成長に伴って変化するチーム体制に対応しながら、品質保証プロセスを広範囲に適応する必要があります。 現在、テストケースはドメインごとにスプレッドシートで管理されており、合計で約 60 のシートがあります。 導入 TIY とは QA として何をしたか 期待する効果 テックタッチでは、テストマネジメントを強化し効率化するために新しいテストマネジメントツールの「Qase」を導入しました。 このツールにはいくつかのメリットがあり、それによってテストプロセスが大きく改善されます。 Qase 導入のメリット ただ、Qase ではバージョン管理ができないため工夫する必要があります。 今後の活用 最後に、テストプロセスが自走するチーム体制を目指して取り組んでいることを振り返ります。 テックタッチでは、テストプロセスが自走するチーム体制を築くために、更なる成長を支える人材を募集しています。とくに SET（Software Engineer in Test）という役割に興味をお持ちの方は、ぜひご応募ください！一緒に品質を追求し、テストプロセスの改善に取り組みましょう。 興味を持っていただけたら、ぜひ弊社の採用ページをご覧ください！
はじめに
この記事では最近テックタッチの開発チームで行なっているテストプロセスの改善について紹介します。前提情報
プロダクトチームの体制
Four Keys の Elite を目指して
品質保証の課題
1. テストの重複
2. 刻々と変化するチーム体制
現状、私たちはインプロセス QA を実践しており、JSTQB の定義にあるような『テスト計画からテスト完了』までのテストプロセスをカバーしています。テックタッチのスクラム開発はインクリメンタルな開発アプローチであり、テストプロセスのうち『テスト分析・テスト設計・テスト実装・テスト実行』に多くのリソースを割いています。
テックタッチの組織設計上、QA は Team Topologies でいうイネーブリング・チームです。
QA チームの立ち上げから現在までで、スクラムチームのインプロセス QA としてテストプロセスを最適化することに集中してきましたが、事業とチームが成長してきた今こそ、QM ファンネルにおける QA コーチとしてバリューを発揮できるようになっていきたい考えです。
プロダクトチームにおける QA の役割を QM ファンネルを参考にして再設計し、開発チームの拡大に備えた柔軟な組織設計を目指すことで、開発のボトルネックを回避したいと考えています。3. 属人化したテストケース管理
スプレッドシートはドメインごとにファイル横断しているため、テストケースの検索性が低い状態です。そのため、テストケース作成者以外がテストケースを追跡しようとすると、時間がかかります。この属人化したテスト実装のプロセスを改善する必要があります。
また、このファイル横断した仕組みではテスト実行時のモニタリングが難しく、テスト効率の低下に気づきづらい状態です。 さらに、テストケースは使い捨てになりやすい傾向があります。改善策：テストプロセスの変更とテストケース管理ツールの導入
1. テストプロセスの改善〜Test It Yourself〜
「刻々と変化するチーム体制」にイネーブリング・チームとして適応するために、段階的に QA コーチへの進化を目指していきます。
我々QA チームは、この活動を『Test It Yourself』（以降、TIY として記載）と名付けました。これにより、開発プロセスに新しいテストのアプローチを取り入れ、チーム全体で品質を作り込む文化を育てようとしています。
主なポイントは、テストプロセス（テスト計画、テスト分析、テスト設計、テスト実装、テスト実行）を開発者が主体的に実施することです。 これまでインプロセス QA としてテストプロセスを担当していた QA は、開発者と並走しながらテストプロセスをレビューします。
TIY を導入することで、QA の役割は今よりもイネーブリングにスクラムチームをサポートする方向にシフトしていきます。
現在、TIY をスクラムチームに適応できるよう推進中です。
例えば、開発者が TIY に慣れるよう、「隣のチームも手順に従ってテスト実行できるように」をコンセプトにドキュメントを作ったり、「なぜこの変更が必要なのか」やどんな良いことがあるのかを丁寧に説明しています。
また、誰もが簡単にテストができるように、テストプロセスを改善することも大切です。開発者の視点でテストプロセスの改善案などが出たり、よりテスト技法の理解を深めようとするアプローチがあります。このようなアプローチに応えるため、QA が持っている暗黙的なナレッジを言語化することで、再現性のあるテストプロセスに成長する予感がしています。
TIY による期待効果は 2 つあります。
1 つめは、開発者が最終的なプロダクトの品質を作り込むため、「いつどこで、どうやってテストするか？」を考えながら実装することで、新たな気づきを得ることができることです。
2 つめは、どのテストレベルでテストを自動化するか明確にできることです。例えば、単体テストに近い領域でテストが自動化ができた場合、E2E テストを自動化しようとしていたテストを削減させることができ、結果としてもっと効率の良い開発ができるようになります。2. テストマネジメントツールの導入
このツールの利用によって、E2E テストを効率的に実施すべき領域を特定しやすくなります。これは、開発者と QA のチーム両方にとって大きな利点となるでしょう。 どのテストケースが存在するかが明確になることで、より迅速で効果的なテストとフィードバックが可能となり、これまで別々で管理していたため重複したテストケースを抑制し、結果としてプロダクトの品質向上に貢献することを期待しています。おわりに
