タクシーデリバリー専用アプリ「GO Dine」のQAをご紹介

株式会社 Mobility Technologiesのicchiと申します。

以前、私がQAを担当しているタクシーデリバリーアプリ「GO Dine」にて、
スクラムチーム内で工夫・実践していること、私が感じていることをご紹介させて頂きました。

今回は「GO Dine」におけるQAについて少しご紹介したいと思います。

プロジェクト全体の流れ

まず、QAの前にプロジェクト全体の流れを以下に記載します。

　　案件相談　　　：事業運営メンバ、Pdm、Designer、Engineer、QA
　　　　↓
　　要件定義　　　：Pdm（& Designer、Engineer、QA）
　　　　↓
　　デザイン作成　：Designer（& Pdm、Engineer、QA）
　　　　↓
　　システム実装　：Engineer
　　テスト設計　　：QA
　　　　↓
　　テスト実行　　：QA
　　不具合改修　　：Engineer
　　　　↓
　　リリース　　　：Engineer

スプリント単位の開発フェーズに当てはめると、以下ようなイメージに
なります。

GO Dine QAチームによるQAの流れ

1.上流工程への参加

下記の工程にも部分的に参加し、仕様の考慮漏れや不備、
ユーザビリティなどをQAの目線からもフィードバック/提案をしています。
　・案件相談
　・要件定義
　・デザイン作成

2.テスト設計

下記のテスト設計作業に加え、設計をする中で検出した仕様の考慮漏れや
不備なども関係者にフィードバックをしています。
　・実装要件に対する機能テスト
　・リグレッションテスト
　・テスト設計レビュー、レビュー指摘修正

3.テスト実行

　・実装要件に対する機能テスト
　・リグレッションテスト
　・不具合報告及び、不具合改修確認
　・一気通貫テスト（システムの基本挙動を一通り確認）
　・Server定期リリーステスト（システムの基本挙動を一通り確認）

なお、スプリント期間中は、直近リリース対象の「テスト実行」と
次にリリースを控える実装要件の「テスト設計」を
並走して作業する必要があるため、状況に応じて柔軟に
タスクをスイッチしながら対応しています。

また上記以外にも時間の合間を見つけ、項目書のメンテナンスや
ナレッジの整備（テスト環境構築/テストデータ/テスト手順書の整理など）を
適宜行っています。

最後に

簡単ではありますが、「GO Dine」におけるQAは
何となくイメージ頂けましたでしょうか。

QA部分は比較的シンプルですが、「GO Dine」QAチームの特徴として
「上流工程への参加」を意識して取り組んでいます。

作られたプロダクトを検証して不具合流出を防ぐことに加え、
問題を上流工程の早い段階で検出し、できるだけ不具合を
作り込まないことにチャレンジしているそんなQAチームです。

今回のご紹介は以上になります。

MoTでは、私たちと一緒にチャレンジしてくれる仲間を募集中です。
ご興味のある方は採用ページからご連絡ください！