はじめまして。QA Engineer(以降QAE)チームのtakamaです。
私自身、これまでQAやゲームエンジニアといったキャリアを歩んできました。LayerXには2024年9月に入社し、この記事を書いている時点で8ヶ月目になります。前職までは主に不定期リリースにおけるQA活動が中心で、数ヶ月単位でじっくりと品質保証に取り組むスタイルでした。バクラクで初めて2週間という短いサイクルの定期リリースに携わることになり、日々新しい発見と学びの連続です。
本記事では、そんな私がバクラクで経験している定期リリースの仕組みと、その短い期間でQAチームがどのような活動をしているかをご紹介します。
2週間サイクルにおけるQAの動き方
バクラクのQAEは、各開発チームに1チームメンバーとして深く関わりながら、QAチーム全体として横断的な情報共有や自動テストといった施策の推進も行っています。このような体制のもと、2週間1リリースのサイクルの中で多岐にわたる活動を行っています。主なQA活動をご紹介します。
プロダクトバックログアイテム（PBI）の明確化と詳細化
PBIとは、将来的に実装する可能性のある機能や改善要望などを優先順位でリスト化したものです。PBIの目的や仕様を開発チーム全体で確認・共通認識を作ることで、実装すべき機能の仕様を明確にし、開発着手後の考慮漏れを防ぎます。 QAEも積極的に参加し、ユーザーストーリーの観点から仕様の曖昧さ、テスト実施上の懸念、潜在的な問題を早期に指摘・質問します。これは開発前のバグ作り込みを減らし、手戻りを防ぐ重要な活動です。
2週間サイクル開始時のミーティング
取り組むPBIを決定し、それらを達成するためのタスクを洗い出し、作業量の見積もりを行います。 QAEはPBIに対して、テストの観点から必要なタスク（テスト設計、テストデータ準備、テスト環境確認、テスト実行など）を洗い出します。
テスト計画作成
PBIに基づきテスト計画を立てます。大きな開発や改修がない場合は毎回作成せず、状況に応じて柔軟に対応します。
- テスト目的: 今回のテストで何を達成したいのか、何を検証するのかを明確にします。例えば、「新機能〇〇が仕様通り動作することを確認する」「リファクタリングによる既存機能への影響がないことを確認する」などです
- テスト方針・戦略: どのようなアプローチでテストを進めるか、重点的にテストする箇所はどこか、どのようなテスト技法を用いるかなど、テスト全体の進め方に関する方針を定めます
- スケジュール: いつまでに誰が何をするのか、各テストフェーズ（テスト設計、テスト実行、バグ修正確認など）の開始日と終了日を計画します
- テスト環境: テストを実施する環境（開発環境、ステージング環境など）を決めます
この計画は開発チーム内で共有し、テスト活動の指針となります。
リグレッションテストのテスト項目書のメンテナンス
新機能の追加や既存機能の仕様変更に合わせて、テスト項目書を常に最新の状態に保つようにメンテナンスします。
自動テストのメンテナンス
開発スピードと品質の両立のため、テスト自動化を推進しています。QAEは既存自動テストスクリプトが最新コードで正しく動作するか定期確認し、必要に応じて追加・修正します。 主なテストツールは以下の通りです。
- Playwright
- runn
- Autify
これらの使い分けについては、以前QAEメンバーのhashiさんが紹介していますので、詳細はそちらをご参照ください。
主なメンテナンス作業には、以下のようなものがあります。
- 新規機能に対するテストの追加
- UI変更への追従
- 仕様変更への対応
- テストデータの更新
- 不安定なテストの修正 (Flaky Test対策)
テスト設計
テスト計画（または個別の開発チケット）に基づいて、具体的なテストケースを設計します。様々なテスト観点や技法（同値分割、境界値分析など）を駆使し、効果的・効率的なバグ発見を目指します。 QAEは、仕様書やPBIの内容を深く理解し、お客様の実際の利用シーンを想像しながらテストケースを設計します。
ET会実施
ET会とは、探索的テスト（Exploratory Testing）を実施する会のことです。事前に詳細なテストケースを準備せず、テスターの知識・経験・直感でソフトウェアを操作しバグや問題点を発見します。 QAEだけでなく、開発者やプロダクトオーナーなども参加し、多様な視点からプロダクトを触り、予期せぬ不具合やユーザビリティの問題を発見します。 探索的テストについても、以前QAEメンバーのnaoさんが紹介していますので、詳細はそちらをご参照ください。
QA範囲レビュー
リリース前のリグレッションテスト範囲を、開発チームやプロダクトオーナーとレビューします。追加機能・改修機能から影響のある既存機能を洗い出し、テスト範囲が十分か関係者間で確認・合意します。
テスト実行
設計したテストケースに基づき、プロダクトを操作してテストします。準備した環境・データで手順通りに進め、実際の結果が期待結果と一致するか確認します。 発見したバグは再現手順などを明確に記録し開発チームへフィードバック。修正後、再テストを実施します。
振り返り会
開発チームで活動を振り返ります。KPT（Keep, Problem, Try）などで開発プロセス、コミュニケーション等について良かった点・改善点を話し合い、次回のアクションを決定します。 QAEはテスト活動の良かった点・問題点・改善策を積極的に提示し、開発チーム全体の品質向上に貢献します。
感想
これまで不定期リリースしか経験のなかったQAEとして、バクラクの2週間サイクルという定期リリースで実際に行った活動をご紹介しました。 不定期リリースの際は、ウォーターフォールに近い形で数ヶ月かけて対応していたのに対し、2週間という短い期間で品質を担保するには、実施すべきテストの的確な見極め、マニュアルテストの削減、そしてテスト期間に入る前の段階でいかに品質を作り込んでいくかが非常に重要だと実感しています。今後、プロダクトが拡大し確認項目が増えていく中で、より早期の段階から品質を意識する「シフトレフト」の取り組みが一層不可欠になると考えています。
さいごに
バクラクでは2週間間隔で定期リリースを行っています。このスピード感の中、QAEは計画から実行、改善まで一連のQAプロセスを主体的に回しプロダクト品質を支えています。変化の速い環境は挑戦的ですが、それ以上に新しい技術や手法を学び、開発チームと共にプロダクトを成長させる「わくわく」感に満ちた2週間の繰り返しだと感じています。
本記事が、バクラクのQA活動や定期リリースにおけるQAの役割について、少しでも皆様のご理解の助けとなれば幸いです。
少しでもご興味持ちましたら、お話ししましょう！ （以下からカジュアル面談を応募できます）
