feather for Twitter の開発は主に 2人のエンジニアによって行われています。
そのため、多機能なアプリケーションに発生する不具合を見つけるのには限界があります。
特に設定の組み合わせや、通信環境 (電車内の不安定な環境など) によって稀に発生する不具合は発見が困難です。
そして何より今回のバージョンはちゃんと動くのかな？と思いながらリリースするのは精神的にも辛いものがあります。
こちらでは十分にテストを行った上でリリースはしているのですがそれでも限界があります。
そこで弊社ではどのようにその精神的な辛さを取り除いているのかを紹介したいと思います。
テスト
テストと言ってもイロイロあります。
feather for Twitter では 自動テスト と 人間によるテスト を行っています.
自動テストでは主にロジックのテストに専念していて UI のテストは行っていません.
UI は高頻度で変更が発生するのでテストのコストがバカにならないと判断したためやっていません。
しかし、もう一方の人間によるテストに力を入れることによってテスト範囲をカバーしています。
feather for Twitter では人間によるテストを 3段階に分けて実施しています。
これ以降はそれについて詳しく書きたいと思います。
その前に、ちょっと開発に使っているブランチ戦略についての説明です。
ブランチ戦略の説明
feather for Twitter では簡単なブランチ戦略にしています(以前はもうちょい複雑でした)。
ブランチは大きく2種類に分かれていて develop と それ以外のブランチです。
その他のブランチは全て develop ブランチから作られて develop ブランチにマージされます.
一般的には master って名前が付いているやつですね。
git flow や github flow の様なスタイルは取っていません。 以前はそれに近いブランチ戦略を使っていましたが 特にそこまでの必要がないなって思い始めたので思い切って現在のようにしました。
様々なテスト版の feather for Twitter
先程も少し触れましたが、 feather for Twitter は AppStore に公開されるまでに様々なテスト版が日々作られテストされています。
テスト版の種類は大きく 3種類あり
- alpha 版 -> 不安定
- beta 版 -> やや安定
- TestFlight 版 -> 安定
という様な安定感で運用しています。
それぞれ詳しく説明します。
alpha 版
これは日々の開発の中で機能が作られる毎に開発者に配布されるテスト版です。
先ほど説明したブランチ戦略の中にある develop ブランチに何らかの変更が行われる前に
開発者によるレビューが行われるのですが、そのレビュー用に配布されます.
- プルリクエストの度に自動的に alpha 版が fabric に登録される.
- プルリクエストをレビューする人はその alpha 版を使ってレビューを行う
- 機能やコードに問題がなければマージされる
と言った流れで、1日数回程度配布されます。
レビュー前のテスト版ですので非常に不安定な可能性があります。
クラッシュしたり機能がおかしくなっていたり、デザインがおかしかったりするのは日常茶飯事ですが develop にマージされる前にはちゃんと直します。
beta 版
こちらは小規模な外部テスター向けに配布しているやや安定したバージョンです。
- 毎晩1回、開発者によるレビューが終わった機能を試せるバージョンが fabric に登録される
- 機能があまり追加されていない日は配布しないが、自動化しているためビルドと登録は毎日行われる
- ボタンをぽちっと押すと配布
10名程度の規模で実施しており、週に 1 〜 2回の頻度で配布しています。
このバージョンは開発者によるレビューで見逃された不具合や、再現率が低い不具合を発見してもらうのが主な目的です。
基本的に開発者は引きこもりなので電車の中で使用した時などの回線環境が不安定な場合のテストを行うことができません。 そのため、一般的な生活をしている人にテストをお願いすることでより現実的なテストを行うことができます。
また、不具合報告はツイッターを経由した報告のほか fabric の Crashlytics の機能を使ってクラッシュログなどは自動的に収集しています。
TestFlight 版
これはリリースの直前に大規模に配布するテスト版になります(v2.12.0 から導入)。
- Apple が公式に提供している TestFlight の外部テスターの機能を利用
- 実際に申請に使用するものと同じバージョンが配布される
- beta 版の登録と同時にTestFlight (iTunesConnect) に毎日登録される
- ボタンをぽちっと押すと配布 (審査される可能性もあり)
規模は50名程度です(200名程度にまで増やしたいと思っています)。
TestFlight 版を使ってリリース前に深刻な不具合が無いかを最終確認します。
ここで深刻な問題が見つかれば審査を取り下げます。 軽微な問題であればそのままリリースします。
不具合の中には低い確率でしか発生しないものがありますが、そういったものを見つけるには人数が必要ですので 沢山のテスターに配布することができる TestFlight の機能は非常に助かります。
このテスト版でも Crashlytics の機能を使ってクラッシュログを収集しています。
まとめ
コベリンは 4人という小さい会社ですが、外部テスターにテストをお願いすることにより品質を向上させています。
テスターの皆さまのご協力により開発者の精神的な負担がかなり和らいでいるので感謝しています。
これからも feather for Twitter と合同会社コベリンをよろしくお願いいたします！
Android 版も絶賛揮発中です -> feather for Android 進捗
