UXやUIを重視したアプリQAについて

プロダクトはUXやUIを重視したアプリ

ユーザーに高品質かつストレスを与えないサービスを利用していただくために
例えば、アプリだと色合いの方が重要視（ターゲット層によっても異なる）

• UXやUIの観点

• 多端末側面（機種、OSやOSのバージョン）

• アプリ動作

品質を担保する仕組作りをしておりました。

テスト

• 機能テスト：コアキングスペースでリラックスしながら
  

• バックエンドテスト：CharlesとFirebaseを利用
  

QAでは下記の内容を重視

1.リリーススピードと品質、両方とも大事でありQAが社内にあることでアプリチームの負担が軽減

2.過去起きた障害を分析し、把握対処することに時間をかけることが可能

3.QAの情報をアプリチームにも提供できQAへの意識が高まる

4.不具合改修確認を勝手にデザイナー、アプリエンジニアがすることがなくQAに最終権限

QA体制

1.iOSアプリエンジニア
2.Androidアプリエンジニア
3.QAエンジニア
4.QAテスター

の4名で進めてみる

QAフェーズ

フェーズとして3種類になります

Overall QA

Must QA

Production QA

QAフェーズ詳細

Overall QA

・既存機能と新規機能に関する機能や表示のテストを 「通常利用に問題がないか」 という観点で行うことで 「ユーザー」 に対して 「アプリの利用体験が適な状態」 を保証する

・このQA工程のみ、 「アプリエンジニアやデザイナー」 も参加します。

・理由としては、QAだけではなくアプリエンジニアやデザイナーも参加することで開発部全体のQA底上げができる

・アプリエンジニアやデザイナーがQAを通じて現状の課題や今後の対応すべき内容をいち早くキャッチアップできる点がメリットである

・どういう不具合が多いのか、傾向を把握することにより、今後実装時に生かすことができる点。

・QA期間内は、毎朝朝会で昨日の不具合チケットや要望Issueチケットを確認し、優先対応レベル判断を用意しています。

Must QA

・ 「金銭の授受を含み契約に関連する機能」 に関する、同意した項目テストを網羅的に実装されているかという観点で行うことで社内のステークホルダーに対してクライアントに提供するものが不完全ではないことを保証する。
・FirebaseのDebugViewで対象ログが出力されているか。impやClickであったり。
・Charlesでリクエストやレスポンス確認

DebugViewでリアルタイムにログ確認
https://console.firebase.google.com/?hl=ja

Charlesは、AndroidやiOSのスマホアプリテストでJSONファイルを書き換えで、リクエストやレスポンス確認にちょっと使っております。

Production QA

・最終チェックであり、 「起動できることマーケティング（スキーマ起動）できること、バージョンが正しいこと、PUSH通知が送れること、強制アップデートができること、ログが本番の分析環境に正しく出力していること」 を確認する

全体のまとめ

・リリースマネージャとともに、リリース計画からリリース予定日までリリース全体の把握とリリース品質を判断し、リリースの可否を決めます。このリリースマネージャが社内のリリース作業の効率化を行います。
QA実施は、開発エンジニアがコードフリーズ後に取り掛かります。

今後どうあるべきか

・まずはテスト自動化できる項目を洗い出し、Appiumというモバイルテストフレームワークを利用し。自動で確認できる仕組み。

・手動テストでもテスト設計レベルを、要件・因子でGithubのIssueテンププレート化し直交表に落とし込むことにより、禁則であったり網羅性の担保、全てのテストケースを作成する工数自体削減できる

取り組み

・一定の品質を提供するテスト設計のテンプレートを用意することにより、誰でも同じ粒度のテストケースが左作成でき、アプリリリース時にも同じ品質のアプリを常に提供できる

・第三者からのテストというレビューUXやUIについても。まずはQA時に1ユーザーとして気になる点や、使い勝手をチケットに記載。これは不具合というよりもユーザー視点でのレビュー

・独立性を保つため、アプリエンジニアとQA担当が分かれることによりお互い独立視点を維持できる