QA テスト支援 IT（スタートアップ）

スタートアップにおける柔軟なQA支援体制の構築

専任のQAを置かずに、
必要なときだけテストを頼める体制です。

Challenge

相談が来たときの状態

コンシューマー向けアプリを運営するスタートアップにおいて、リリースごとのテストは開発者やPMが分担して実施していました。

リリースサイクルの増加に伴い回帰テストの負荷が増大し、新規機能の検証が十分に行えない状態となっていました。

また、テストの専門性が不足しており、リリース後に不具合が発生するケースも見られていました。

一方で、QA業務は常時発生するものではなく、必要なタイミングだけ柔軟に依頼したいというニーズがありました。

Approach

月に2〜3回のリリースに対して、必要な回だけ、必要な範囲だけ確かめる形にしました。

Channel

Slackで依頼できる体制を作る

Slackで常時つながった状態にし、必要なタイミングで依頼できるQA体制を作りました。契約や調整の手間を、依頼のたびに繰り返さない形です。
Design & Run

仕様からテストケースを作り、実行する

新規機能については、NotionやFigmaの仕様をもとに、スプレッドシートでテストケースを作成し、実行まで行いました。仕様の読み違いも、この段階で見つけます。
Timing & Scale

依頼のタイミングと規模に合わせる

依頼日にそのまま着手することもあれば、検証環境にビルドされるタイミングを前もって教えてもらい、準備して臨むこともあります。小さな変更はその日のうちに確かめ、影響範囲の広い回帰テストは数人日で対応します。急ぎの依頼では、土日や夜間に対応したこともあります。

Test cases

NotionやFigmaの仕様から、使う人の立場で確かめる観点をテストケースに書き出し、実行した結果とあわせてスプレッドシートで渡します。

Bug ticket

開発者やPMでは見落としがちな不具合を、再現手順と影響範囲を明記したチケットにして返します。開発チームがすぐ動ける形です。

Outcome

専任のQA担当者を置かずに、必要なタイミングで品質を確認できる状態になりました。

開発者やPMでは見落としがちな不具合を検出し、再現手順と影響範囲を明記したチケットにすることで、開発の手戻りが減りました。

依頼のしやすさと対応スピードにより、継続的に活用される体制となっています。

支援前

支援後

急な対応にも関わらず、いつもありがとうございます。

依頼元の担当者の言葉

Contact

似た状況でのご相談を受け付けています。
現在の状況を伺いながら、どこから着手できるか一緒に整理します。