Tweet
Tweet

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

to be continued...

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

Thank You For Listening! Twitter: cocoeyes02 Github: cocoeyes02