testing - アジャイルのような開発では、誰がテストケースを書くべきですか？

Question

私たちのチームには、各開発者に割り当てられた小さな増分タスクを投稿するタスクシステムがあります。

各タスクは独自のブランチで開発され、トランクにマージされる前に各ブランチがテストされます。

私の質問は次のとおりです。タスクが完了したら、このタスクで実行する必要があるテストケースを誰が定義する必要がありますか？

理想的には、タスクの開発者自身がその仕事に最も適していると思いますが、時間の無駄だとか、単にやりたくないと思っている開発者からは多くの抵抗がありました。

QAの人にやってもらうのが嫌いなのは、彼らが自分の作品を作るというアイデアが好きではないからです。たとえば、テストするには手間がかかりすぎるものを省略したり、必要な技術的な詳細を知らなかったりする場合があります。

しかし、同様に、テストケースを実行する開発者の欠点は、壊れると思われるものを除外する可能性があることです。（無意識のうちに多分）

プロジェクトマネージャーとして、自分で各タスクのテストケースを書くことになりましたが、時間に負担がかかるので、これを変更したいと思います。

提案？

編集：テストケースとは、ブランチをトランクにマージする前に、ブランチに対して実行する必要がある個々のQAタスクの説明を意味します。（ブラックボックス）

score 19 · Accepted Answer

チーム。

欠陥が顧客に届いた場合、それはチームの責任であるため、チームは欠陥が顧客に届かないことを保証するためにテストケースを作成する必要があります。

プロジェクトマネージャー (PM)は、チームの誰よりもドメインをよく理解している必要があります。彼らのドメイン知識は、ドメインに関して意味のあるテストケースを作成するために不可欠です。入力例を提供し、無効な入力に対する期待についての質問に答える必要があります。少なくとも「ハッピーパス」テストケースを提供する必要があります。
開発者はコードを知っています。あなたは開発者がタスクに最適かもしれないが、ブラックボックスのテストケースを探していると示唆しています。開発者が思いついたテストはすべてホワイトボックステストです。これが、開発者がテストケースを作成する利点です。開発者は、コードの継ぎ目がどこにあるかを知っています。

優れた開発者も、「いつ何が起こるべきか?」という質問を PM に持ってきます。– これらはそれぞれテストケースです。答えが複雑な場合、「a の場合x、bの場合y、木曜日を除く」 – 複数のテストケースがあります。
テスター (QA)は、ソフトウェアのテスト方法を知っています。テスターは、PM や開発者が思い付かないようなテストケースを考え出す可能性があります。そのため、テスターが必要です。

score 8 · Accepted Answer

プロジェクトマネージャーまたはビジネスアナリストがこれらのテストケースを作成する必要があると思います。
次に、QA担当者に渡して、肉付けしてテストする必要があります。

そうすることで、仕様と実際にテストおよび提供されたものとの間に欠落したギャップがないことを確認できます。

開発者はユニットテストをテストするので、絶対にそれを行わないでください。ですから、それは時間の無駄です。

さらに、これらのテストでは、仕様の誤解、またはコードを介した機能やルートが適切に検討および実装されていないことが原因である可能性があるため、開発者が見つけることのできないエラーが検出されます。

十分な時間がない場合は、他の人を雇うか、誰かをこの役割に昇進させてください。これは、優れた製品を提供するための鍵です。

score 4 · Accepted Answer

開発者とQA担当者のペアリングを試してみたところ、かなり良い結果が得られました。彼らは一般的に「お互いを正直に保ち」、開発者はコードを処理するための単体テストを持っていたので、彼/彼はすでに変更に非常に親密でした。QA担当者はそうではありませんでしたが、ブラックボックス側からやって来ました。どちらも完全性について責任を負っていました。進行中のレビュープロセスの一部は、単体テストの欠点を見つけるのに役立ちました。そのため、問題があったことを証明する可能性があるため、誰かが意図的にXテストの作成を避けていることに気付いたインシデントはそれほど多くありませんでした。

私はいくつかの例でペアリングのアイデアが好きで、それはかなりうまくいったと思います。常に機能するとは限りませんが、さまざまな分野のプレーヤーが相互作用することで、頻繁に発生する「壁を越えて投げる」という考え方を回避することができました。

とにかく、それがあなたに何らかの形で役立つことを願っています。

score 4 · Accepted Answer

過去の経験から、わずかに異なるものをテストするために、さまざまなレベルでテストを定義することはかなり幸運でした。

第 1 層: コード/クラスレベルでは、開発者はアトミックユニットテストを作成する必要があります。目的は、個々のクラスとメソッドを可能な限りテストすることです。これらのテストは、おそらくコードをソース管理にアーカイブする前に、開発者がコーディングするときに実行する必要があります。継続的インテグレーションサーバー (自動) が使用されている場合は、それによって実行する必要があります。

