Starting & Sustaining Code-Based E2E Testing for Non-Coding QA Teams( #jasstniigata )

JaSST'26niigata( #jasstniigata ) での、「プログラミング未経験者を含むQA組織で、コードベースE2E自動テストをどう始め、どう続けるか」の発表資料です

Transcript

1. プログラミング未経験者を含むQA組織で、 コードベースE2E⾃動テストをどう始め、 どう続けるか Teppei YAMAGUCHI @ JaSST'26 Niigata © LayerX Inc.
2. ⾃⼰紹介 • • 株式会社LayerX 所属 / 個⼈事業主 ◦ テスター / コーチ / コンサルタント / プログラマー ◦ 現場でテストコードのレビューをし続けています 翻訳 ◦ ◦ • Teppei YAMAGUCHI 『ソフトウェアテストをカイゼンする50のアイデア』 『Fearless Change』 コミュニティワーク ◦ ◦ ◦ © LayerX Inc. Regional Scrum Gathering Tokyo 実⾏委員 SQiP 研究会 研究コース4「アジャイルと品質」アドバイザー テスト⾃動化研究会 お世話係 2
3. 「みんなで⾃動テストを書こう」では、 普及できませんでした
4. 今⽇お話しすること • • 「みんなで⾃動テストを書こう」をやめて、まず最初の⼀⼈が型を 作りきる理由 型ができてからの巻き込み⽅と、レビューを最初の⼀⼈に集約する進め⽅ © LayerX Inc. 4
5. コードベースE2E⾃動テスト普及の課題
6. 課題 【以前の現場】「1本でいいから書いてよ」と頼んだ • • • • テストフレームワークは⽤意した。あとは書くだけのつもりだった 声をかけたのは開発チームの3〜4名。「やります」と⾔ってもらえた 2ヶ⽉働きかけて、増えたテストは2〜3本だった 続かなかったし、広がりもしなかった © LayerX Inc. 6
7. 課題 【以前の現場】当時の私は「みんな忙しいんだろう」と思っていた • • • 書かない側に理由がある、と思っていた ◦ 実際、忙しかったのは本当だった 2ヶ⽉かけて私が変えようとしたのは、相⼿のやる気だった いま振り返ると、変えるべきだったのは、そこではなかった © LayerX Inc. 7
8. 課題 課題① テストを1本書くまでの判断が多い テストを1本書くまでに必要な判断の⼀部 • • • • • このテストは、どのファイルに置く？ テストケースの名前は？ メソッドの名前は？ この処理は共通化する？ しない？ 待ち⽅は？ ロケーターはどれを選ぶ？ アサーションはどの粒度で書く？ © LayerX Inc. 8
9. 課題 テストは書けても、判断の基準は⼀⼈で決めにくい • • プログラミングが分かる⼈ならテストを書けるのか？ ◦ テストは書ける。ただし、前に例⽰した判断には⼀つ⼀つ⾃分で答えを 出すことになる 「みんなが使うテストの判断を、⾃分が決めていいのか」が分からない © LayerX Inc. 9
10. 課題 課題② テストケース固有の知識がない テストケースは読みやすく、とメンバーに伝えても、返ってくる問いは… • • • テストケースとして、どうなっていたらいいのか？ そもそもファイルのはじめから何を書いたら良いのか？ テストケース内でのログインはどう書いたら良いのか？ © LayerX Inc. 10
11. 課題 AIでテストを書けるだけでは、数年続く⾃動テストにはならない • • • 数年使い続けると、パッと作ったテストは、直す箇所が分からなくなる AIがテストを書けても、テストのための判断基準がないことは変わらない むしろ、書ける量が増えるぶん、直せなくなるのが早い © LayerX Inc. 11
12. 普及させるためには⼯夫が必要
13. アプローチ 全体の流れ 今回は私 ① 最初の⼀⼈が 型を作りきる 型ができたら ② 巻き込む∕レビューを 最初の⼀⼈に集約する ③ 最初の⼀⼈による レビューをやめる レビュー指摘がなくなったら ① 判断回数を減らすガイドやコーディングルール、サンプルコードで構成する 型を最初の⼀⼈が作りきる ② 巻き込みつつ、⼈により判断がぶれないように最初の⼀⼈にレビューを 集約する ③ レビュー指摘がなくなったら、最初の⼀⼈によるレビューをやめる © LayerX Inc. 13
14. アプローチ 最初の⼀⼈が型を作りきる、とは何をするのか 次に書く⼈が、コピペ&モディファイでテストケースを書けるようにする • • • ⾃動テスト作成ガイドとコーディングルールを整備する 主要なフローを含むテストケースを、サンプルコードとして⼀通り、 最初の⼀⼈が作りきる 完璧を⽬指さず、書く⼈が⼿を動かし始められるところまで作る © LayerX Inc. 14
15. アプローチ 例：「保存」ボタンをクリックしたい • 「保存」ボタン要素を、どの種類のロケーターで定義しますか？ A. B. C. D. E. • data-testid 表⽰されている「保存」の⽂字 role とアクセシブルネーム CSS セレクタ（.btn-primary） XPath（フォーム内の3番⽬のボタン） どれでも動く ◦ ただし、UI の変更に強い種類と、どの要素でも使える種類は異なる ◦ 要素に応じて選ぶ © LayerX Inc. 15
16. アプローチ ガイドやコーディングルールとして決めること（1） 要素は、極⼒、上位の種類のロケーターで定義する A. B. C. D. E. テスト⽤に割り振ったID（data-testid、getByTestId） 表⽰されているテキスト（getByText） role とアクセシブルネーム（getByRole） class / id / name、タグ名との組み合わせ（.btn-primary など） XPath による何番⽬や列指定などの構造情報 ※ Playwright 公式は role を先に勧める。 A を最優先にしたのは、⾃分たちで管理でき、⽂⾔やスタイルの変更では壊れないから © LayerX Inc. 16
17. アプローチ 例：申請プロダクトの requests/new 画⾯の要素定義をしたい • この画⾯の要素定義、どこに置いて何と呼びますか？ ◦ ◦ ◦ ◦ • A pages/requestNew.ts に RequestNewPage クラス B pages/workflow/requests/new.ts に WorkflowRequestsNew クラス C pages/申請/新規作成.ts に CreateRequest クラス D specs/ のテストケースと同じファイルの中に書く どれでも動く ◦ ただし、次に書く⼈とAIが、同じ答えにたどり着けるか © LayerX Inc. 17
18. アプローチ ガイドやコーディングルールとして決めること（2） 可能な限り、名前は「決める」のではなく「決まる」ようにする • クラス名とファイル名は、プロダクト名かドメイン名と URL の階層で決まる ◦ ◦ ◦ URL {申請プロダクトドメイン}/requests/new ファイル pages/workflow/requests/new.ts クラス WorkflowRequestsNew ※「workflow」は「申請」プロダクトを指す • 要素名は、⾒た⽬にあわせて名付ける。input タグでも、ボタンなら 〜Button © LayerX Inc. 18
19. アプローチ ガイドやコーディングルールとして決めること（3） ファイルの保存場所や依存関係も、先に決めておく • ディレクトリ構成 root/ pages/ // 画⾯の要素定義と、1画⾯内の操作（Page Object Model） shared_components/ // サイドバーなど、プロダクトごとに共通の部品 steps/ // ページをまたぐ⼀連の処理 specs/ // E2Eテストケース （ほか testdata/ utils/ download/） • • • steps と specs は、直下がプロダクト名（doc-issue / id / payer …） pages は、直下がプロダクト名かドメイン名。その下は URL の階層 参照の向きを固定する specs → steps → pages / specs → pages © LayerX Inc. 19
20. アプローチ ルールを全部守ると、こうなる test("パスワードが未入力の場合ログインに失敗すること ", async ({ page }) => { // 期待値：パスワードが未入力だとログインできない const idIndex = new IdIndex(page); const idAuthSignIn = new IdAuthSignIn(page); await idAuthSignIn.load(); // 固定IDで失敗が続くとロック時のメッセージになるため、ランダムな IDで試みる await idAuthSignIn.usernamePlaceholder.fill(`hoge+${utilsGenerateTimestampedUniqueId()}@XXXXXX`); await idAuthSignIn.passwordPlaceholder.fill(""); await idAuthSignIn.loginButton.click(); await expect(idAuthSignIn.alertToast).toContainText("ユーザー名とパスワードを入力して下さい "); await expect(idIndex.globalNavigationBar.productDropdown).toBeHidden(); }); IdAuthSignIn：プロダクト名（id）と URL（/auth/sign_in） の階層から決まる loginButton：ボタンだから 〜Button expect ×2：アサーションは spec に残す © LayerX Inc. 20
21. アプローチ 最初の⼀⼈が作りきるテストケースに含めていること ファイルの書きはじめや、基本的な操作が書かれたファイルを⽤意する 例） • • • • • ファイル内で実装しているテストケースのテスト設計書へのリンク テストアカウントの定義 テストケース内でのログイン⽅法 テストケース内での主要フローの実装‧利⽤ テストケース内でのテストにおける期待値の表現 © LayerX Inc. 21
22. アプローチ サンプルコードの上部 import { IdAuthSignIn } from "@pages/id/auth/sign_in"; import { IdIndex } from "@pages/id/index"; import { test, expect } from "@playwright/test"; import { utilsGenerateTimestampedUniqueId } from "@utils/generateTimestampedUniqueId"; // テストケース表 : 「[ID] テストケース表」の「【 ID】認証」シート // パスワードが未入力の場合ログインに失敗すること // https://docs.google.com/spreadsheets/d/XXX/edit?gid=YYY#gid=ZZZ&range=xx:xx test("パスワードが未入力の場合ログインに失敗すること ", async ({ page }) => { 【以下略】 © LayerX Inc. 22
23. 型ができてから、 QA組織のメンバーをどう巻き込んだか
24. 巻き込み ペアプロは、セットアップから⼀緒にやる • • • ガイドを書いても、実⾏環境のセットアップで⽌まる⼈がいる テストケース1本を⼀緒に書いて、ガイドの使い⽅を⾒せる 分かりにくかったガイドは、その場で直す © LayerX Inc. 24
25. 巻き込み やってみせる会で、考えていることを実況する • • • • 「なぜこの順番で書くか」を、声に出しながら書く 「こうしておくと後が楽になる」を、その場で共有する 同じところでハマっている⼈を、まとめて助けられる エディタの使い⽅なども共有できる © LayerX Inc. 25
26. 巻き込み テストケース群の品質と⼀貫性を維持する • • • テストケースが少ないうちは、書き⽅のばらつきが発⽣しやすい 書き⽅がばらつくと、次にテストを書く⼈の判断が増える ◦ そのため、レビューは最初の⼀⼈に集約し、ばらつきを減らすようにする レビュアーの負荷は上がる ◦ この期間は引き受ける、と最初の⼀⼈が先に決めておく © LayerX Inc. 26
27. 巻き込み レビュー指摘を、AI向けのガードレールに書く • • 当初狙ってはいなかったが、AIに問題を繰り返させないために、 レビュー指摘をAI向けのガードレールに書いている ガードレールとして書いていること（⼀部） ◦ ◦ ◦ ◦ ◦ • 既存のテストと同じ形で書き、新しい書き⽅を持ち込まない ロケーターは UI 上の意味で狭く定義する アサーションは spec に残す。意味のないアサーションを作らない タイムアウト、ループ、リトライを雑に書かない シナリオは、共通化（DRY）より業務の読みやすさを優先する これらはレビューをしながら増やしている © LayerX Inc. 27
28. 巻き込み レビュー指摘がなくなったら、最初の⼀⼈によるレビューをやめる • 同じ指摘が2〜3回出たら、ガイドやガードレールに書く ◦ • 最初の⼀⼈によるレビューをやめる流れ 1. 2. 3. • 書いた分、次のレビューで⾔うことは減る 直接、最初の⼀⼈がレビューする 慣れてきたら、まず書く⼈同⼠でレビューし、最初の⼀⼈は最後に⾒る 2. で書いた⼈同⼠でも、最初の⼀⼈によるレビューでも、レビュー指摘がなくなり 安定したら、最初の⼀⼈によるレビューをやめる 書く⼈同⼠のレビューは、レビューの練習でもある ◦ 指摘された⼈と指摘した⼈の両⽅が学ぶ © LayerX Inc. 28
29. 巻き込み 状況に応じて、最初の⼀⼈によるレビューを再開する • • ⾃動テスト作成経験のある⼈から順に、半年ほどで最初の⼀⼈による 直接的なレビューをやめた ところが最近、AIで書く量が増え、ガードレールが追いつかない場⾯が 出てきたため、最初の⼀⼈によるレビューを再開している © LayerX Inc. 29
30. 巻き込み （おまけ）巻き込みや普及拡⼤に関しては戦略的な視点もある • • • ここで紹介したものは、⾃動テストに特化した施策レベルのもの より⼤きな範囲での巻き込みや普及を考えると戦略的なものも必要になる 参考：「技術導⼊の障壁と解決のヒント」 https://speakerdeck.com/teyamagu/ideas-for-introducing-new-methods © LayerX Inc. 30
31. 巻き込んだ結果、何が変わったか
32. 効能 ⾃動テストが、みんなのものになった 型を作りきってから巻き込んで得られた効能 • • • 効能① 書きはじめるまでの迷いが減った 効能② プログラミング未経験のメンバーも、サンプルコードとガイドを ⾒ながら書けるようになった 効能③ レビュー指摘が、⼈向けのガイドやAI向けのガードレールとして 残るようになった © LayerX Inc. 32
33. 効能 とはいえ、まだ途中です • • • 書いた⼈は増えた。ただし、⽉ごとに書く⼈には波がある ⾃動テストでカバーしたい範囲は、プロダクトの成⻑や 増加とともに広がり続ける レビューを完全になくせる段階には、まだ⾄っていない © LayerX Inc. 33
34. まとめ
35. まとめ どう始め、どう続けるか • • 始め⽅ ◦ 「みんなで⾃動テストを書こう」をやめ、まず最初の⼀⼈が型を作りきる ◦ 型は、判断回数を減らすガイドやコーディングルール、サンプルコード 続け⽅ ◦ 巻き込むのは型ができてから。レビューは最初の⼀⼈に集約する ◦ レビュー指摘がなくなったら、最初の⼀⼈によるレビューをやめる ◦ ただし、状況に応じて再開することもある © LayerX Inc. 35
36. まとめ 明⽇からできる第⼀歩 • • • ⾃分がやっているテストの書き⽅を、1枚のドキュメントとして作成する 他者にとって参考になるテストケースを、最初の⼀⼈として1本書く 誰かとペアで、テストケースを1本書く © LayerX Inc. 36