実験プラットフォームとしてのWindows Phone

ほとんどのIT企業は、MicrosoftのモバイルオペレーティングシステムのシェアがiOSやAndroidのシェアよりも小さいため、Windows Phone用に製品のバージョンを作成していません。 ただし、これは市場で3番目に大きいモバイルオペレーティングシステムであり、アプリはBadoo Windows Phoneで長い間使用されてきました。



もともとは、Silverlightの外部委託開発者によって作成されたもので、長い間更新されておらず、数年間、製品に専用の部門はありませんでした。 2014年、Windows Phoneの開発者が会社に来てこのアプリケーションのサポートを開始し、テスト用のタスクの一部を受け取り始めました。



数ヵ月後、完全に新しいアプリケーションを作成し、ほとんどすべての古い成果を放棄することが決定されました。これは主に、コードが理想からほど遠いためであり、そのサポートに多くの時間が費やされました。 Windows Phoneの最初の新しいアプリケーションは、パイロットプロジェクトBadoo-Hot or Notでした。 概念的には、Badooに非常に似ていますが、機能ははるかに少なく、わずかに異なります。 わずか3か月で、2人はGitリポジトリの1つのブランチでHotまたはNotアプリケーションをゼロから作成し、最終的にマスターになりました。 また、TeamCityアプリケーションは、各開発者のコ​​ミットが個別のアプリケーションとしてアセンブルされるように構成されていたため、テスターとして、クライアントの変更履歴を確認できました。





Hot or Notのいくつかのリリースの後、Badooの開発に戻り、両方のアプリケーションを共通のカーネルで作成することにしました。 これは、Hot or NotとBadooに共通のGitリポジトリと共通のVisual Studioプロジェクトがあることを意味していました。 当時、Windows Phone 8に加えて、Windows Phone 7もサポートしていました。また、Visual Studioの仕様により、これらは完全に異なる2つのアプリケーションであり、2つのアプリケーションで構成される2つのプロジェクトがありました。 1人のテスターに​​とっては、これは非常に多く、1つのリリースでGitに1つのブランチがあったときに、古い開発スキームを使用すると多くの間違いを犯す可能性があります。 そして、開発プロセスを改善する方法を考え始めました。





リフレクションの過程で、ワークフローの2つの主な要件を提案しました。

• まず、テスターと開発者はお互いをブロックしないでください。 私たちは2人しかいませんでしたが、一方が他方の作業をブロックすると、チームの半分が機能しなくなりました。
• 第二に、各タスクは異なる段階で数回チェックする必要があります（異なる人がより良い）。

iOSおよびAndroidのモバイル開発チームがGit Flowを使用していることに気付きました。 これは、テストが3つの段階に分かれているかなり大きなシステムです。

最初は、マスターと開発の2つのGitブランチがあります。 テストの最初の段階はブランチの機能です。 開発者はDevブランチから新しいGitブランチを作成し、その中にクールな機能を作成し、テスト用に提供します。 タスクが検証され、すべてが問題なく実行されると、Devブランチにマージされます。

特定の数のタスク（たとえば、10）がこの方法で処理されると、テストの第2段階である統合の時間が来ます。 ここでは、複数のブランチが相互に統合されているために発生するバグについてタスクをテストします。 この段階で見つかった問題は、統合ブランチの最優先事項で修正されています。

テストの最終段階は、アプリケーションの新しいバージョンをストアに公開する前に行われます。 これはリリーステストです。 これは統合テストに似ています。 リリースで見つかったバグも優先度が最も高くなります。 このリリースのすべてのタスクがチェックされると、リリーステストが実行され、アプリケーションが公開され、リリースブランチがDevとMasterにマージされます。





Git Flowは、大規模なiOSおよびAndroid開発チームに適した非常に興味深い優れたシステムです（それぞれ15人以上）。 しかし、1人のテスターと1人の開発者が一緒に作業するのは難しすぎるため、テストの最初の段階を削除することを決定し、結果のシステムは「Windows Phone Team Flow」と呼ばれました。



これにより、開発開始からわずか3か月で新しいBadooアプリケーションを正常に起動しました。

2015

2015年、私たちのチームは2倍になりました-開発者とテスターを雇いましたが、これは奇妙なことです。開発者に対するテスターの古典的な比率は1/3です。 しかし、これには理由がありました：

1. 自動化はほとんどありません。 現在、開発の初期段階にあり、ほぼすべてのチェックを手動で行っています。
2. 開発者にはMicrosoftの優れた標準ライブラリがあり、Telerikライブラリと組み合わせて、新しいUIインターフェイスを非常に迅速に開発できます。 Windows Phoneの設計は非常にシンプルであり、複雑なアニメーションを避けようとしています。 これらすべてにより、開発者はより短時間でより多くのことを実行できます。
3. 多くの実験により、私たちは大規模な開発チームよりも多くの新しい機能をアプリケーションに作成していますが、私たちは少数です。

実験