第 2 層: コンポーネント統合レベルでは、開発者が単体テストを作成しますが、それはコンポーネント間の統合をテストします。目的は、個々のクラスやコンポーネントをテストすることではなく、それらがどのように相互作用するかをテストすることです。これらのテストは、統合エンジニアが手動で実行するか、継続的統合サーバーが使用されている場合は自動化する必要があります。

第 3 段階: アプリケーションレベルでは、QA チームにシステムテストを実行してもらいます。これらのテストケースは、プロダクトマネージャーから提供されたビジネス上の仮定または要件ドキュメントに基づいている必要があります。基本的に、あなたがエンドユーザーであるかのようにテストし、ドキュメントに記載されている要件に従って、エンドユーザーが実行できるはずのことを行います。これらのテストケースは、顧客が何を望んでいて、どのようにアプリケーションを使用することが期待されているかを (おそらく) 知っている QA チームとプロダクトマネージャーによって作成される必要があります。

これでカバー力はかなりあると思います。もちろん、上記の層 1 と 2 は、ビルドされたアプリケーションを QA チームに送信する前に実行するのが理想的です。もちろん、これを自分のビジネスモデルに合わせて調整することはできますが、私の前職ではこれでうまくいきました。誰かがテストを実行するのを忘れて壊れたコードをソースアーカイブにコミットした場合に備えて、ビルド/統合プロセス中にユニットテストの 1 つが失敗した場合も、継続的インテグレーションサーバーは開発チームに電子メールを送信します。

score 2 · Accepted Answer

QAの人にやってもらうのが嫌いなのは、彼らが自分の作品を作るというアイデアが好きではないからです。たとえば、テストするには手間がかかりすぎるものを省略したり、必要な技術的な詳細を知らなかったりする場合があります。

ええ、あなたはあなたのQA部門、またはより良いものにもっと信頼を置く必要があります。つまり、「開発者にソフトウェアを開発してもらうのは好きではありません。彼らが自分の作品を作成するというアイデアは好きではありません」と言っていたと想像してみてください。

開発者として、私は自分のテストを書くことにリスクがあることを知っています。それは私がそうしないと言っているわけではありませんが（特にTDDをしている場合はそうします）、テストカバレッジについての幻想はありません。開発者は、自分のコードが自分たちが思っていることを実行することを示すテストを作成します。手元にある実際のビジネスケースに適用されるテストを作成する人はそれほど多くありません。

テストはスキルであり、QA部門、または少なくともその部門のリーダーがそのスキルに精通していることを願っています。

score 2 · Accepted Answer

「時間の無駄だと思う開発者、または単にやりたくない開発者」そして、それに対して報酬を与えます。彼らにテストケースを作成してもらうには、どのようなソーシャルエンジニアリングが必要ですか?

QA はコードとテストケースに目を通し、「十分なカバレッジがありません -- さらにケースが必要です」と発音できますか。もしそうなら、すぐに「十分な」カバレッジを持つプログラマーがビッグ・カフナになります。

ですから、私の質問は次のとおりです。タスクが完了したら、このタスクに「十分な」テストケースの目標を誰が定義する必要がありますか? 「十分」がわかれば、プログラマーに「十分」を記入する責任を負わせ、QA に「十分」なテストが行われたことを保証する責任を負わせることができます。

「十分」を定義するのは難しいですか？面白い。おそらく、これがそもそもプログラマーとの対立の根本的な原因です。彼らは、すでに「十分」にやったのに、今は「十分」ではないと誰かが言っているので、時間の無駄だと感じるかもしれません。

score 2 · Accepted Answer

QA 担当者は、「顧客」と協力して、各タスクのテストケースを定義する必要があり [ここでは実際に用語を混ぜています]、開発者はそれらを作成する必要があります。最初！

score 1 · Accepted Answer

私の提案は、品質を確保するためにコードをマージする前に、他の誰かにテストケースを調べてもらうことです。これは、開発者が別の開発者の作業を見落としていることを意味している可能性がありますが、2番目の目は最初は捕らえられなかったものを捕らえる可能性があります。最初のテストケースは、テスターではなく、開発者、アナリスト、またはマネージャーが実行できます。

QAは、期待される結果が定義されていない状況である可能性があるため、テストケースを作成するべきではありません。この時点で、QAと開発の間に、それぞれの解釈が正しいと判断した場合、誰かにレフェリーを配置するのは難しいかもしれません。それは私が何度も見たものであり、それがそれほど頻繁に起こらなかったことを望みます。

score 1 · Accepted Answer

（ランダムに選ぶだけでなく）1人か2人のテスターを選択し、テストケースを書いてもらいます。レビュー。タスクを操作する開発者がタスクのテストケースを調べる場合にも役立ちます。テスターにテストセットの改善と追加を提案するように勧めます-時々人々は上司がしたことを修正することを恐れます。このようにして、テスト設計が得意な人を見つけることができます。

テスターに技術的な詳細を知らせてください-アジャイルチームの全員がコードへの読み取りアクセス権と利用可能なドキュメントを持っている必要があると思います。私が知っているほとんどのテスターはコードを読み取る（そして書き込む）ことができるので、単体テストが役立つと思うかもしれませんし、場合によってはそれらを拡張することさえできます。テスト設計者が何かを知る必要がある場合は、開発者から有用な回答を得るようにしてください。

