エッジケースの承認基準

私はアジャイルチームのプロダクトオーナーです。私はPO受け入れテストを行うとき、通常いくつかのエッジケースを試すことを書き留めます。私が何かを発見するのは珍しいことではなく、それを開発者に渡します。開発者の話を拒否すると、開発者の1人から反発を受けます。彼は私がストーリーで説明するものだけをコード化する傾向があるため、エッジケースとプログラムが許容基準でどのように応答する必要があるかを指定しないので、彼は不公平だと言います。コーディング中にエッジケースにぶつかったときに私に尋ねるように彼に勧めましたが、彼はエッジケースをじっくり考えるのは自分の仕事ではないと考えており、次のスプリントのために新しいストーリーを作成する必要があります。

私の弁護では、彼がストーリーを実装するまで彼のストーリーのデザインがわからないので、すべての可能性を繰り返すことは困難です（構成はDBまたはプロパティファイルにありますか？）。簡単にするために、電卓アプリに除算を追加するストーリーがあるとします。理想的なSCRUMの世界では、「ゼロによるハンドル除算シナリオ」を受け入れ基準に追加するのは私に任されているのでしょうか、それともアプリが5/0に爆破しないように開発中にそれらのケースを処理する必要がありますか？明確に言うと、この場合、アプリが5/0で激しくクラッシュした場合は受け入れませんが、ログに記録したり、DIV0を出力したり、その他の方法でエラーを処理したりすれば合格します。クラッシュしない。

答えは、両方ともあなた自身の一連のエッジケースについて考えるべきだと思います。開発者は、特定のユーザー入力からアプリがクラッシュするなど、データ固有のエッジケースを処理する必要があるため、5/0は確実にこの部分に該当します。開発者は、ユーザーの操作の一部として与えられた入力が無効なものにつながる場合、適切なエラーメッセージであると考えるものについて尋ねます。

スペクトルのあなたの部分は物事のビジネス面です。ユーザーのアカウントで除算ボタンの使用が許可されていない場合、電卓はどのように動作しますか？アカウントでMod操作の使用が許可されているが、除算機能にアクセスできない場合、どのように動作しますか？

あなたが伝え、そしてすべてのチームメンバーから受け入れられる必要があると私が思う重要なメッセージは、あなたがすべて同じチームにいるということです。製品が完成していない場合、製品は完成しておらず、チームの責任であり、特定のメンバーではありません。

チームは、「自分の仕事ではなく、自分の責任ではない」タイプの態度/マントラではなく、協力して取り組む必要があります。

合格基準は次の形式で提供されます。

• 事業受入
• 品質保証の受け入れ

通常、ビジネスの受け入れは通常、次の質問に答えます。

• 実装された機能は、私がやりたいことをしますか？

この機能には、ビジネス指向の多くの要件があります。たとえば、このボタンを押すと、このアクションが発生すると予想されます。予想されるビジネスシナリオと予想される動作を一覧表示しますが、すべての可能なケースをカバーするわけではありません。

品質保証がビジネス以外の要件に関する技術を開発できるように、反復の前にビジネス要件を定義する必要があることが予想されます。品質保証では、破壊的なケースだけでなく、必要に応じてエッジケースも開発する必要があります。

ストーリーの作業を開始する前に両方の要件のセットを確認して、作業単位に対して正式な見積もりとコミットメントが発生するようにする必要があります。これが完了すると、機能/ストーリーを処理できます。この時点で、ビジネスと技術の両方の観点から何が提供されるかについて誰もが明確にしています。

ビジネスと品質保証チームのメンバーがストーリーを承認すると、ストーリーは最終的に承認されます。これは、ビジネス承認と品質保証承認の両方の反復中に発生するはずです。これは、追加のストーリー作業を開始できることを示す完了（DoD）の定義です。

新しい発見事項は、欠陥または追加のストーリースパイクとして記録される場合があります。完璧な世界では、これは決して起こりませんが、実際には、通常、機能/ストーリーの作業中に発生するある程度の「発見」があります。これは自然なことです。

チームは協力すべき要件のいずれかの漠然とした発見型のうち、ハッシュへ（ビジネス、QA、開発者）。これがアジャイルである場合、コミュニケーションを促進し、発生する可能性のある質問への迅速な解決を促進するために、全員が同じテーブルに座っている必要があります。次のようになります。

QA：

「開発者、この特定のシナリオを処理する必要があります。このデータを入力するとエラーが発生することを発見しました。」

DEV：

「それはどの要件でもカバーされていませんが、これをカバーするためにいくつかの追加機能を追加できます。OK、ビジネスパーソン、この場合のアプリケーションの動作はどのようにしますか？」

ビジネス：

「標準のエラーメッセージを表示して、このシナリオでユーザーに再試行させましょう。その場合、さらにどのくらいの労力が必要になりますか？」

DEV：

「それは簡単です。あと1、2時間だけです。この反復のためにコミットできます。QAこのシナリオの承認基準を更新してください。追加のストーリーは必要ありません。ありがとう！」

