生産性の向上: より迅速なリリースのための新しい QA ロールの実装ガイド

やあ！

システム QA の役割を導入することで、リリース フローを 20% 改善することができたことを共有できることを嬉しく思います。

私の会社は典型的な製品会社であるため、チームは製品ごとではなくコンポーネントごとに分かれています。このおかげで、一方では、知識の「保有者」を集めた強力なチームを形成することができました。しかしその一方で、ユニット内の役割は比較的孤立しており、さまざまなハード スキルや専門知識によって限界が課せられます。たとえば、テスターをバックエンド チームからフロントエンド チームに、またはその逆に移動する必要がある場合があります。

このため、QA チーム内の効果的なオーケストレーションとチーム間のやり取りの管理に問題が生じました。もちろん、これは最終的にリリース フローに影響を与えました。

変更前のリリースフロー

変更前のリリース フローは次のようになっていました。

1. ビジネス要件仕様 (BRS) は、ビジネス内の特定の機能、システム、製品、またはプロジェクトの詳細なニーズ、期待、仕様の概要を説明する文書です。これは、ビジネス関係者と開発チームまたは実装チームの間の橋渡しとして機能し、何を達成すべきか、そしてそれが全体的なビジネス目標とどのように一致するかを明確に理解できるようにします。これには、ユーザーが機能をどのように操作するかを説明する詳細なシナリオが含まれている必要があります。機能所有者 (FO) は、ビジネス要件を策定する義務を負っています。
2. ソフトウェア要件仕様 (SRS)は、ソフトウェア システムが達成することが期待される内容の詳細な説明を概説する包括的な文書です。たとえば、どのコマンドがどのようにやり取りするか、どのプロトコルによって、どのようなデータが送信されるかなどです。機能に取り組んでいるチームがグラフィカル インターフェイスを利用している場合、SRS には開発中の機能のレイアウトが含まれている必要があります。機能アーキテクトは SRS の作成を担当します。
3. 品質アクション プラン (QAP) – 機能所有者が機能を受け入れる前にチェックする一連のケース。ドキュメントについて説明した後、機能の実装に進みます。最初のチームがその機能の一部の開発とテストを完了すると、その機能は 2 番目のチームに転送されます。 2 番目のチームは統合/開発/テストを実行し、次のユニットに渡します。機能開発に参加しているすべてのコンポーネント チームがこのフローを通過するまで、同様に続きます。 FO は機能を検証し、リリースに送信します。

リリースフローの問題

したがって、書類、申請書、受理ケースなど、すべてがうまくいっているようです。ただし、このプロセスでは次のような困難に直面しました。

QA側の問題:

• 要件テストは開発後にのみ開始されます。開発者によってすでに実装されているタスクは、その要件とともに QA チームに引き渡されます。しかし、ご存知のとおり、要件には誤りがある可能性があります。
• どのケースが他のチームによってすでにテストされているかが必ずしも明らかではないため、バグの責任チームを見つけるにはかなりの時間がかかります。
• テスト成果物の再利用はありません。 1 つの機能をテストする一環として、QA チームは同様のテスト データ セットを準備します。しかし、チームが孤立していて専門性が狭いため、このデータを相互に送信することができませんでした。

副操縦士側の問題:

• 機能が多いため、QAP の作成には時間がかかります。
• 機能の検証は、すべてのチームによる開発後に行われます。私たちの場合、多くの統合上の問題により、リリース フローが大幅に長くなります。
• 製品の複雑さとチーム間の統合の量に応じて、テスト環境の準備も正確に行われます。さまざまなチームがコンポーネントを同時にテストしているため、データのマッシュ、変更、削除のリスクが増大しています。

更新されたリリース フローのシステム QA

QA チーム間の効果的なチーム間対話を促進し、リリース フローを削減するために、システム QA の役割を導入しました。

これにより、FO による受け入れケースの作成という形での作業負荷が軽減され、テスト シナリオの作成が高速化され、次のチームに渡す前に機能コンポーネントの中間テストが導入され、テストの準備という時間のかかる作業も移行されました。環境からシステム QA まで、統合とテスト データに関するチームのあらゆるニュアンスと要件を考慮します。

システム QA は、各機能の技術要件とビジネス要件と製品全体とを結び付けるものになっています。

システムQAのオンボーディング

リリース サイクル全体を理解するには、システム QA は各チームで特定のリリース サイクルがどのように機能するかを理解する必要があります。システム QA は各チームで 2 ～ 3 週間を費やして、チーム固有のリリース サイクルを理解するため、オンボーディングは通常約 3 か月続きます。

新しいプロセスの結果

• 現在、機能所有者とアーキテクトからの BRS/SRS 要件をテストしています。バグの早期発見はビジネスのコスト削減につながります。

• 私たちはクロスチーム QA スペースを確立し、ビジネス要件、技術要件、受け入れケース、他のチームのケース、テスト データなどの各機能にテスト成果物を添付しました。これにより、すべての QA チームが単一のコンテキストに属し、データを効果的に再利用できるようになりました。

• システム QA にはすべてのチームからのテスト ケースが含まれているため、バグのローカリゼーションのプロセスが迅速化されました。

• システム QA はチームごとに受け入れケースを作成するため、これはテストの高速化と品質向上の優れたヒントになります。

• 各コマンドの後に受け入れケースによって機能が検証されるため、統合プロセスは簡単になりました。

• FO からの負荷の大部分が取り除かれたことにより、機能の受け入れとテスト データとの統合スタンドの準備が加速されました。

  
  

全体として、リリース フローが 15 ～ 20% 加速され、統合バグの数がほぼ半分に減少しました。これは、BRS および SRS 要件を作成する段階と、機能開発のフレームワーク内でのチーム統合中の両方でバグを検出できるようになったためです。

楽しく生産的なテストを！