score 1 · Accepted Answer

アジャイルの原則は、(少なくとも) 2 つのテスト層 (開発者テストと顧客テスト) が必要だということです。

開発者テストは、できればテスト駆動開発を使用して、本番コードを作成するのと同じ人によって作成されます。それらは、適切に分離された設計を考え出すのに役立ち、リファクタリングの後でも、コードが開発者が考えていることを確実に実行するようにします。

顧客テストは、顧客または顧客代理人によって指定されます。実際、それらはシステムの仕様であり、実行可能 (完全に自動化された)かつビジネス担当者が理解できるように記述する必要があります。多くの場合、チームは QA 担当者の助けを借りて、顧客がそれらを作成する方法さえ見つけます。これは、機能が開発される間、または開発される前に発生する必要があります。

理想的には、マージの直前に QA が行う唯一のタスクは、ボタンを押してすべての自動テストを実行し、いくつかの追加の探索的 (=スクリプト化されていない) テストを行うことです。マージ後にこれらのテストを再度実行して、変更の統合によって何かが壊れていないことを確認することもできます。

score 1 · Accepted Answer

小規模なチームを除いて、プロジェクトマネージャーがテストケースを作成するのを聞いたり見たりしたことはほとんどありません。大規模で複雑なソフトウェアアプリケーションには、そのアプリケーションをよく知っているアナリストが必要です。私は住宅ローン会社で PM として働いていました。サブプライムローンや金利などを理解する必要がありましたか? 表面的なレベルかもしれませんが、実際の専門家はそれらが機能することを確認する必要がありました. 私の仕事は、チームを健全に保ち、アジャイルの原則を守り、チームのために新しい仕事の機会を探すことでした。

score 1 · Accepted Answer

テストケースは、ストーリーカードの最初に始まります。

テストの目的は、欠陥を左側に移動させることです (ソフトウェア開発プロセスの早い段階で、修正が安価で迅速に行われます)。

各ストーリーカードには、受け入れ基準を含める必要があります。プロダクトオーナーはソリューションアナリストとペアを組んで、各ストーリーの受け入れ基準を定義します。この基準は、ストーリーカードの目的が満たされているかどうかを判断するために使用されます。

ストーリーカードの受け入れ基準により、開発者がテスト駆動開発を行う際に、どの自動単体テストをコーディングする必要があるかが決まります。また、自動化されたテスターによって実装される自動化された機能テストを推進します (FIT などのツールを使用している場合は、おそらく開発者のサポートも必要です)。

同様に重要なことは、受け入れ基準が自動化されたパフォーマンステストを駆動し、開発者によるアプリケーションのプロファイリングを分析するときに使用できることです。

最後に、ユーザー受け入れテストは、ストーリーカードの受け入れ基準によって決定され、ビジネスパートナーやユーザーによって設計される必要があります。このプロセスに従えば、欠陥ゼロでリリースできる可能性があります。

score 1 · Accepted Answer

私は自分のテストを「開発者」テストと「顧客」テストに大まかに分類し、後者は「受け入れテスト」になります。前者は、コードが正しく実行されていることを確認するために開発者が作成するテストです。後者は、動作が仕様と一致することを確認するために、開発者以外の誰かが作成するテストです。開発者は、受け入れテストを書いてはいけません。なぜなら、彼らがテストしているソフトウェアの作成は、彼らが正しいことをしたことを前提としているからです。したがって、彼らの受け入れテストはおそらく、開発者がすでに真実であると知っていたことを主張するでしょう。

受け入れテストは仕様によって駆動される必要があり、開発者によって記述されている場合は、コードによって駆動されるため、望ましい動作ではなく、現在の動作によって駆動されます。

score 0 · Accepted Answer

私たちは、失敗し続けている「これがどのように行われたか、または行われるべきか」という考え方から進化する必要があります。テスト計画/ケース作成の問題を解決する最善の方法は、要件/ユーザーストーリーが書かれているときに、テストケースをウォーターフォールの要件ドキュメントまたはアジャイルのユーザーストーリーに記述することです。このようにして、何をテストする必要があるかは疑問の余地がなく、QA チームと UAT チームはテストケースを実行し、実際のテストと欠陥の解決に時間を集中できます。

score 0 · Accepted Answer

システムアナリストは、すべてのテストケースと、ユースケースとの正しい関係を確認する必要があります。さらに、アナリストは、テストケースに基づく最終的な UAT を実行する必要があります。つまり、アナリストと品質担当者は、ある種の査読を行っています。

品質担当者は、テストケースを作成している間にユースケースをレビューします。アナリストは、テストケースが作成された後、UAT を実行している間にテストケースをレビューします。

testing - アジャイルのような開発では、誰がテストケースを書くべきですか？

16 に答える 16

チーム。

Related

Reference