ユーザーへの新しいバージョンの配信が高速であるため、当社で最高の実験プラットフォームはウェブです。 真の継続的インテグレーションがあります：本番環境に1日に2回新しいビルドを投稿し、各計算に1分もかかりません。 しかし、今日、モバイル業界は飛躍的に発展しており、モバイルアプリケーションを好むユーザーが増えています。 そのため、同社の優先事項はモバイルプラットフォームに移行しています。 そして、大きな問題がありました。 ほとんどの場合、ウェブ上で開始された実験の結果は、モバイルクライアントの現実には不適切であることが判明しているため、実験には特別なモバイルプラットフォームが必要です。



Windows Phoneが実験に適しているのはなぜですか？

Windows Phoneのモバイルリソースのユーザー数は全体のわずか3％であり、毎日何十万人もいます。 この量により、A / Bテスト、さらにはA / B / C / Dテストを実行できます。これらのテストは、コントロールグループを含む4つのグループに分けられます。 一方、エラーが発生した場合、多数のユーザーのアクティビティに影響を与える可能性があるユーザーはあまり多くありません。 大規模なプラットフォームでのアクティビティの減少は、リソース全体のアクティビティの顕著な減少を伴います。



AppStoreでのレビュー時間が1週間または2週間であるiOSとは異なり、Windows Phoneストアでのレビューには20分しかかかりません。 Microsoftによると、16時間後、アプリケーションは世界中でダウンロードできるようになります。 そして、私たちの経験では、わずか2時間で、私たちにとって重要なすべての市場でダウンロードできます。 これは、Windows Phoneの新しいバージョンのアプリケーションの配信速度が速いことを意味します。 ユーザーの60％は24時間以内に更新されます。



Androidには、携帯電話にインストールされているハードウェアの非常に大きな断片化があります。 さらに、各ベンダーは、基本を変更しながら、このオペレーティングシステムの独自のバージョンを作成します。 Microsoftは、電話で使用されるハードウェアに厳しい制限を設定しており、Windows Phone OSのサードパーティバージョンはありません。 したがって、オペレーティングシステムまたはハードウェアに依存するバグはほとんどありません。



Windows Phone OSは、iOSとAndroidの発売後に開発されました。 そして、大きな違いが1つあります。それはグラフィカルインターフェイスです。 iOSおよびAndroid OSとは異なり、Metroの設計は大幅に簡素化されています。 丸められたものは正方形になります。 複雑なアニメーションはほとんどありません。 一方、マルチタスクとタッチスクリーンを備えた同じモバイルオペレーティングシステムです。 そして、これらすべてのオペレーティングシステムのアプリケーションはまったく同じように見えます。





Windows Phoneの上記のすべての利点のおかげで、私たちはモバイル実験プラットフォームになりました。 私たちのチームは製品マネージャーのアイデアを迅速に実装し、統計を収集して、この機能が成功するかどうかを判断します。 すべてが順調であれば、このアイデアはiOSおよびAndroidの開発チームに与えられ、通常の「フロー」でこの機能を実装します。 統計でアイデアに問題があると言われた場合、プロダクトマネージャーはそれを完成させる方法を考えます。 表示されたら、修正して再度起動します。 何も役に立たない場合は、クライアントからこの機能を削除します。 2015年、実験の結果、55の新機能を実装し、モバイルプラットフォームの収益を大幅に増やすことができました。

これらの結果を達成するのに何が役立ちましたか？

翻訳者、デザイナー、モバイルサーバー開発、課金開発者の各チームには、そもそも実験のタスクに関与している人々がいます。 これにより、新しい機能をより迅速に作成できます。



私たちはまだコミュニケーションの問題がない小さなチームです。 職場を離れることなく、すぐにタスクについて議論できるため、「会議」はほとんどありません。 特に、週に一度だけ収集し、製品マネージャーと毎週のリリースサイクルについて話し合います。



当社では、テストケースはまったくありません。 開発とメンテナンスに多大な時間が費やされるためです。 さらに、指示に従った人の仕事は、研究や実験を行う意欲を減らし、テストは創造的なプロセスです。 特に実験チームでは、毎週いくつかの新しい機能を作成しています。 テストケースの代わりに、機能ごとに分けたノートを使用して、好きなものを見つけることができます。一部にはマインドマップが添付されており、アプリケーションコンポーネントとその入力パラメーターの関係を確認できます。

公益事業

Badooは、テストと開発を高速化するのに役立つ非常に多くの異なるユーティリティを作成しました。次に、主なものを見ていきます。



サーバーログビューアインターフェース

ほとんどすべてのテスターが、バグのどちらの側（クライアントまたはサーバー）を判別する必要がある状況に直面したと確信しています。 また、このタスクを簡素化するために、サーバーログを表示するための非常に便利なインターフェイスを作成しました。これにより、ユーザーログや履歴、およびリアルタイムログや履歴によってフィルター処理されたログを表示できます。 さらに、セパレータを追加したり、さまざまな部分を非表示または表示することができます。



QaAPI

