【実践的QA/テストプロセス】私たちの品質保証のプロセス(後編)

こんにちは!アクセルラボのQAグループマネージャーのkenabeです。

前編では要件定義から参画するシフトレフトの活動から詳細設計レビューまでの流れをご紹介いたしました。 今回は後編となりますので、前編をまだご覧になっていない方は合わせて読んでいただけると幸いです。

▼前編 tech.accel-lab.com

品質を組織文化に組み込む体系的QAプロセス

我々のプロセスは、単なるバグ発見ではありません。開発の早期段階から品質を設計し、チーム全体の当事者意識を醸成し、データに基づき継続的に進化する仕組みそのものです。

4. テスト仕様書作成:誰でもテストできる「再現性」を担保する

合意したテスト観点から、具体的な「テスト仕様書(テストケース)」を作成します。IoTのテストケースは、操作が複数の機器にまたがるため、手順の明確さがより一層求められます。

  • テストケースへの落とし込み: 「アプリでタイマーをセットし、指定時間後にデバイスがONになることを確認する」のように、操作対象(アプリ/デバイス)と期待結果を明確に記述します。
  • 網羅性の担保: 観点だしで洗い出した項目が、漏れなくテストケース化されていることを徹底します。
  • わかりやすい手順: 操作が複数の機器や機能にまたがるIoTテストにおいて、曖昧な手順は致命的。テスト仕様書は再現性を担保する最も重要な設計書となります。
  • 徹底したレビュー: 作成したテスト仕様書は、QAチーム内のピアレビューと、開発・PMによる外部レビューを経てFIXさせます。

5. 開発者による受け入れテスト:品質への当事者意識を高める

私たちのプロセスでは、QAにビルドを引き渡す前の「受け入れテスト」を、開発者自身に実施してもらいます。

  • 目的: 開発者自身が、プロダクトの根幹をなす正常系の機能(障害レベルA)が最低限動作することをQAに引き渡す前に確認します。これにより、明らかな不具合がQAフェーズに持ち越されることを防ぎ、QAはより本質的な観点(仕様の矛盾、ユーザー体験の課題など)のテストに集中できます。
  • 合格率98%の意義: 私たちのチームでは、「受け入れテストの合格率98%以上」をQAフェーズへ移行するルールとしています。これは開発者がクリアすべき品質基準です。なぜ100%ではないのか?それは、軽微な表示崩れなど、テスト全体の進行に影響を与えない不具合まで修正を待つことによるスケジュールの遅延を防ぐためです。しかし、障害レベルA(正常系)のクリティカルな不具合は100% PASSしていることが絶対条件です。この基準は、「テストを効率的に進めるための品質」と「開発スピード」のバランスを取るための、現実的かつ効果的な指標なのです。

このプロセスは、開発者に「自分が作ったものが、きちんと動くのか」という品質への当事者意識を強く促し、チーム全体の品質文化を醸成します。 結果として、QAフェーズでの初期不具合密度が下がり、お本来注力すべき仕様・ユーザー体験面のテストに時間を使えるような仕組みになりました。

6. テスト実施とBTS管理:品質の見える化

開発者による受け入れテストをクリアしたビルドに対して、QAが多角的にテストしていきます。

  • テスト実施と判定: テスト仕様書に基づき、アプリの操作とデバイスの振る舞いを同時に確認し、OK/NGを判定します。
  • BTSによる不具合管理: 不具合はBacklogなどのBTS(Bug Tracking System)に起票します。この時、アプリのログ、デバイスのログ、再現動画などを添付し、原因調査がスムーズに進むよう工夫します。
  • 進捗管理: 収束曲線グラフを利用しテストの消化状況や不具合の発生・収束状況などで日々トラッキングし、関係者にSlackで自動通知して共有します。計画からの遅延や、特定の機能に不具合が集中しているなどの傾向を早期に察知し、対策を講じます。
  • 効率的な改修のための優先順位付け: 不具合が多数報告される中、すべてを同時に修正しようとすると非効率になりがちです。QAはユーザー影響度やテストのブロッカーとなっているかを考慮し、「この不具合から先に修正してほしい」という改修の優先順位を開発チームに提案します。これにより、修正後の手戻りを最小限に抑え、効率よくテストを進めることができます。

継続的なプロセス改善:未来の品質を作るために

リリースはゴールではなく、新たなスタートです。今回のプロジェクトで得た学びを、振り返りを行い未来のプロダクト開発に活かします。

そのためにナレッジを蓄積しているのが「ヌケモレチェック表」です。過去のプロジェクトで発生した不具合(例:「特定のWi-Fiルーターとの相性問題」「OSアップデートによるアプリの不具合」など)や、レビューでの指摘事項をリスト化したりテストケースに落とし込みます。次のプロジェクトが始まる際に、このチェック表や過去のテストケースを基にレビューやテスト設計を行うことで、同じ過ちを繰り返すことを防ぎます。

こうした地道な改善活動が、IoTという複雑なシステムの品質を支える土台となるのです。

まとめ

前編・後編で、アプリとハードウェアが連携するIoTプロダクトの品質を保証するための、私たちのQA・テストプロセスをご紹介しました。

  • ユーザーストーリー定義からの両利きレビュー(ソフトウェア/ハードウェア)
  • シフトレフトによる手戻り防止
  • 開発者自身が受け入れテストを行うことによる品質意識の向上
  • AI活用など、新しい手法への挑戦
  • 振り返りや「ヌケモレチェック表」による継続的な改善

このプロセスの「型」は、多くのアプリケーションQAと共通しています。大切なのは、その型に「IoTならではの観点」をどう落とし込み、チーム全体で品質に向き合っていくかです。

ソフトウェアだけ、ハードウェアだけでは完結しないからこそ、チーム全員で知恵を出し合い、品質を作り上げていく必要があります。そのプロセス全体をデザインし、ユーザーに最高の体験を届けることこそ、IoT時代におけるQAの醍醐味だと感じています。

📩 お問い合わせ・採用情報

本ブログを読んでいただきありがとうございます。 もし内容にご興味を持っていただけましたら、以下よりお気軽にお問い合わせ・ご応募ください。

スマートホームの導入をご検討中の企業様へ:

👉お問い合わせ - SpaceCore(スペースコア)

技術にご興味を持たれたエンジニアへ:

アクセルラボではエンジニア採用を強化しています。 私たちの技術やビジョンに共感し、スマートホームの未来を共に創っていきたい方のご応募をお待ちしています。

👉 https://recruit.accel-lab.com/