Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
アペルザの品質を支えるE2Eグレートジャーニー
Search
SASAKI Kunihiko
November 19, 2020
Programming
0
660
アペルザの品質を支えるE2Eグレートジャーニー
SASAKI Kunihiko
November 19, 2020
Tweet
Share
Other Decks in Programming
See All in Programming
イベント駆動で成長して委員会
happymana
1
320
色々なIaCツールを実際に触って比較してみる
iriikeita
0
330
GitHub Actionsのキャッシュと手を挙げることの大切さとそれに必要なこと
satoshi256kbyte
5
430
よくできたテンプレート言語として TypeScript + JSX を利用する試み / Using TypeScript + JSX outside of Web Frontend #TSKaigiKansai
izumin5210
6
1.7k
Jakarta EE meets AI
ivargrimstad
0
610
LLM生成文章の精度評価自動化とプロンプトチューニングの効率化について
layerx
PRO
2
190
ペアーズにおけるAmazon Bedrockを⽤いた障害対応⽀援 ⽣成AIツールの導⼊事例 @ 20241115配信AWSウェビナー登壇
fukubaka0825
6
1.9k
Macとオーディオ再生 2024/11/02
yusukeito
0
370
Remix on Hono on Cloudflare Workers
yusukebe
1
290
macOS でできる リアルタイム動画像処理
biacco42
9
2.4k
Snowflake x dbtで作るセキュアでアジャイルなデータ基盤
tsoshiro
2
520
Less waste, more joy, and a lot more green: How Quarkus makes Java better
hollycummins
0
100
Featured
See All Featured
How To Stay Up To Date on Web Technology
chriscoyier
788
250k
Optimizing for Happiness
mojombo
376
70k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
31
2.7k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
93
16k
Happy Clients
brianwarren
98
6.7k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
1.9k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
How GitHub (no longer) Works
holman
310
140k
Making the Leap to Tech Lead
cromwellryan
133
8.9k
Side Projects
sachag
452
42k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
329
21k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
109
49k
Transcript
Ξϖϧβͷ࣭Λࢧ͑Δ&&ͷ άϨʔτδϟʔχʔ ٕज़෦ 2"ΤϯδχΞ ࠤʑ NBCMίϛϡχςΟΣϏφʔ
͍͜ͱԣʹ͍·͢ ͍͜ͱ+BWBΤϯδχΞ ࠷ۙςετࣗಈԽΤϯδχΞ ΞϖϧβͰͷܦྺ ݄ʙ +BWBΤϯδχΞ ݄ʙ 2"νʔϜϦʔμʔ ࣗݾհ
None
https://www.aperza.com/corp/recruit/ こんな サービス
日本語を話すメンバーと英語を話すメンバーがいます。 この1年で人数が12人から28人と倍になりました。 ։ൃνʔϜͷհ October, 2019| 12Members November, 2020| 28Members
ΞδΣϯμ アペルザでは、2017年から「まずは小さく始めてみよう」の指針で E2Eをコツコツ運用してきました。 今日は、その間に学んだことなどを紹介したいと思います。 • なぜE2Eをはじめたのか • どうやって運用しているのか • 今までやってきたこと
• これからやりたいこと
ͳͥ&&Λ͡Ίͨͷ͔
&&ΛΒͳ͍ཧ༝͍ͬͺ͍͋Δ • アプリの挙動が変わるたびにテストコードをメンテするの大変だし。 • 失敗するたびに確認するの大変だし。 • 失敗を検知してもアプリがすぐ直らないこともあるし。 • 失敗が続いたまま放置すると形骸化するし。 •
テストコード書くのも工数いるし。 • リリース前にテストすれば大丈夫じゃん。
ͳͥ&&Λ͡Ίͨͷ͔ リグレッションテストの必要性を感じる不具合が、 何度か発生したのがきっかけです。 • 本番環境でリンク先や画像の取得元がテスト環境になっていた。 ◦ 社内からはテスト環境につながるので発見が遅れてしまった。 • ページのレンダリングに失敗するページがあった。 ◦
データの組合せによってエラーが発生していて組合せが多い。 マニュアルテストで見逃すなら機械に頼んでしまおう。
ͳͥ&&Λ͡Ίͨͷ͔ QAチームリーダーになった時に、過去1年分のバグチケットを見直しました。 見直した結果、「要件・仕様・設計」に関する不具合よりも、 「UI/UXや実装ミス」に関する不具合が多いことがわかりました。 E2Eで見つかりやすい不具合が多いので、カバレッジを増やすことに効果があ ると考えています。
Ͳ͏ͬͯ&&Λӡ༻͍ͯ͠Δͷ͔
2"ϝϯόʔͷհ アペルザではオフショアを利用していて総勢6人です。 • 社内QAが2人 ◦ 1人はスクラムマスター ◦ 1人は自動化エンジニア(僕です) • オフショアQAが4人
2"ϝϯόʔͷ࡞ۀ୲ オフショアQA:マニュアルテスト 社内QA:SET(私) もう1人の社内QA:スクラムマスター、バ グチケット管理、リリース管理 自動化エンジニアとスクラムマスター の二人でアペルザの品質向上を目指し て活動しています。
&&Ͱಈ͔͍ͯ͠Δͷ アペルザではリグレッションテストを自動化しています。 •E2Eを運用を続けていくには、メンテナンスコストを小さくするのが良い と考えていて、仕様・実装の変更が少ないリグレッションテストが向いて る。 ◦ 主に正常系を動かしています。 ◦ メンテナンスは必ず発生するので作り込みすぎないように心がけています。 •リリース直前に仕様が変わることもあるため、新機能は柔軟に対応できる
マニュアルテストが向いている。 ◦ 境界値テストや、全てのフローを通る操作などを実施します。
アペルザでは、障害レベルを設定 していて、障害レベルに合わせて 頻度を変えてスケジュール実行し ています。 レベルSは毎日実行していて、 レベルA、B、Cは週1で実行して います。 また、ログイン・ログアウトなど データの登録・更新を行わないテ ストについては、本番環境に対し
ても実行しています。 &&Λಈ͔͢λΠϛϯάͳͲ 障害 レベル S • クリティカルパスの機能において、ユーザーがアク ションを完了することができず、代替手段もない場 合。 • 個人情報・機密事項漏洩の可能性がある A • Sと同じ内容のトラブルだが、代替手段がある場合。 • Sより重要度は低いが、ユーザーがアクションを完了 することができず、代替手段もない場合。 • ごく限定的なユーザにレベルSのトラブルが発生した 場合 B • アクションを完了することができないが、代替手段 がある場合 C • 上記以外
&&ͰϝʔϧΛૢ࡞͢Δ •E2Eを実装するには、会員登録時やパスワードリセット時に送信されるメ ールの本文にあるURLをクリックする必要がありました。 •アペルザでは2018年夏からMailosaur (https://mailosaur.com/) を利用して います。
.BJMPTBVSͷհ 任意の文字列を含むメールアドレスに対してメールの送信ができ、APIで メールを取得することができます。 例) e2e-catalog-editor.<server-id>@mailosaur.io あらかじめメールアドレスを用意する必要がなく、送りつけることができ るのが便利です。 Java, Node.js, Python,
Rubyなどのライブラリも提供されているため組込 みやすいです。
.BJMPTBVSͷհ 受信したメールをブラウザで確 認することもできます。 textメールとhtmlメールを切り 替えて表示の確認ができます。 emlファイルのダウンロードも できるのも便利です。
ࠓ·Ͱ͖ͬͯͨ͜ͱ
ͷؒʹ࣮ߦڥΛճม͑·ͨ͠ • 2017年〜 Java(JUnit) + Selenium (Selenide) PageObjectPatternで実装 • 2018年〜
Gauge + Selenium (Selenide) • 2020年〜 mabl(2020年9月にスタートアッププラン から エンタープライズプラン に変更) ※切替中は平行運用しています。
+BWB +6OJU 4FMFOJVN 4FMFOJEF 1BHF 0CKFDU1BUUFSO • 良いところ ◦
JavaとJUnitは使い慣れていたので、はじめやすかったです。 ◦ SeleniumのラッパーであるSelenideを利用することで簡潔に書くこ とができました。
+BWB +6OJU 4FMFOJVN 4FMFOJEF 1BHF 0CKFDU1BUUFSO • 問題点 ◦
失敗した時にテスト結果を確認するのが大変でした。 ▪ 失敗時の画面の状態がわかりにくい (画面キャプチャ撮ってファイルに保存してました) ◦ Page Object Pattern が使いにくかった。 ▪ 例えば、ログインボタンを押した後の状態は、ログイン成功とログイン失敗がある と思いますが、上手く表現できなかった。 ◦ テストケースを増やすにはJavaが書ける必要があった。 ◦ テストコードを書くのが面倒で、なかなか増やす気になれませんでした。
(BVHF 4FMFOJVN 4FMFOJEF Gaugeでは、シナリオを MarkDownで記述します。 シナリオには操作を記載し、実際 の操作をJavaなどで実装します。
(BVHF 4FMFOJVN 4FMFOJEF 操作のJava実装。 @Stepアノテーションの記載が、 MarkDownで記載したシナリオに 関連付けられます。
(BVHF 4FMFOJVN 4FMFOJEF 実行結果が見やすいです。
(BVHF 4FMFOJVN 4FMFOJEF • 改善したこと ◦ 実行結果がとても見やすくなりました。 ◦ 再利用可能なステップを実装することで、非エンジニアでもシナリオ を増やすことができるようになりました。
(実際はエンジニアしか作成しませんでした)
(BVHF 4FMFOJVN 4FMFOJEF • 問題点 ◦ Chromeがアップデートなど、環境変化によりテストに失敗することがありました。 ▪ どうせまたChromeの更新の影響なんじゃないの?とテスト結果の確認を後回しにして、 バグを見逃すことも起きました。
◦ 並列実行ができていないため時間がかかっています。 (Gaugeは並列実行をサポートしてるけれど環境を用意できなかった) ◦ IEの実行環境を用意できませんでした。 ◦ E2Eを想定した実装になっていないので、要素の指定が難しい。 (idが振っていないなど、拡充するためにテスト用のdata属性の追加を検討していました) ◦ CSSに関連するデグレが見つけられない。 ◦ ローカルに実行環境を構築するのが非エンジニアには難しい。 (JavaとGaugeのインストール)
NBCM • 改善したこと ◦ 実行環境の保守からの開放! ◦ 並列実行による実行時間の短縮! ◦ コードが書けない人も作れる! ◦
要素の指定に悩むことがなくなった。 ◦ IEテストができるようになった。 ◦ Visual Changeを検出してくれるので、スタイルの変更も検知できるようになった。 • 問題点 ◦ IEでの実行を安定させるには工夫が必要。
ͭͷൺֱ ʙΞϖϧβͷ4&5ͷྺ࢙ʹͳͧΒ͑ͯʙ ※1 並列実行も可能だと思いますが環境構築の作業をやりませんでした。 ※2 Gaugeの結果画面は見やすいですが、さらにステップ毎に画面キャプチャを撮るようにしています。 サービス名 実行環境 実行環境の メンテナンス
実行時間 結果確認 ケース作成 ができる人 ケース作成 Selenium 社内のPC 必要 長い (直列実行 ※1) 大変 Javaコード を書ける人 大変 Gauge 社内のPC 必要 長い (直列実行 ※1) ◎簡単 ※2 作成済の部品(Java)が あれば誰でも ◯簡単 (でも要素の指定は大変) mabl クラウド ◎不要 ◎短い (並列実行) ◎簡単 ◎誰でも ◎簡単
͜Ε͔ΒΓ͍ͨ͜ͱ
ΧόϨοδͷ֦ॆͱNBCMͷҠߦ • カバレッジを拡充 ◦ E2Eのカバレッジを上げることで、言語・フレームワーク・ライブラ リのバージョンアップに対する抵抗感がなくなると思っています。 • mablの方がメンテナンスが楽ですし、Visual Changeが使え るのでGaugeからmablに移行をしたいと思っています。
少しずつアプリが増えてきて、いまデプロイパイプラインが複雑になって います。 例えば、アプリAを操作した後に、アプリBを操作するテストシナリオがあ った時に、アプリAとアプリBのデプロイパイプラインが別れていると、デ プロイパイプラインに組込みずらいと思っています。 まずパイプラインを整理して、本番リリース前に必ずE2Eをパスするように したいです。 σϓϩΠύΠϓϥΠϯʹΈࠐΉ
ߏจνΣοΧʔͳͲ੩తղੳͷಋೖ 過去にこんなことがありました。 Chromeでは動いて、IEで動かない不具合が見つかり、原因を調査したら htmlの構文が正しくないためでした。 ◦ buttonタグの中にaタグが記載されていて、Chromeだとaタグが優先さ れますが、IEではbuttonタグが優先されformのactionが動いていました。 どの環境でも動くようにするには、E2Eを拡充するよりも、IDEなどの指摘 を減らしたほうが良さそうに思ってます。
·ͱΊ この1年で開発メンバーが増え、QAチームによるテストの実施待ちが発生 しそうな気がしています。 E2Eは品質の最後の砦としてカバレッジを増やしていく予定ですが、より仕 様や設計フェーズでの不具合を減らす活動にシフトする必要がありそうだ と感じています。 QAチームだけが頑張るのではなく、開発メンバー・QAメンバーが一緒にな って品質向上に向けて活動できるようにしたいと思っています。 QAをチームではなく活動に!
͝੩ௌ͋Γ͕ͱ͏͍͟͝·ͨ͠ɻ もちろん採用してます! 新機能も続々!