北海道に来ています。iOSチームのかっくんです。
初めての北海道がまさかの勉強会に登壇という自分でもびっくりな状況です。
今回登壇したのは以下のイベントです。

発表資料

発表した資料はこちらです。

概要

弊社はFammというスマートフォン向けアプリを開発・運営しています。

f:id:fromkk:20190718192335p:plain

開発体制としては現状CTOがProduct Ownerを兼ねています。主に今後アプリをどの様にしていきたいかを考えて、スクラムでいうユーザーストーリーを作っていきます。
次にディレクターがいて、POが考えたユーザーストーリーを解釈し、デザイナーにデザインの作成依頼をしたり、システム開発に必要な要素を集めてまとめます。
その後、エンジニアに仕様が降りてきて開発をしていく流れです。
最後に動作確認・品質担保としてQAがいます。歴史的な経緯もあるのですが、ソフトウェアエンジニアの経験者ではなく、いわゆるパートタイムで働いている方々が項目の作成とテストの実施を行います。

f:id:fromkk:20190718183633p:plain

Fammは2014年ごろから運用を始め、最初は家族内で共有可能なフォトストレージとしての機能しかありませんでした。
その後カレンダーの印刷機能が入り、そのままでは新たな機能追加がし辛い作りになっていたので、一度リニューアルを行いました。
その後グロースをしながら親戚招待やDVD機能や、さらなる商品の追加、ストア化をしながらどんどん機能が増えている様な状況です。

QAチームが行うテストとしては現在、

Feature QA: 新規開発やリファクタに伴う機能の動作確認・テスト
Dev QA(結合テスト): 開発中の機能全体が仕上がってから行うテスト
Release 前QA: リリース用のビルドが出来てから行うテスト

の3種類あります。
日々業務としてFeature QAとDev QAのがあり、合間にリリース前QAが差し込みで入っていました。
これは最初辛いとの事でしたが、曜日を固定化して予めスケジューリングしておくことで改善しました。
また、機能が増える度にリリース前QAの項目がドンドン増えて時間がとても掛かる様になってしまいました。

とうとう リリース前QAの項目を減らしたい との申し出がありました。
そこで、ビジネス観点で必要最低限これが動かないと死ぬと言うレベルの部分を担保することで同意して項目を削ることにしました。
また、機能をなるべく早く出してユーザーに価値を届けることを優先する様になりました。
とはいえ、エンジニアはタスクデーなどを利用して、既存機能のリファクタやバグ修正などを実施します。
QAの人が知らない内に何かしらの影響が出ないとも限りません。
次第に細かい不具合を見逃してしまう事が発生する様になりました。

このままじゃいけないなと思ってチームで話し合った結果 品質改善委員会 という会議が発足しました。

品質管理委員会とは

f:id:fromkk:20190718184648j:plain

品質管理委員会は、任意参加の定例MTGです。
参加者各自が品質に関して問題だと思うことを付箋に書き、似たものをグルーピングし、グループ毎に優先度を決定し、毎週優先度の高いものから話し合いを行い、アクションに落としていく様な感じで運営しています。
その中で、QAチームで自動テストのが出来ないかという提案がありました。
もちろん僕たちエンジニアもユニットテストやUIテストは書いていますが、画面単位のテストなので、網羅的なシナリオテストは欲しいなと思いながら手を付けられていませんでした。

まず、Android版でEspressoのテストレコーダーを利用してみました。
レコードボタンを押して画面を操作するだけでテストが出来るので、最初は良いかと思われたが、写真アップロードなど、難しいテストに対してどう対処すれば良いのか分からない、OSが出すダイアログのハンドリングが難しいなどの問題がありました。
続いて、iOS側も同じくXCTestのUI Recording機能を利用しました。
まず、当時QAチームが利用していたMacbook Airだと遅すぎる問題があり、頑張ってレコーディングをしても、思う様に動いてくれない事が多く諦めました。

非プログラマーにはやはり難しかった なというのが分かりました。

Magic Pod

そこでMagic Podを試してみる事にしました。
Magic Podはウェブブラウザー上でUIテストの作成・実行が可能なテストプラットフォームです。

機械学習を利用
Appiumをラッピング
GUIで要素の検索、操作、アサートの設定などが可能
ほぼ全てが日本語で操作可能

という特徴があります。特に、ほぼ全てが日本語で操作可能 という事が非プログラマーには非常に大事です。簡単にテストケースを作成するデモ動画を作成したのでよければご覧ください。

youtu.be

注意点としてXCTestのUIテストと同様に accessibilityIdentifier の設定がとても大事です。
また、ローカルとリモートの端末の選択が出来るんですが、リモートは重いので、テストケースの作成はなるべくローカルで行う事がオススメです。

メリット

Slackグループで不具合報告や要望を伝えると(物によっては)すぐに実装してもらえたりするので、不明な事があれば気軽に問い合わせをしてみると良いかもしれません。
BitriseなどCI経由でリモート実行する事が出来るので定期的に実行して結果のウォッチも可能です。
以前書いた記事にもちらっと紹介しています。

techblog.timers-inc.com

デメリット

現時点ではデメリットも色々あります。
ローカルでのビルド環境を整える為にエンジニアが環境整備を行う必要がありました。
また、Xcode 11より導入されるTest Planの様に複数の環境を一気にテストするという事が現状出来ないという点もあります。
複雑なテストケースを作成すると実行時間制限の15分をすぐ超えてしまう事があるので適度に分割が必要です。
普段マニュアルテストを実施しながら合間でテストケースを作っているのでどうしても時間がかかってしまいます。
現状進められる時に合間を見つけて作業をしている様な状況です。

目標

目標としてはリリース前QAの一部を完全自動化したいと思っています。
その上で人間じゃ無いと出来なかったり気づけない様な箇所や体験に関する箇所を目視で確認して欲しいなと思っています。
また、今は過去に作った機能についてのテストを足している様な感じですが、将来的には新たに作る機能に関しては自動テストも一緒に作成される様になると良いなと思います。