アジャイルスクラム/かんばんチームの適切なテスト戦略は何ですか？
問題は：
私が作業しているチームには、開発者とテスターの比率が10です。つまり、「テスト」を行うよりも早くコードを作成します。
では、アジャイルの専門家によると、このようなシナリオでの活動を追跡するための適切なアプローチは何でしょうか？
私の恐れは、近いうちに、以前のスプリントで「完了」と呼ばれるもの（テストは行われていません）がたくさんあるときに実際にテストになると、いくつかの潜在的な欠陥があるかもしれないということです。
努力をシームレスに追跡するにはどうすればよいですか？テストは「完了定義」の一部である必要がありますか？そうでない場合の落とし穴は何ですか？
私によると、実際に機能テストされる前にストーリーを「完了」と呼んでいるので、これは一種の「ウォーターフォール」です。
はい、テストは絶対に「完了」の定義の一部であるべきです。疑いもなく。
純粋にアジャイルの観点からは、適切なアプローチは、チームの全員がテストの作成に貢献することです。テストを調整するのはテスターですが、ソフトウェアが適切にテストされていることを確認するのはチーム全体の責任です。
まず、10：2の比率は悪いです。経験から、3：1または4：1の開発者とテスターの比率は適切に機能します。したがって、少なくとももう1人のテスターが必要になる可能性があります。そうしないと、テストのバックログが大きくなり、クリアされないか、どこかで手抜きされます。
次のスプリントでタスクをテストする場合、テストと開発を分離するため、ミニウォーターフォールまたは「スクラムフォール」を実装します。テストは完全に完了した定義の一部を形成する必要があるという点で正しい。タスクがテストされていない場合、どのようにして「完了」と宣言できますか？
したがって、正しいアプローチは次のとおりです。
- 可能であれば、テスターをチームに追加します。そうでない場合、開発者にいくつかのテストを実行してもらいます（ただし、プロのテスターほどうまくはいきません）。
- スクラム/カンバンボードを変更して、「テスト準備完了」列と「テスト中」列を含め、ワークフローの一部ですべてのタスクがこれらのレーンを通過する必要があることをチームに同意します。
- タスクは、テストによって受け入れられた場合にのみ、「完了」列に到達します。
これは一般的ではありませんが、かなり一般的です。いくつかの質問に答えるには：
- そのようなシナリオでのアクティビティを追跡するための適切なアプローチは何ですか？
- 機能はQAなしで完了しますが、欠陥はありますか？
- 努力をシームレスに追跡するにはどうすればよいですか？
- テストは「完了定義」の一部である必要がありますか？
- そうでない場合の落とし穴は何ですか？
私は次のような全体的なアプローチを取ります。
- テスターが価値を追加できるようにします
- 彼らに権限を与える
- 価値を最大化する
- qA担当者に開発者のトレーニングを奨励します
そして、それを行う（そしてあなたの質問に答える）ために：
- jira、Trello、Pivotal 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の回答の正確さについて私は同意しません。開発者が優れたユニットテストと統合テストを作成している組織では、これは7：1で十分かもしれません。開発者が行うテストは1対1である必要があります。これは、組織、構造、知識、業界などに実際に「依存」しています。
product の作成を開始したときに、かんばんも実装し、それとともに完全なテスト自動化戦略を実装しました。その結果、現在、チームにはテスターがいません。代わりに、開発者はテストケースを作成し、ユーザーストーリー、拡張機能、または不具合の作業の一環として自動化する必要があります。 Dev Completeの定義には、単体テストと機能の自動化が含まれます。
開発が完了した後も、まだ「検証」段階にあります。すべての新しい開発作業（機能、バグ修正）がステージングサーバーに展開され、誰か（機能を理解している人）が検証する必要があります。私たちは、ドキュメントチームだけでなく、製品管理（場合によってはシニアEnggのリード/アーキテクト）を使用して検証します。各リリースは、本番環境にデプロイする前に、ステージングで少なくとも1週間滞在する必要があります。
これが私たちのかんばんボードのスナップショットです-
プロセスとかんばんは私たちのために働いています。ほぼ100％のテスト自動化があり、3〜4週間の製品リリースケイデンスがあり、何よりも、ほとんどのチームメンバーは製品のほとんどの部分に柔軟に取り組むことができます。
したがって、これは短期的な目標を満たしていない可能性がありますが、長期的に見てチームを再構築する方法を確認し、まだ完了していない場合は、チームがより優れた成果を上げるのに役立つテスト自動化戦略を検討することをお勧めします。短い間隔で品質。