More Related Content
Similar to LFK_MagicPod_Meetup_Share (20)
LFK_MagicPod_Meetup_Share
- 2. 自己紹介
2011 : ラーメン屋
2014 : LINE Fukuoka に当時テスターとして入社
その後 LINE Creators Market/ LINE Creators Studio 等の
LINEスタンプ関連の QA Engineer を担当
2017 : スタンプ事業関連QA部署のManagerに
2020 : QA組織内で自動テストチームを立ち上げ
福永 誠
LINE Fukuoka
QA室/QAE室 Manager
- 14. 通常 Animation Sound Popup Custom Effect Premium
and many
more!!
公式スタンプ 100coin 100coin 100coin 100coin 100coin 100coin subscription …
クリエイターズ
スタンプ
50coin 100coin × × 50coin × subscription …
絵文字 100coin 100coin × 100coin × × subscription …
公式着せ替え 150coin 150coin × × 150coin 150coin × …
クリエイターズ
着せ替え
150coin
× × 150coin × × × …
and many
more!!
… … … … … … … …
複雑な条件分岐
活用事例
※実際の仕様とは一部異なります
- 36. Visual Regression Testing (画像回帰テスト、画像差分比較テスト)
画像の差分検知により、自動化範囲を拡大！
※参考/出典：https://blog.trident-qa.com/2020/07/reg-cli-magic-pod-e2e/
Editor's Notes
- 本日は貴重なお時間いただきありがとうございます。
Line fukuoka の福永と申します
今回は Magic Pod の活用事例と題して、 弊社でのMagic Pod導入に至った背景から、現在に至るまでの過程を通してお話させていただきます。 何か皆様にとって参考になる部分があれば幸いです。よろしくお願いいたします
- それでははじめに自己紹介をさせてください
改めまして、LINE Fukuoka のQA部門のマネージャをしています、福永と申します。
前職は福岡のラーメン屋で働いていまして、IT業界とは無縁なところで汗水垂らしていました。
そこから色々ありまして 6年ほど前から LINE Fukuoka に入社し、その後LINE スタンプ関連事業のQA engineerを担当してきました。
その流れで、現在はスタンプ事業に関わる QA部門のマネージャになり、 今年に入って 自動テストチームを立ち上げています。 このチームで Magic Podのお力をお借りして価値を生み出そうと奮闘している最中でございます。 それではよろしくお願いいたします。
- では、今回はこちらの流れでお話させていただきます。
- 最初に Magic Pod という所謂ノーコーディングのツールを選択するに至った背景として、先ずは全体像として弊社QA組織の歴史から簡単にご説明させてください。
まず弊社のQA組織の立ち位置について、サービス開発組織から独立した組織となっています。
そして、従来のQA組織の役割としては主に手動でのブラックボックステストを主軸とした職務要件でした。
- そういった役割が主流となった背景として、LINEの急激なビジネス成長スピードにも起因しております。
お陰様でこれまで弊社サービスの拡大・拡充が猛スピードで成長してきたこともあり、
それら膨大なサービスの品質保証を担うために、急激な人員確保が急務となっていました。
そのため、間口を広げて多様な方を素早く採用することが当時重要課題であったため、 IT業界未経験の方も多く在籍しています。
- そういったQA部門の平均的なスキルセットも踏まえて、これまでは比較的入り口の敷居が低い手動テストを主軸とした職務を担い、
自動テストに関しては SET(software engineer in test) 組織が 間に入る形で、E2Eテストの自動化もSETが担う体勢で進めてきました。
- ですが、次第に QA組織とSET チーム双方の注力領域が異なってきました。
SET 側では自動テストピラミッドの概念等にならって、CI /CDといった開発寄りのテスト自動化に注力する方針に舵を切り出しました。 逆に 実装やメンテナンスコストが比較的大きくなる E2Eテストの自動化に関してはスコープを絞って実施する流れに切り替わってきました。
一方で、QA組織側では組織の成熟に伴って、単純作業だけでなく、人手を割くべき業務に注力できる環境が各現場からも強く求められるようになりました。
その改善策として、 E2Eテストの自動化も 非常に重要なキーとして適応範囲の素早い拡大に期待が強まりました。
そのため、SET の手の届かない部分には一部のQA メンバーが Selenium などを活用して自動化を進めるなど、部分的な改善はこれまでも実施されてきました。
- ですが、コーディングが必要なツールを使いこなせるスキルセットを持つ方は部署内でもまだまだ限られており、 既存の業務と並行して片手間での自動テストの作成や継続的なメンテナンスが追いかなくなったり。
あるいは 自動テストを運用できるメンバーの異動、退職などの事情によって使えなくなってしまう。といった改善が途切れる状態が続いていました。
また弊社ではWebサービスだけでなく、LINE メッセンジャーアプリのようにスマートフォンアプリを多く展開してるのですが、特にアプリのテスト自動化は効果的に運用できる人が更に限られてしまうなど、
なかなか広範囲に向けて継続的な効果を発揮しきれない課題を残してきました。
- そこで今年から改めて E2Eテストの自動化に注力するチームをQA組織内で立ち上げることにしました。
これまでの失敗事例を踏まえて、幅広い人が効果的に自動化できることを重視した結果、 数あるツールの中でもMagic Podが 弊社の課題解決に最も理想的なツールだと判断し、今年の3月から導入させて頂いております。
- というわけで前置きが長くなりましたが、そういった歴史を経て ここからは実際にMagic Pod の活用事例の紹介に移っていきます。
- 現在はLINE アプリから開ける スタンプショップという、LINEで使えるスタンプなどの販売サービスのテストと、もう一つ 社内の業務管理システムのテストに活用しています。
残念ながら、社内システムの方は社外に公開できない要素が多いため、今回はスタンプショップでの事例を代表で紹介させていただきます。
- スタンプショップの中で、現在は主にスタンプなどの販売商品の購入周りの E2Eテストを Magic Pod で行っています。
お金が絡む部分ですので、自動化による安定性向上も狙いの一つです。
- そして何よりも、コンテンツの種類が膨大になってきたことで、人力で正確なテストが難しくなっていた部分でもありました。
スタンプショップで購入できるコンテンツはリストに出してる通り、公式スタンプやクリエイターズスタンプといったメインカテゴリの中で、 音が出るのか、アニメーション効果があるかなどサブカテゴリも複雑に分岐しています。
さらに商品価格、購入導線、販売対象国家による違いなどが絡んでくるので、正直中の人でも細かい仕様を覚えきれないレベルで複雑化してきており、テストの安定性にも懸念が出てきていました。
- そこで、各コンテンツ条件ごとに網羅的な購入テストにMagic Pod による自動テストを適応しました。
また各カテゴリーのアイテムの購入の前準備や、購入後の確認項目には共通する部分が多いため、それらのフローは共通ステップにまとめています。
- そのため、基本的にはスライド上で矢印をつけています、アイテムのnameの書き換えのみで、各カテゴリのテスト切り替えができるようにしています。
- 簡易的な図解にするとこういうイメージです。
あくまで商品のカテゴリのみが変わるので、購入前後のステップはほぼ共通化されています。
それらを共通ステップに登録しておけば、何かメンテナンスが発生しても最小限に抑えられるということです。
という感じで、やっかいなテスト項目をMagic Pod にお任せてして安定的なテストが現在実行できるようになっています。
- ちなみに数値で示せるの成果についても、現時点で拾える範囲で参考までににご紹介します。
7月時点でスタンプショップでは 54のテストケースにMagicPod による自動化が進んでいます。ケース内に含まれる細かいステップ数で言うと815ほど
また 自動テストの誤検知の割合は 2%未満でしたので、 2000回以上実施された テストの 98% が安定的に実行されています。
これらは今年の 5月から約3ヶ月程度での結果となりますが、短期間での結果としては順調にテスト自動化の拡充を安定的に伸ばしてこれています。
しかし、私は冒頭に3月からMagic Podの契約をしたとお伝えしました。
なぜここで 5月からの数値なのか、勘の良い方はお気づきかと思います。 ここに至るまでには色々な苦労も当然ありました。
- というわけで、先ほどの数値が残っていない導入初期については失敗の歴史が隠れています。
それでは、次にそれらの失敗の歴史を踏まえて、結果どのようにして改善に至ったかについてお話していきます
- では、その失敗の歴史編です。
今年3月にマジックポッドを契約し、さっそく最初に自動化に取り組んだのですが、はじめは目的が曖昧なまま進めてしまったことであまり価値を生み出せない時期がありました。
最初の流れからお話します。
先ずは、繰り返しテストを自動化して、少しでも人手を軽くできればという、ありがちですが漠然とした思いではじめてみたのですが、
それまで手動テストで実施していたテストケースを特に深く考えずそのまま自動化しようと試みたことからはじまります。
- それの何が問題だったかというと、
手動テストでは既存のテストケースに記載されていない観点でも熟練テスターの勘と経験によって広範囲まで網羅されていることで、結果的に品質が担保されているという内情が判明しました。
これはそもそものテストケース自体の質にも問題があるのですが、幸か不幸かこれまで表面化していなかったこともありあまり問題として認識されていませんでした。
- というわけで、結局その時の自動テストは抜け漏れのある状態で流しているだけで、中途半端な検証しかできておらず、 だから、マニュアルテストも”しかたなく”以前と変わらずやるしかない、という状態になってしまい、自動化されたことで誰にどんな価値をもたらしているのか不明確になってしまいました。
これが暗黒の3月、4月時点での状況でした。
- そこで、5月より改めて目的を具体化するために現状把握から仕切り直しています。
過去のテストケースはあくまで選択肢が手動テストだけの状況で作られたものなので、
自動化という選択肢が増えたことを踏まえて改めてテストプロセス全体を再設計しなおしました。
- 現在はそれら一連の流れをこちらの導入プロセスガイドラインとしてまとめて導入初期から効果を見据えた運用を行うことで現在はプロジェクト全体が納得感を持って進められるようになりました。
ここは全体を説明するとけっこうなボリュームになってしまうため、詳細は割愛しますが、
要求分析フェーズで活用しているチェックリストの一部を参考までに紹介します
- こちらがそのチェックリストの一部を抜粋したものです。
最初にプロジェクトに導入する際に、どこから自動化するのが効果的か簡単に判断できるチェックリストを策定して運用しています。
内容としては、まず一般的な自動化の向き不向きに関する観点、例えば繰り返し実行されるかーなどの基準ももちろん含んでますし、
プロジェクトそれぞれの実際の経験もチェックポイントに含んでいます。 過去にヒューマンエラーでの見逃しなど発生したテストがあるか〜など。 また、自動化メンバー側で判断する、自動化難易度などを踏まえて、総合的な観点で優先順位の切り分けをリードできるフローを用意しています。
- それをもとに、自動化ニーズのあるテストシナリオ単位で区切って各観点のポイントをもとに優先度ランク分けをしています。
この結果を最終的にプロジェクト全体で認識合わせを行って、各関係者が納得して自動化に着手するという流れで進めています。
このように自動テストを作りだす前段階の導入フローを整えたことで、 自分たちも迷わず、周りからも期待を持たれて効果的な自動化を展開できるようになりました。
- では続いて、導入準備を経て 実際にMagic Pod でテストを作成する段階で意識していることについてです
- Magic Pod での自動化にあたって、「状態依存性」を慎重に考慮して作成するようにしています。
その理由ですが、スライドのように１つのテストケース内で複雑な条件分岐を行うと、不安的なテストにつながりますし、
仮に問題があった際の原因調査も手間がかかります。
- 実際に、初期には一つのテストケース内で前提条件に依存するテストを作成していましたが、
その場合には、エラーの調査に手間がかかることはもちろん、 中途半端な状態で落ちたテストをリトライするために、結局手作業で次のステップに進むための前提条件をセットしたりなど、
とにかくイケてない構成のせいで、自動テスト担当者が疲弊してきておりました。
- なので、現在は前提条件は共通化した上で期待結果ごとにテストケースを分割してなるべく一定方向に作成するよう心がけています。
これにより、仮にテストが落ちてもどこが原因か切り分けが素早く行えること、またリトライ時間も最小限に抑えられています。
加えて共通ステップを効果的に活用することで、そもそもの自動テスト作成やメンテナンスの効率化もできていいます。
- 次に、多言語対応のテストに関して
弊社サービスはグローバルに展開しているものが多いため、 多言語での確認もマニュアルテスターの時間と気力を奪う大変なテストの一つです。
これらは Magic Pod のデータパターン設定機能を使って、同じシナリオで期待結果のみ各言語で確認できるような作り方で効率化しています。
簡単ではありますが、活用事例の紹介は以上です。
- では最後に、今後の展望について少しだけ紹介します
- ここまで達成したダーン項目について、パイロットプロジェクトとしてスタンプショップと、社内ツール 2つのプロジェクトにスコープを絞って軌道に乗せるところまでは順調に来れています。
失敗を通して自動化のプロセス定義や、今回は触れませんでしたが CIツールとの連携などシステム面での強化も並行して行ってきました。
そして今後の展望、TODOについては、継続運用はもちろん、対応プロジェクト数の増加を今後進めていきます。
実際にここまでの活動成果が広まり、社内でもうちでもやって欲しいと複数希望が上がってきています。
ですので、Trident様との契約も 当初エンタープライズ”ライト”プランでしたが、 枠を増加してエンタープライズプランに契約更新させていただきました。
マジックポッドの敷居の低さを存分に活かして、今後もテンポ良く範囲拡大を進めて行きたいです。
- 別途、自動テストという選択肢をさらに多方面に活かしていくという方向でも検討しています。
TODOの緑色の下2項目についてがそちらにあたりますが、ここは個別に少し詳しくお話しさせてください。
- 一つ目は、今後テストシナリオの自動化だけでなく、障害再現ケースの自動化にも取り組んでいきたいと考えています。
これは、従来は人力のテストしか選択肢がなかったため、本番障害が発生した場合にQAチームが取りうる再発防止作はどうしても根性論によった、「気をつけてみます。リグレッションテストケースに追加します。」
といった抜本的な対策が取れないことが長年課題として持っていました。
そういったウィークポイントにも自動化の強みを活用して更に適切な再発防止、早期検知ができるような活用を進めていきたいです。
- 続いて、画像差分比較テストの導入にも取り組んでいます。
これにより、例えばスクリーンショットを目視チェックなどで対応していた確認工程も、より正確かつ高速化することを期待しています。
こちらは Trident 様の技術ブログでも詳しく紹介頂いてますので、それを参考に環境構築を行いました。
- 現在は実際に差分を検知してSlack通知させるところまでは成功できています。
また実験段階でスタンプショップの自動テストに組み込んでいるのですが、 つい先日に実際に細かいUI の表示バグをさっそく検知してくれていました。
そちらのバグについては、まだリリース前のものになるため、詳細は公開できないのですが有効性の期待は高まりました。
残る課題としては、例えば広告バナーなど同じ画面の中でも常に変化する前提の部分をどう扱うかなど、
画像差分チェック特有の使い所、注意点などナレッジを蓄積しながら、 安定的な実用化に向けて検討を進めていっているところです。
- 最後に
これまでの弊社QA組織で行うテストはほぼ「手動」で行う前提でした。
そのため、膨大な手作業にどうしても圧迫されて 本来のQA Engineer として行うべき、やりたいことがなかなか前進できずにいました。
- ですが、Magic Pod を活用して誰でもできるテスト自動化の成功事例を展開していくことで
継続的テストへの発展など、本来のQA Engineer としてより価値を発揮すべき領域に集中できる環境作りに貢献していきたいです。
- 以上で簡単ではありますが、LineFukuoka でのMagic Podの活用事例をご紹介させて頂きました。
このあと交流タイムを設けて頂いてますので、ぜひ情報交換をさせてください。
今回ご紹介した事例を実際に行なっている弊社自動化メンバーも参加させて頂きますので、更に詳しい話を本人達からお話しできると思います。
それでは以上となります、ご清聴ありがとうございました。
