スクラムガイドにテスターがいないと書かれているのはなぜですか？

私はscrum.orgのスクラムガイドを読んでおり、次のように書いています。

開発チームには、テストやビジネス分析などの特定のドメイン専用のサブチームは含まれていません。

文字通りの翻訳では、これは混乱を招くテスターがいないことを意味します。彼らはどのようにこれを提案できますか？

次のいずれかを意味します。

1. テスターは開発チームに統合されています-開発者がテストだけでなくテストを支援するツールを構築します。

   または：

2. チームはテスト駆動開発を実践します。つまり、システムを実行する自動テストを作成します。

どちらの場合も、別のテストチームは必要ありません。

文字通りの翻訳では、これは混乱を招くテスターがいないことを意味します...彼らはどのようにこれを提案できますか？

はい、これはまさに彼らが示唆していることです。言い換えれば、開発者はテスターであり、テスターは開発者です。

アイデアは、コードの所有権と品質を育成することです。

これは、コードがテストされていないことを意味するのではなく、コードの作成に関与した人がテストに関与していることを意味します。責任の分離はありません。

このアプローチが解決しようとしている問題は、開発者とテスターの間の非常に一般的な分離です。標準以下のソフトウェア。

これの基本的な部分は、機能するコードを作成して要件を満たすことがコーダーの責任であることです。これには、特定の考え方が必要です-「私が書いているコードは、想定されていることを行います。」

コーダーの責任をミックスするということは、コーダーが他の活動のために他の考え方を入力する必要があることを意味します。

テスターの責任は、バグを見つけ、機能が必要な機能から逸れる場所を見つけることです。これには、「コードが壊れているため、その方法を調べる」という考え方が必要でした。

同様に、ビジネスアナリストは、顧客が実際に求めている要件を特定しようとしています。これには、「アプリケーションはこのように動作しませんが、動作するはずです」という別の考え方が必要です。

コーダーがこれらの他の機能のいずれかで動作するためには、考え方が競合し、コーダーがサブパーを実行する合理的な可能性があります。

• Coder / QA-「コードは完全に機能します。コードを壊す可能性があると考えられるあらゆる方法を処理するために、すでにコード化しています。」
• コーダー/ BA-「コードは私が望むように機能するはずであり、これらは顧客が考えていないことを追加するためのきちんとしたものになるでしょう。

これは、すべてのコーダーがこれらの問題の影響を受けやすいということではありません（非常に才能のあるコーダー/ QAタイプに出会ったことがありますが、彼らが書いたコードではありません）。

これは、開発チームにも及んでいます。開発チームの責任とそれらの責任の関連する考え方を混ぜると、最終製品（コード）が損なわれます。

テスト専用のサブチームはないという。これは、テストがまったく実行されないという意味ではありません。これは、チームメンバーが独自のテストを行い、多くの場合、他の人のコード/機能をテストすることを意味します。私はスクラムの方法論にあまり詳しくありませんが、手足を動かして、クライアントもテストに関与している可能性があると言います。

これは部分的には、自分のコードのテストを書いてそれが機能するかどうかを確認することを期待されていることを意味すると思います（そうでない場合は、実際にそれを終了していない） 。

人々がソフトウェア品質の仕事を他の人に任せて無視することを許可するのではなく、これは誰もが常に品質の観点から書いているコードについて考えることを強制するので、それは良い考えです。

このステートメントは基本的に、サイロ化された作業を回避しようとしています。これに対するソリューションの一部は、次のようなプラクティスです。-テスト駆動開発-ペアプログラミング-プルリクエスト-テストの自動化など、すべてのテストを、側面または「後」。

さらに、スクラムガイドでは役割について非常に限られた話があります。実際、彼らは開発チームについて話します。彼らが意味するのは、あなたが強力なクロスファンクショナルチームが欲しいということです。つまり、プロジェクトに必要なものに応じて、UX、BA、QA /テスター、Ops、Coderなどのスキルが必要になりますが、これらをカバーする1人または複数の個人であるかどうかは実際には重要ではありません。

DevOpsの社員がいるように、私が協力しているチームには確かにQAが役割を果たしています。しかし、これらはすべて開発者でもあり、これらの分野に特化しています。秘trickは、サイロに陥らずに単独で作業することです。

テスターがいないわけではありません。スクラムチームに専用のテスターがいる場合とそうでない場合があります。

私にとって、このスクラムに関する声明は、配信パイプライン全体を単一のチームとして考える必要があるということです。同じチームの一員であることは、いくつかのことを示唆しています。

1. ストーリー/バグ/タスクに関する単一の見積もりがあります。devの見積もりとテストの見積もりはありません。
2. チームは、テスターがいない状態でストーリーを推定してコミットしません。
3. 何か問題が発生した場合、開発者の責任と同じようにテスターの責任ではありません。 チームのせいですです。
4. チームがテスターを借りたり、要求したり、依頼したりする必要はありません。
5. テストは、完了の定義の一部です。テストされていない作業は不完全な作業です。
6. 開発者は、コードを設計する際にテスト容易性を考慮する必要があります。

単一のチームで一緒に作業している場合、チームは一緒に成功し、一緒に失敗します。私は、いくつかのテスターがいる非常に成功したスクラムチームに参加しました。テスターは、すべてのスタンドアップ、グルーミングセッション、計画などの間に出席していました。ストーリーのテスト方法が明確でなければ、チームはそれにコミットしませんでした。見積りをするときは常にテスターと話しました。

テスターを実際に配達チームの一部として扱わない可能性のある兆候。

1. テスターに​​は「QAスタンドアップ」があります（うん、見たことがあります）。
2. テスターに​​は個別の管理構造があります。
3. QAリードがあります。
4. エンドツーエンドのテストに大きく依存しています。
5. テストは次のスプリントで書かれます。
6. ほとんどのテストは、スプリントの最終日に行われます。

これらは主観的なものであり、必ずしも間違っているわけではありません。私の意見では、これらは危険信号です。

これはすべて、テスターの指定された役割を持つ人がいなくてもスクラムチームを持つことは完全に可能です。それもうまくいく。特にテストを自動化する場合。TDDも役立ちます。