Ξϖϧβͷ඼࣭Λࢧ͑Δ&&ͷ άϨʔτδϟʔχʔ ٕज़෦ 2"ΤϯδχΞ ࠤʑ໦๜඙ NBCMίϛϡχςΟ΢ΣϏφʔ

௕͍͜ͱԣ඿ʹ͍·͢ ௕͍͜ͱ+BWBΤϯδχΞ ࠷ۙ͸ςετࣗಈԽΤϯδχΞ ΞϖϧβͰͷܦྺ ೥݄ʙ +BWBΤϯδχΞ ೥݄ʙ 2"νʔϜϦʔμʔ ࣗݾ঺հ

No content

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は週１で実行して います。 また、ログイン・ログアウトなど データの登録・更新を行わないテ ストについては、本番環境に対し ても実行しています。 &&Λಈ͔͢λΠϛϯάͳͲ 障害 レベル S ● クリティカルパスの機能において、ユーザーがアク ションを完了することができず、代替手段もない場 合。 ● 個人情報・機密事項漏洩の可能性がある A ● Sと同じ内容のトラブルだが、代替手段がある場合。 ● Sより重要度は低いが、ユーザーがアクションを完了 することができず、代替手段もない場合。 ● ごく限定的なユーザにレベルSのトラブルが発生した 場合 B ● アクションを完了することができないが、代替手段 がある場合 C ● 上記以外

&&ͰϝʔϧΛૢ࡞͢Δ ●E2Eを実装するには、会員登録時やパスワードリセット時に送信されるメ ールの本文にあるURLをクリックする必要がありました。 ●アペルザでは2018年夏からMailosaur (https://mailosaur.com/) を利用して います。

.BJMPTBVSͷ঺հ 任意の文字列を含むメールアドレスに対してメールの送信ができ、APIで メールを取得することができます。 例) [email protected] あらかじめメールアドレスを用意する必要がなく、送りつけることができ るのが便利です。 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が書ける必要があった。 ○ テストコードを書くのが面倒で、なかなか増やす気になれませんでした。

(BVHF4FMFOJVN 4FMFOJEF Gaugeでは、シナリオを MarkDownで記述します。 シナリオには操作を記載し、実際 の操作をJavaなどで実装します。

(BVHF4FMFOJVN 4FMFOJEF 操作のJava実装。 @Stepアノテーションの記載が、 MarkDownで記載したシナリオに 関連付けられます。

(BVHF4FMFOJVN 4FMFOJEF 実行結果が見やすいです。

(BVHF4FMFOJVN 4FMFOJEF ● 改善したこと ○ 実行結果がとても見やすくなりました。 ○ 再利用可能なステップを実装することで、非エンジニアでもシナリオ を増やすことができるようになりました。 （実際はエンジニアしか作成しませんでした）

(BVHF4FMFOJVN 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をチームではなく活動に！

͝੩ௌ͋Γ͕ͱ͏͍͟͝·ͨ͠ɻ もちろん採用してます！ 新機能も続々！