カイゼンと僕とE2Eテスト

Transcript

1. カイゼンと僕と E2E テスト 02 ( 大津 和槻) システムテスト自動化カンファレンス 2019

2. 自己紹介 02 ( 大津 和槻) Twitter: cocoeyes02 株式会社ウィルゲート（新卒2 年目） バックエンドエンジニア

   QA 領域にも興味がある（QA エンジニア） 趣味：ジャズ鑑賞、カホン、ゲーム

3. 今日は私が業務で触っている プロダクトの改善について お話をします

4. テストコード( 主にE2E テスト) メインのお話です

5. 触っているプロダクト 去年リリースされた BtoB 向けの案件管理システム リリース当初から 「業務が止まってしまうような障害が多い」 という大きな問題を抱えていた 当時のマネージャーからも 「なかなかシステム品質が悪い」の一言

6. 触っているプロダクト 去年リリースされた BtoB 向けの案件管理システム リリース当初から 「業務が止まってしまうような障害が多い」 という大きな問題を抱えていた 当時のマネージャーからも 「なかなかシステム品質が悪い」の一言 「よし、カイゼンだ！」

7. 問題：バグが多い バグの発見は手動のシステムテスト頼り 漠然と「システム品質が悪い」と思う状況だった ので、どの機能に問題があるのかわからない

8. 問題：バグが多い バグの発見は手動のシステムテスト頼り 漠然と「システム品質が悪い」と思う状況だった ので、どの機能に問題があるのかわからない 「よし！カイゼンだ！」

9. 対応：E2E テストを導入した 素早く確実にバグを見つけたい、品質を可視化したい → テストコードの導入を検討 しかし、当時ユニットテストを書くにはリファクタリ ングが必要だとされていた 内部処理が複雑になっている リファクタリングの心理的障壁が高い ユニットテストと比べると

   内部的なコードをあまり気にせずテストができる E2E テスト(puppeteer) を用意することにした

10. 問題：E2E テスト作る時間が あんまりないよ！ 時間がないのはしょうがないとして、そもそも テストコードを作る優先順位がきまってなかった 当時はそもそもテストを使って何を担保したいのか、 テストの目的が定まっていない状況だった

11. 問題：E2E テスト作る時間が あんまりないよ！ 時間がないのはしょうがないとして、そもそも テストコードを作る優先順位がきまってなかった 当時はそもそもテストを使って何を担保したいのか、 テストの目的が定まっていない状況だった 「よし！カイゼンだ！」

12. 対応：主要機能の Never Must Want を定めた まず、事業部と開発で整理し、主要機能について以下 をスプレットシートに記入しました あってはならない（Never ） できなければならない（Must

    ） あったら良い（Want ） テストコードでは「Never が起きていないこと、 Must ができることを担保する」という目的を定めた

13. 問題：E2E テストが全然運用 に乗っていなかった 運用し始めたあと、デザイン変更などが理由で 半分ぐらいの E2E テストが壊れていた

14. 問題：E2E テストが全然運用 に乗っていなかった 運用し始めたあと、デザイン変更などが理由で 半分ぐらいの E2E テストが壊れていた 「よし！カイゼンだ！」

15. 対応：修正 + 結果を見やすく 泥臭く修正した！ ただ修正するだけじゃなくて、以下の改良も加えた テスト失敗したときには画面のスクリーンショッ トを取って保存する そもそも何を確認したいE2E テストなのか、 テストケース名を整理して結果に表示する

16. 問題：バッチの挙動は E2E テストで担保できない！ E2E テストで担保できている範囲も広くなったが、 流石にここはE2E テストでは担保できない

17. 問題：バッチの挙動は E2E テストで担保できない！ E2E テストで担保できている範囲も広くなったが、 流石にここはE2E テストでは担保できない 「よし！カイゼンだ！」

18. 対応：リファクタリングをし て、ユニットテストを導入 バッチ処理をリファクタリングし、重要ロジック部分 をユニットテストで担保した 初めてユニットテストを導入するので、若干リファク タリングはした 改めて、E2E テストで担保すべき場所を見直すことに

19. 問題: 「このプロダクト、 ユニットテスト書けないわけ ではないよ？」「えっ」 02 や設計者以外のチームメンバーが、設計に対する ユニットテスト導入のアプローチを勘違いしていた 大規模なリファクタリングをしなくても、 ユニットテストが導入できる

20. 問題: 「このプロダクト、 ユニットテスト書けないわけ ではないよ？」「えっ」 02 や設計者以外のチームメンバーが、設計に対する ユニットテスト導入のアプローチを勘違いしていた 大規模なリファクタリングをしなくても、 ユニットテストが導入できる 「よし！カイz

    「あ、02 くん来月から別のチーム と兼任になるので稼働半分ぐらい減るからね」 「えっ」

21. to be continued...

22. 今後アプローチしたいこと

23. 指針: 僕がいなくてもテストコード を書く作業ができる状態にしたい ユニットテストにかかる工数を見積もりたい 優先度の高い機能から見積もりをし、チケット化 する E2E テストの範囲に含まれているところから手をつ けると良いかも

24. 指針: 僕がいなくてもテストコード を書く作業ができる状態にしたい テストコード指針を書きたい UI(E2E) テスト、結合(feature, API) テスト、ユニッ トテストで得意領域と苦手領域は違うはず Never

    Must を見て、どの機能をどのテストで担保 するのかだけは書いておく

25. 指針: 僕がいなくてもテストコード を書く作業ができる状態にしたい 各テストの書き方マニュアルを用意する 簡単なハンズオンリポジトリみたいなのも用意し ても良いかも？

26. カイゼンに終わりはない オレたちのカイゼンは これからだ！！

27. Thank You For Listening! Twitter: cocoeyes02 Github: cocoeyes02