アジャイルスクラム/かんばんチームの適切なテスト戦略は何ですか？

問題は：

私が働いているチームは、開発者が10人、テスターが2人という比率です。つまり、「テスト」よりも早くコードを作成することになります。

では、アジャイルの専門家によると、このようなシナリオでの活動を追跡するための正しいアプローチは何でしょうか？

以前のスプリントで「完了」と呼ばれるもの（テストは行われていません）がたくさんあるときに、近いうちにその日が来るのではないかと心配しています。

努力をシームレスに追跡するにはどうすればよいですか？テストは「完了定義」の一部である必要がありますか？そうでない場合の落とし穴は何ですか？

私によると、実際に機能テストされる前にストーリーを「完了」と呼んでいるので、これは一種の「ウォーターフォール」です。

はい、テストは絶対に「完了」の定義の一部である必要があります。疑いもなく。

純粋にアジャイルの観点から見ると、適切なアプローチは、チームの全員がテストの作成に貢献することです。テストを調整するのはテスターですが、ソフトウェアが適切にテストされていることを確認するのはチーム全体の責任です。

まず、10：2の比率は悪いです。経験上、開発者とテスターの比率は3：1または4：1が適切です。したがって、少なくとももう1人のテスターが必要になる可能性があります。そうしないと、テストのバックログが大きくなり、クリアされないか、どこかで手抜きされます。

次のスプリントでタスクをテストする場合、テストと開発を分離するため、ミニウォーターフォールまたは「スクラムフォール」を実装します。テストは完全に完了した定義の一部を形成する必要があるという点で正しい。タスクがテストされていない場合、「完了」と宣言するにはどうすればよいですか？

したがって、正しいアプローチは次のとおりです。

1. 可能であれば、テスターをチームに追加します。そうでない場合は、開発者にいくつかのテストを実行してもらいます（ただし、プロのテスターほどうまくはいきません）。
2. スクラム/カンバンボードを変更して、「テスト準備完了」列と「テスト中」列を含め、ワークフローの一部ですべてのタスクがこれらのレーンを通過する必要があることをチームに同意します。
3. タスクがテストで受け入れられた場合のみ、タスクは「完了」列に到達します。

これは一般的ではありませんが、かなり一般的です。いくつかの質問に答えるには：

• そのようなシナリオでのアクティビティを追跡するための適切なアプローチは何ですか？
• 機能はQAなしで完了しますが、欠陥はありますか？
• 努力をシームレスに追跡するにはどうすればよいですか？
• テストは「完了定義」の一部である必要がありますか？
• そうでない場合の落とし穴は何ですか？

私は次のような全体的なアプローチを取ります。

• テスターが価値を追加できるようにします
• 彼らに権限を与える
• 価値を最大化する
• QA担当者に開発者のトレーニングを奨励します

そして、それを行う（そしてあなたの質問に答える）ために：

• Jira、Trello、Pivo​​tal Trackerなどの機能も含む使いやすいバグ追跡システムにバグを入力できることを確認してください。

• 次の内容を説明する適切なバグレポートの作成に関するトレーニングを受けていることを確認してください。

  • 再現する手順
  • 初期/設定値
  • 入力された値
  • 適切な場合のスクリーンショット
  • 必要に応じてサーバーログ
• バグが割り当てられ、作業され、完了したことを確認します。
• それらをベストプラクティスでトレーニングし、会議に送ります。
• プログラミングとテストフレームワークの使用についてトレーニングします。
• テストのための良いアプローチと考え方についてプログラマーに教えることができます。

また、はい、一部の機能はQAなしで実行できますが、欠陥があります。QAは2つ目の目となることがよくあります。この役割は別の開発者が担当する場合があります。個人的には、これはいくつかのエラーを見つけますが、別のQAマインドセットが見つける可能性があるすべてのエラーではありません。

テストは一部実施する必要がありますが、QA担当者がテストを実施する必要があるという意味ではありません。リソースの不足と、QAが参照できる仕様を回避するアジャイル環境を考えると、QAは、ユーザードメインの学習、会議の設計、ポイントグルーミング会議、スタンドアップ、回顧などに関与する必要があります。

テスト戦略の大きな問題については、アジャイルテストの四分円を使用してガイドします。

                   |
      Integrated   |     Performance
_________________________________________
                   |     
           Unit    |     Exploratory

開発者はすでにユニットテストを行っているかもしれません。QAがカバーすることで価値を追加できる重要な領域は、統合テストとUIオートメーションの使用です。優れた探索的テストも非常に価値があります。これは、ページ上のすべてのリンクをクリックするだけでなく、エンドユーザーのドメインを学習し、アプリケーションを使用することがユーザーにとってどのような意味を持つかについてです。

QAとテスターの比率については、テストの三角形も考慮してください。

    Exploratory
  Integrated Tests
Individual Unit Tests

これにより、「スタック」全体を実行することにより、1つの探索的テストまたは統合テストで、数百ではないにしても数十のユニットテストを表すことができます。

また、アジャイルチームの場合と同様に、誰でもコードを作成し、だれでもテストできるというアプローチが必要です。もちろん、重要なのは、人々が必要なことを行えるようにガイダンスと構造を提供し、他の領域のトレーニングを提供することです。

実際の比率の点では、3：1または4：1のDavidの答えの正確さについて私は同意しません開発者が行うテストは1対1である必要があります。組織、構造、知識、業界などに実際に「依存」しています。

製品の構築を開始したときに、かんばんも実装しました。それに伴い、完全なテスト自動化戦略を実装しました。その結果、現在、チームにはテスターがいません。代わりに、開発者はテストケースを作成し、ユーザーストーリー、拡張機能、または不具合の作業の一環として自動化する必要があります。Dev Completeの定義には、単体テストと機能の自動化が含まれます。

開発が完了した後も、まだ「検証」段階にあります。すべての新しい開発作業（機能、バグ修正）がステージングサーバーに展開され、誰か（機能を機能的に理解している人）が検証する必要があります。私たちは、ドキュメントチームだけでなく、製品管理（場合によってはシニアEnggのリード/アーキテクト）を使用して検証します。各リリースは、実稼働環境にデプロイする前に、ステージングで最低1週間保持する必要があります。

これが私たちのかんばんボードのスナップショットです-

プロセスとかんばんは私たちのために働いています。ほぼ100％のテスト自動化があり、3〜4週間の製品リリースケイデンスがあり、何よりも、ほとんどのチームメンバーは製品のほとんどの部分に柔軟に取り組むことができます。

したがって、これは短期的な目標を満たさない可能性がありますが、長期的にはチームを再構築する方法を検討し、まだ完了していない場合は、チームが確実に優れた成果を上げるのに役立つテスト自動化戦略を検討することをお勧めします。短い間隔で品質。