読者です 読者をやめる 読者になる 読者になる

mixi engineer blog

ミクシィ・グループで、実際に開発に携わっているエンジニア達が執筆している公式ブログです。様々なサービスの開発や運用を行っていく際に得た技術情報から採用情報まで、有益な情報を幅広く取り扱っています。

iOSクライアントアプリとスクラム開発環境下での受け入れテストについて

QA scrum

はじめまして。
iOSクライアントアプリWindows8クライアントアプリQAを担当している、品質管理グループの菅原です。
今回は、私が普段行なっているiOSクライアントアプリの受け入れテストについて、ご紹介します。

これまでのmixiの受け入れテストは、ウォーターフォール開発に合わせた手法で行ってきました。そんな中、2012年8月のユニット制移行に伴い、スクラム開発を導入するユニットが増え、私の参加しているユニットでもスクラム開発が導入されました。

スクラム開発環境下では、従来の手法では対応できないことが多く、テスト実行前、テスト実行中、テスト完了後の各フェーズにおいて、試行錯誤を重ねています。

テスト実行前・テスト準備
テスト準備は、基本的にリファイメントとスプリント計画から得られるユーザーストーリーと、大まかな仕様の把握のみに留めています。

ウォーターフォール開発の受け入れテストでよく見られるような、事前に仕様書を読み込んで、テストケースを作成して、入念な準備をする、ということには、あまり時間を割いていません。

テスト準備に時間を費やさない理由は、スクラム開発では要求が変化することを前提としている為、十分な事前準備を行なっても、後々テスト設計が使えなくなってしまう可能性が高い、という点が挙げられます。また、スクラム開発では包括的なドキュメントより動作するソフトウェアを重視する、ということで、できるだけ多くのリソースをテスト実行に割り当てたい、と考えています。


テスト実行
ユーザーストーリーや大まかな仕様は把握していても、詳細までは把握できていない状況でテストを行う事になります。そこで、機能詳細を学習しつつテストを実行する為に、テスト実行フェーズを2つのステップに分けて進めていきます。

ステップ1:推奨状態での確認
ステップ1では、通信環境や諸々の設定が推奨される状態(電波状況が良い、プッシュ通知設定がON等)でテストを実行します。仕様の詳細を把握しながら、ユーザーストーリーを実現する為の機能群が正しく実装されているかを確認します。
インタラクションや非機能要件についても併せて確認を行い、問題があれば直ちに対応します。

ステップ2:非推奨状態での確認
ステップ2では、ステップ1で把握した仕様をもとに、通信環境や諸々の設定が推奨されていない状態(電波状況が悪い、プッシュ通知設定OFF等)でテストを実行し、機能が正しく制御されているか確認をします。
機能制御の具体例としては「電波状況が悪く、何らかの投稿を失敗した際にはタイムアウトエラーを表示する」といったものが挙げられます。

このステップ2では、非推奨状態において機能がスマートに制御されていない、というリスクを検出し、そのリスクの扱い(スマートな機能制御を実装する、とか、ユーザーガイドで補う等)をリリース前に検討することができます。

また、リスクの扱いについての検討の中で、関係者がアプリケーションに対して、
より深く正確な共通認識を持つことが出来るため、とても重要なステップになります。

そして、ステップ2では、ステップ1でテストした機能群を、更に主機能と貢献機能に分類し、主機能を優先的にテストしていく、という特徴があります。

主機能とは、ユーザーの立場から見て動作不能や欠陥があると、製品としての用をなさない機能の事を指します。

例えば、下図の"フォト付きつぶやきを投稿したい"というユーザーストーリーの場合、投稿導線、入力フォーム、写真添付、投稿ボタン、投稿したフォトが該当箇所に表示される、といったフォト付きつぶやきを投稿する上で欠かす事の出来ない必須機能が、主機能と分類されます。
もし、非推奨状態に関する問題が主機能上で発生した場合は、優先的に修正対応されることになります。

貢献機能とは、製品の有用性には貢献するものの、主機能ではない機能の事を指します。

下図で例を挙げるとすれば、"いま何してる?"というガイダンス表示や、キャンセルボタン、入力文字数制限等が、貢献機能にあたります。非推奨状態に関する問題が貢献機能上で発生した場合は、修正対応するか、次のスプリントに回すか、ユニット内で優先度について、検討することになります。


図: mixi公式クライアントアプリ(iPhone)のつぶやき投稿画面

post_voice_iPhone.png

 

iOSクライアントアプリの受け入れテストにおいて、非推奨状態は無数にありますが、
現在は、以下の点を中心に確認を行なっています。

通信環境

  • 電波状況が悪い環境下での確認
  • 圏外時の確認で、通信中に圏外になるパターン、通信開始前から圏外のパターン 等


デバイス側の設定

  • Push通知OFF設定時、位置情報OFF設定時のアプリの振る舞い
  • メールアカウント未設定時のアプリの振る舞い
  • 連絡帳や写真へのアクセスが許可されていない場合の確認 等


デバイスのハード面

  • 画面サイズ
  • 解像度 等


その他の影響

  • 電話着信やメール通知など、他の機能に割り込まれた場合の確認
  • アプリを新規インストールした場合の確認
  • アプリを上書きインストールした場合の確認 等


以上、テスト実行フェーズでは、確認すべき事柄に優先度を設定しており、よりクリティカルな事象をスピーディーに発見できるよう努めています。

テスト完了後
とは言え、メリハリのある優先度を設けていると、不具合を見落としてしまうことも、よく稀にあります。
見落としのきっかけとなったイレギュラーなイベントについては、振り返りを行い、
テスト実行のステップ2の視点にフィードバックして、次回以降のスプリントに活かすようにしています。
このフェーズを"テスト準備"と定義しても良いかもしれません。

まとめ
iOSクライアントアプリの受け入れテストでは、端末内に保存されている情報(写真や個人情報等)のパーミッションや、通信環境等、定義した要件の他にも、様々な外的要因を考えなければならず、また同時に、スクラム開発のスピードや変化にも対応できるフローも構築していく必要があります。

  • ユーザーストーリーと大まかな仕様の把握
  • 推奨状態でのユーザーストーリーを満たす機能、詳細仕様の確認
  • 非推奨状態での主機能の確認
  • 非推奨状態での貢献機能の確認
  • スプリントの振り返りと、反省点のフィードバック


上記のサイクルを回すことで、アプリのイレギュラーなイベントに対するスマートな処理を増やし、継続的に品質を向上できるように取り組んでいます。

今後も試行錯誤を重ねて、何らかの成果をご紹介出来ればと思います。