paint-brush
生産性の向上: より迅速なリリースのための新しい QA ロールの実装ガイド に@malykhpaul
5,574 測定値
5,574 測定値

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

Paul Malykh
Paul Malykh HackerNoon profile picture

Paul Malykh

@malykhpaul

8+ years of QA expertise, including highload backend and smart...

4 分 read2023/08/13
Read on Terminal Reader
Read this story in a terminal
Print this story

長すぎる; 読むには

システム QA の役割を実装して、チーム間のコラボレーションを強化し、テストを加速し、リリース プロセスを合理化しました。孤立したチーム、テスト成果物の再利用の欠如、統合の課題などの問題に対処しました。システム QA は技術要件とビジネス要件の間の橋渡しとして機能し、バグ検出、テスト効率、統合品質を向上させます。その結果、リリース フローが 20% 高速化され、統合バグが減少し、コスト削減とスムーズなリリース フローが確保されました。
featured image - 生産性の向上: より迅速なリリースのための新しい QA ロールの実装ガイド
Paul Malykh HackerNoon profile picture
Paul Malykh

Paul Malykh

@malykhpaul

8+ years of QA expertise, including highload backend and smart contract testing. Currently heading a 30-member QA team.

0-item

STORY’S CREDIBILITY

Guide

Guide

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

やあ!


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


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


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


変更前のリリースフロー

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


BRS、SRS、QAP という機能ごとに 3 つの主要ドキュメントを用意しています。

BRS、SRS、QAP という機能ごとに 3 つの主要ドキュメントを用意しています。

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

リリースフローの問題

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


QA側の問題:

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

副操縦士側の問題:

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


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

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


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


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


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

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


image
新しいプロセスの結果


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

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

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

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

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

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


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


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

L O A D I N G
. . . comments & more!

About Author

Paul Malykh HackerNoon profile picture
Paul Malykh@malykhpaul
8+ years of QA expertise, including highload backend and smart contract testing. Currently heading a 30-member QA team.

ラベル

この記事は...

Read on Terminal Reader
Read this story in a terminal
 Terminal
Read this story w/o Javascript
Read this story w/o Javascript
 Lite
X REMOVE AD