または、作業量が多い場合は、新しいストーリーがバックログに追加されます。チームは、元の要件をすべて満たしているため、元のストーリーを受け入れ、次のイテレーションでスパイクストーリーを取り上げることができます。

不正確またはあいまいな入力に直面しても堅牢な動作をするソフトウェアを作成することは、ソフトウェア開発者の仕事の重要な部分です。

開発者がそれをそのように見ない場合は、この仕様を明示する要件仕様に追加の非機能要件を含め、開発者にテストプロセスの例を提供して、最終的に提出する前にそのプロセスを適用できるようにします。レビュー用のコード。

いずれにしても、受け入れテストは、要件ドキュメントの重要な部分です。要件に受け入れ基準も記載されていない場合、それは実際には要件ではありません。それは願いです。

ここで起こったことは、あなたが価値を発見したということです。入力値は、ストーリー（および受け入れ基準）がいつ記述されたか、またはコードがいつ記述されたかは考慮されませんでした。それが許容基準の一部ではない場合、そのストーリーを拒否する根拠は実際にはありません。

私たちのチームで行うことは次のとおりです。

1. 予想される動作と実際の動作を詳しく説明するバグを作成します。
2. 新たに見つかった要件が文書化されるように、受け入れ基準を更新します。
3. 次のイテレーションでは、他のすべてのストーリーとバグとともにバグに優先順位を付けます。

ここでの利点は、このバグの修正が次に重要なことであるかどうかを検討しなければならないことです。修正するのに十分なほど重要ではない場合もありますが、その値を考慮することが重要です。

もちろん、開発者（および自分自身）がこれらのエッジケースを前もって検討するように促す方法を見つける必要があります。開発チームがストーリーの分析に時間を費やしていない場合は、開発チームが作業を開始する前に詳細な計画セッションを行うように勧めます。

いくつかの観察：

...彼の話を拒否したとき

私はあなたの仕事の文化やプロセスを知りませんが、私にとって物語を拒否することは深刻な一歩です。私が開発者である場合、それは私とチームに悪影響を与える記録されたアクションであるため、それに対するプッシュバックも生成します。

私はエッジケースを指定していないので、彼は不公平だと言っています。

あなたがすべてのエッジケースを知っていることを期待することは彼の不公平です。しかし、同時に、彼にそれを期待するのは不公平です。すべての変更にはリスクがあり、問題が発見されると、全員がチームとして協力してそれらに対処する必要があります。

彼がそれを実装するまで、私はストーリーの彼のデザインを知りません

デザインを知っている必要はありません。どのストーリーがバックログ管理にとってより簡単またはより困難であるかについて、最初の知識に基づいた推測を行うために、設計を知ることは役に立ちます。ただし、ストーリーを作成するときに、開発者をデザインに閉じ込めないでください。POの音声起動キーボードだけの場合、それはすべての楽しみを吸収します。

皆さんはプロセス改善に取り組み、チーム構築を行う必要があるようです。私がプロセスのために提案するかもしれないいくつかのこと：

• カバーされたエッジケースを修正するために、開発者がストーリーに時間を含めることを提案します。一体、それを各ユーザーストーリーの一部にします。これは、新しいバグを0件導入することを目標として簡単に防御できます。問題は、開発者が現在それを計画していないことです。そして、あなたが問題を発見したとき、彼は時間切れです。どちらにしても時間がかかるので、計画中に見えるようにストーリーに入れてください。
• テストが終わったら（ところでテストしてくれてありがとう！）、発見された問題のリストを開発者に送信します。これらの問題の修正は、「エッジケースの修正」という満足の条件に反します。
• 修正されていないものや発見が遅すぎる場合は、ユースケースを実行できるかどうかに基づいて、ストーリーをプッシュする必要があるかどうかを判断します。既知の問題と回避策が発生します。それらをリリースノートで開示し、修正するための新しいストーリーを作成しました。
• プロセスにプッシュバックを生成する特定の荒い部分がある場合は、プロセスを変更してください！結局のところ、プロセスの改善はスクラムの一部です。たとえば、ストーリーを却下したときに開発者が動揺した場合は、却下によって修正がトリガーされないようにプロセスの変更をチームに提案します。完了して拒否される前にテストと修正を行います。
• チームと協力して、チームが生み出したものを活用し、それを最大限に活用します。彼らは完璧な仕事をしませんし、あなたもしません。したがって、そのための計画を立てます。私のチームは通常、精力的に取り組んできました。そのため、計画されていないサポートのユーザーストーリーがあり、緊急の問題が発生するたびにスプリントします。

要件は明確かつ簡潔でなければなりません。そうでない場合は、あなたに起こったこととまったく同じです。それはあなたの責任であり、要件を指定するときにあなたができる最悪のことは、物事を仮定することです。

ゼロによる除算についての具体的な例。エラーをログに記録するように指定しなかった場合でも、開発者が結果として100を出力しても問題ありません。

しかし、そのような場合、欠けているギャップを埋めて開発者に渡します。結局のところ、要件のバグが発生します。