カイゼンと僕とE2Eテスト

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

自己紹介 02 ( 大津和槻) Twitter: cocoeyes02 株式会社ウィルゲート（新卒2 年目）バックエンドエンジニア
QA 領域にも興味がある（QA エンジニア）趣味：ジャズ鑑賞、カホン、ゲーム

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

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

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

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

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

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

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

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

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

対応：主要機能の Never Must Want を定めたまず、事業部と開発で整理し、主要機能について以下をスプレットシートに記入しましたあってはならない（Never ）できなければならない（Must
）あったら良い（Want ）テストコードでは「Never が起きていないこと、 Must ができることを担保する」という目的を定めた

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

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

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

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

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

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

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

問題: 「このプロダクト、ユニットテスト書けないわけではないよ？」「えっ」 02 や設計者以外のチームメンバーが、設計に対するユニットテスト導入のアプローチを勘違いしていた大規模なリファクタリングをしなくても、ユニットテストが導入できる「よし！カイz
「あ、02 くん来月から別のチームと兼任になるので稼働半分ぐらい減るからね」「えっ」

to be continued...

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

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

指針: 僕がいなくてもテストコードを書く作業ができる状態にしたいテストコード指針を書きたい UI(E2E) テスト、結合(feature, API) テスト、ユニットテストで得意領域と苦手領域は違うはず Never
Must を見て、どの機能をどのテストで担保するのかだけは書いておく

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

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

Thank You For Listening! Twitter: cocoeyes02 Github: cocoeyes02

カイゼンと僕とE2Eテスト

カイゼンと僕とE2Eテスト

02

More Decks by 02

Other Decks in Programming

Featured

Transcript