エンジニアと一緒にテストコードの設計と実装を改善した話

QA engineer at a Startup vol.31 登壇資料です。
https://qaengineeratastartup.connpass.com/event/393702/

Transcript

1. エンジニアと⼀緒に テストコードの設計と実装を改善した話 株式会社スタディスト 髙津基暢 2026/06/15
2. 2 ⾃⼰紹介 2 株式会社スタディスト QAエンジニア 経歴 - 前職は株式会社asken - Androidアプリエンジニアとして入社 - 途中でQAエンジニアに転身 - 2025年9月、株式会社スタディストへ Join 趣味 - ボードゲーム - マンガ - ラジオ 髙津 基暢 @decoymaker
4. 4 まずはチームを知ることから Join 直後、何から始めたか 4 元々QAがいたチームへ後任として参加 チームメンバー全員と 1on1 を設定した
5. 5 「現状の開発プロセスで、 課題や改善したいことはありますか？」 聞いた問い 5
6. 6 テストコードをどこまで書けばよいか わからない テストコードをどう書けばよいか わからない テストコードを書くのが大変 テストコード関連の悩みが出てきた 出てきた声 6
7. 7 元エンジニアだからこそ、わかることがあった なぜQAである⾃分が動いたか 7 テストコードを書くのが好きだったし助けられたことがあった エンジニアにQAの基礎知識が加わると、質も速度も改善できる 自分が持っている知識をエンジニアに渡せる と判断した
8. 8 先に聞いていたから、気軽に誘えた 「試しにやってみませんか」という温度感 「まずはチーム内で小さく、数回お試しでやってみませんか？」 小規模で始める　 ：他チームへの展開は後回し。まずこのチームだけ やめる権利を渡す ：数回やってみて合わなければやめればいい → エンジニアにとって「断りやすく・やめやすい」提案にした 8
9. 9 テストコード改善委員会を始めた 9 チーム内で定期イベントとして立ち上げ 「知識・経験・悩みを共有して改善する」 最初に「悩み」と「やってみたいこと」を列挙し、 活動内容を決めた 週30分・オンライン・ FigJamでわいわい
10. 10 ノウハウを「体験」に変える やったこと① 改善活動の共有とモブワーク 10 リードエンジニアが試していたテストコード実装の改善手法を共有 共有だけで終わらせず メンバーがドライバーとして実際にテストコードを書く モブワークも実施 「やってみた」体験が定着を早める
11. 11 共通言語をチームで作る やったこと② "よいテストコード"を議論した 11 「よいテストコードとは何か？」をみんなで議論 結果を整理してドキュメント化 チームの共通言語に → AIレビューにも活用
12. 12 概念を知るだけでなく、実際に問題を解くワーク形式 で実施 ASTERのソフトウェアテスト技法入門資料などを活用 • 同値分割・境界値分析 • 状態遷移テスト • デシジョンテーブルテスト • ペアワイズテスト 座学で終わらせない・「チームみんなが知っている状態」へ やったこと③ テスト技法を⼀緒に学んだ 12
13. 13 テスト技法の学びが設計に波及した 設計への接続：状態遷移図‧表の活⽤ 13 テスト技法入門で学んだ状態遷移図・表が設計に活用された 実装前にユニットテストの設計レビューを提案してもらった 「テストを後から書く」から「テストを先に考える」へ
14. 14 "一緒に"の実態 QAが⼀⽅的に進めたのではない 14 内容はエンジニアと議論して決めた テスト技法ワークショップもメンバーの声を反映 QAが「正解を持ってきて教える」のではなく一緒に考えて決める
15. 15 エンジニアの声（before → after） 15 before テストコードをどう書いたらいいかわからない既存 コードを見様見真似で書いている 境界値を意識してテストケースを設計することが当 たり前になった ユニットテストに苦手意識がなくなり、 TDDが当たり 前になった after 若手エンジニア
16. 16 エンジニアの声（before → after） 16 before テストコードを書く基準が不明確だった テストコードの課題感をチームで共有できて、ネク ストアクションを整理できた テストコードを書く基準が明確になった 状態遷移図・表は設計時に活用できた after エンジニア
17. 17 エンジニアの声（before → after） 17 before 良いテストコードについて整理できたため 負担感が軽減できた 経験上やっていたことが間違っていなかったことを 確認できて安心した 実際にテストコードのリファクタを進めることができ た テストコードをレビューするのも面倒だった 体系的にテストについて学んだことがなかった after リードエンジニア
18. 18 失敗も正直に うまくいかなかったこと 18 • メンバーが忙しくてSKIPが発生した ◦ 定期化していても忙しい時期は欠席や中断が出る ◦ 無理に詰め込まず、再開しやすい雰囲気を大事にした • ペアワイズ法はまだ活用できていない ◦ 全部が定着するわけではない ◦ まず1〜2つ根付かせることを優先
19. 19 QAが「待つ存在」から「声をかけられる存在」へ エンジニアから声がかかるようになった 19 テストコードを含むPRでテストケースのレビューを依頼される 実装前に「テスト設計のレビューをお願いしたい」と相談される 「設計の壁打ち相手お願いしてもいいですか？」と依頼される…
20. 20 まとめ 20 先に聞く　　　 … 1on1で「困っていること」を把握 気軽に誘う　　 … 「試しにやってみませんか」で始める 定期の場を作る … 継続することで関係が育つ 声をかけるための型
21. 21 まとめ 21 遠慮せずにエンジニアを頼ろう エンジニアに頼られる QAになろう 配慮はするが、遠慮はしない
22. https://studist.jp/