問題を再現するためにテストアカウントまたはテスト環境を準備するのが難しい場合があります。 たとえば、登録の1週間後にユーザーのメールに届くレターがどのように見えて機能するかを確認する必要があります。 実際のテストケースは次のようになります。新しいアカウントを登録し、1週間待ってから手紙を受け取り、最後に確認します。 しかし、これは長すぎます。テスターの最初の考えは、サーバー開発者に行って、データベース内の何かを変更してもらい、メッセージをより速く受信できるようにすることです。 しかし、そのような些細なことで開発者の注意をそらすことは非効率的です。さらに、多くの類似した「些細なこと」が存在する可能性があります。 そして、みんなが幸せになるために、QaAPIを作成しました。 これは、テスト環境またはテストアカウントをすばやく準備できるAPIメソッドのコレクションです。 登録の1週間後に送信される手紙の場合、1秒以内に手紙を受け取るために1つのQaAPIメソッドを実行するだけで十分です。 Dmitry MarushchenkoのレポートからQaAPIの詳細を学ぶことができます。



サーバーのモック

当社では、サーバーは通常、モバイルクライアントよりも高速に開発されます。 ただし、Windows Phoneの開発速度が速いため、チームには問題があります。サーバーの準備が整っていないため、新しい機能をテストおよび開発することはできません。 このような問題を取り除くために、Server Mockというインターフェイスが作成されました。 これにより、サーバーが特定のクライアント要求に対して事前に決定された応答を返す特別なテスト環境を作成できます。 これは、すべてのサーバーおよびクライアントチームの必須参加で開発されたプロトコルのおかげで可能になりました。

Pavel Dovbushのレポートでは、Web、モバイルクライアント全般、特にプロトコルの開発について知ることができます。



Badoo内部App Store

アプリケーションストアに公開されたアプリケーションに加えて、各モバイル開発チームにはもう1つのアプリケーションがあり、これを「内部アプリケーションストア」と呼びます。 これらを使用すると、iOS用のxCode、Windows Phone OS用のVisual Studio、Android OS用のAndroid SDKをインストールせずに、クライアントのテストビルドをインストールできます。 プロダクトマネージャーがすぐに「リリース」される新機能の作業を研究したい場合、デザイナーがこの新機能の外観を確認したい場合、または翻訳者が実際の携帯電話で新しく翻訳されたテキストの外観を知りたい場合、目的のアプリケーションアセンブリを選択してインストールするだけです。



Debug_menu

アプリケーションの各テストバージョンには、大きなDebug_menuセクションがあります。 たとえば、Windows PhoneのDebug_Menuでは、クライアントログを表示したり、メールで送信したり、写真のキャッシュや一般的なキャッシュをクリアしたり、必要に応じてアプリケーションを塗りつぶしたりできます。 一般的に、テストと開発を促進する多くの機会があります。

統計

前に書いたように、当社ではWindows Phoneで多くの実験が行われています。これらの実験の結果を理解するために、多くの統計を収集しています。



ホットパネル

統計用の独自のユーティリティは、BIチーム（ビジネスインテリジェンスチーム）と呼ばれる別のチームによって開発されています。 このようなチームを持つことで、製品マネージャーのニーズを満たす完全に構成可能な統計を作成できます。



アパニー

モバイルアプリストアにフィードバックを残すことで、ユーザーから報告された問題に迅速に対応するために、AppAnnieを使用します。 これは、AppStore、Google Play、およびWindows Phoneストアで評価とレビューを収集して処理するサービスです。



ホッケーアプリ

アプリケーションの新しいバージョンの成功の主な指標の1つは、クラッシュ率です。 また、実際のユーザーからクラッシュログを収集するには、HockeyAppを使用します。



キーチャート

また、ユーザーの投票アクティビティ、承認、アクティブなユーザーの数など、リソースの主要なメトリックを示す多数のグラフがあります。





数か月前に、新しいダブルタップTo Likeタスクを実装しました。 ユーザープロフィールが多数あるPeople Neighborhoodアプリケーションのメイン画面の1つで、ユーザーのアイコンをダブルタップするだけで、Badooは自動的に賛成票を数えます。 この機能を起動することにより、多くのユーザーが積極的に投票することを期待していました。 統計を収集することで、ほとんどのユーザーの投票活動が実際に増加し、リソースの女性オーディエンスでは全体的なアクティビティが増加し、リソースの男性の部分では全体的なアクティビティが減少したことがわかりました。 そのため、ダブルタップを「いいね」にするのは女の子だけにしておき、実装のためにiOSおよびAndroidチームに渡しました。 この例は、実験の成功に関する決定を下すために統計が非常に重要であることをもう一度証明しています。



これらはおそらく、私たちがあなたに伝えたかったすべてのメソッドとユーティリティです。 これらを組み合わせることで、モバイルアプリケーションの開発とテストを大幅に加速できます。 Badooでテスト済み。 次はあなたの番です！



ヴャチェスラフ・ロクティック

シニアモバイルQAエンジニア（Windows Phone）