リモートQAチームのテスト管理5つのヒント

リモートワークがかつてなく身近になっています。従業員をオフィスに戻そうとする動きもあるいっぽうで、多くの企業がリモートワークの可能性をさらに追求し、受け入れようとしています。

これは、対面のコラボレーションに戻りたいテスターにとっては、変化を意味するかもしれません。しかし、適切なプロセスがあれば、在宅でもオフィスと同様に成功を収めることができます。以下は、分散化されたQAチームがよりスムーズに協働するための5つのヒントです。

定期的にチェックインミーティングを行う
ドキュメントを最新の状態に保つ
ステータスを更新する
バグ記録および優先順位付けプロセスを定義する
リリースおよびオンコールの分担を決める
コミュニケーション、ドキュメント作成、計画がすべて

定期的にチェックインミーティングを行う

分散されたテストチームでは、定期的なチェックインミーティングが重要な計画の機会になります。毎日のスタンダップミーティングは、チームメンバーがその日の予定を伝え、重要な引継ぎを調整し、ブロッカーについて話し合うのに有効です。チェックインミーティングでは以下のようなトピックを話し合います。

テストの割り当て: これは、複数のメンバーがシステムの同じ領域で作業しており、関連する目標やテストの調整が必要な場合に特に有効です。

どの環境でどのビルドおよび機能が利用できるか: 成果物を段階的に検証する場合、すべての機能が利用できるとはかぎりません。システムのどの部分が完全には機能しない可能性があるのかが、テスターにとって明確でなければなりません。

ドキュメント: 要件、テストのチャーター、テストケース、その他の付随的情報を明確にチームに伝達し、皆がそれぞれに必要な情報をどこで見つけられるかを知っている必要があります。

スケジュールと進捗: 効果的で効率的なテストの妨げになる障害があればマークし、リスクやデリバリーの遅れが予想される場合にマネージャーが他のチームに周知したり、組織の上層部に伝達したりできるようにします。

今後の作業: 今後の機能のテスト計画案を前もって作成できるよう準備します。

チェックインミーティングを毎日実施するのは過剰だと思われる場合、週に何日か、あるいは週に1回のミーティングを検討してください。目的によって使い分けることも可能です。毎日のミーティングは担当やブロッカーについて話し合うのに適しており、週に1回のミーティングは今後の作業についての決定を行うのに適しています。

チェックインミーティングの目的を明確にし、効率をキープしたいとお考えですか？TestRailを利用すると、テストケースの割り当てと実行、新規テスト計画の作成のほか、進捗の追跡や欠陥の報告も可能です。これによって、より追跡が困難なものに時間をかける余裕ができます。

ドキュメントを最新の状態に保つ

リモートテストチームがうまくいくためには、明確でよくメンテナンスされたドキュメントが必要です。一般的なルールとして、新しく入ったメンバーにとって自明ではない情報や、テスターが毎日使用するわけではない情報については、書き留めておくべきです。

安全性が確保されている場合は、チームの誰もがアクセスできる共有のwikiに情報を保存できます。より機密性の高いテストデータやパスワードは、認証・認可されたメンバーだけがアクセス可能な共有保管場所に保存します。

最新の状態を保つドキュメントの候補になるのは、テスト環境の手順書や、リソースへのアクセスを請求するにあたって知っておくべき情報です。これには、VPNアクセスの手順書、モバイルアプリ用QAビルドを提供するツールへの招待、関連ステージングサーバーへのリンクなどが含まれるでしょう。

テストの完了に必要な特別な情報は、TestRailなどの利便性の高い場所に保存するべきです。たとえば、支払い処理コンポーネントを含むアプリケーションでは、様々な入力値によって異なる結果を得られるような特殊なテスト用クレジットカード情報が必要な場合もあるでしょう。

ステータスを更新する

ステータス更新の頻度と内容について、チーム内であらかじめ取り決めておくべきです。通常、頻度はプロジェクトの緊急性によって決まり、短期間でのやり取りを必要とする局面では、コミュニケーションを増やすのもよい考えです。堅実な余裕のあるプロジェクトでも、軌道を逸れることがないよう、定期的なステータス更新が必要です。

不透明な状況では、開始時からコミュニケーション過剰になりがちです。チームにも経営層にも価値をもたらさないステータスの更新に時間がかかりすぎていると感じられたら、いつでも簡略化するという選択肢があります。

たいていの場合に妥当な頻度として、一日または週の終わりに直属のチームにステータスを伝達することから始めます。マネージャーの裁量で、伝達の範囲を広げるとよいでしょう。

ステータス更新には以下の情報を含めます。

テストをブロックする、または遅らせるもの
発見された重大な問題の概要。特にリリースの障害となるものに注意します
期間内に完了した作業の概要
今後の作業計画の概要

チームのメンバーが利用でき、簡単にアクセスできるテストケース管理ツールを使用している場合、進捗は比較的わかりやすく、どこまでカバーされたかに関する詳細な記述は、それほど必要ではないかもしれません。

バグ記録および優先順位付けプロセスを定義する

課題を記録するためのプロセスをチームの全員が理解していなければなりません。これには、どのカテゴリを選ぶか(バグかフィーチャーリクエストかなど)、優先度と重要度の記述方法、再現手順、画面ショット、動画の規格や形式、問題が見つかったビルドの表記方法などが含まれます。

問題が報告されたらすぐに密接に協力し、相談できるという状況に慣れていたチームであれば、課題の重複を減らすため、新しいチケットを作成する前に課題トラッカーを検索する習慣をつけるのも重要です。

バグレポートの内容に加えて、どのように課題をレビューし、開発チームに割り当てるかを計画することも重要です。たいていの場合、チケットをエンジニアリングチームに送ったり、スプリントに自動的に割り当てたりする前に、チームの誰かが優先度を判断する必要があります。それによって課題の重複が減り、優先度が確定されるとともに、バグの調査にもなります。

混乱を減らすためだけでなく、効率性を維持するためにも、バグがどのように割り当てられ、レビューされるかが、すべての関係者に明らかでなければなりません。たとえば、リアルタイムで課題をレビューできない場合、テスターは、以降のテストをブロックしたり、システムの重大な問題を示していたりする欠陥について、どこにどうやって報告すればよいのかを知っている必要があります。欠陥トラッキングの詳細については、こちらの不具合管理に関する記事を参照してください。