エッジケースの承認基準
私はアジャイルチームのプロダクトオーナーです。私はPO受け入れテストを行うとき、通常、いくつかのEdgeケースを試すことを書き留めます。私が何かを発見するのは珍しいことではなく、それを開発者に返します。彼の話を拒否すると、開発者の1人からプッシュバックを受け取ります。彼は私がEdgeケースを指定しておらず、プログラムが許容基準でどのように応答する必要があるかについては不公平だと語っています。私は彼にコーディング中にEdgeケースにぶつかったときに私に尋ねるように勧めましたが、彼はEdgeケースをじっくり考えるのは自分の仕事ではないと考えており、次のスプリントのために新しいストーリーを作成する必要があります。
私の弁護では、彼がストーリーを実装するまで彼のストーリーのデザインがわからないので、すべての可能性を繰り返すことは困難です（構成はDBまたはプロパティファイルにありますか？）。簡単にするために、電卓アプリに除算を追加するストーリーがあるとします。理想的なSCRUMの世界では、「ゼロによる除算のシナリオ」を受け入れ基準に追加するのは私に任されているのでしょうか、それともアプリが5/0で爆破しないように開発中にケースを処理する必要がありますか？明確に言うと、この場合、アプリが5/0で激しくクラッシュした場合は受け入れませんが、ログに記録したり、DIV0を出力したり、エラーを処理するための他の方法を実行したりすると、合格します。クラッシュしない。
答えは、両方ともあなた自身の一連のEdgeケースについて考えるべきだと思います。開発者は、特定のユーザー入力からアプリがクラッシュするなどのデータ固有のEdgeケースを開発者が処理する必要があるため、5/0は確実にこの部分に該当します。開発者は、ユーザーの操作の一部として指定された入力が無効なものにつながる場合に、適切なエラーメッセージになると考えるものについて尋ねます。
スペクトルの部分は、ビジネスの側面です。ユーザーのアカウントで除算ボタンの使用が許可されていない場合、電卓はどのように動作しますか？アカウントでMod操作の使用が許可されているが、除算機能にアクセスできない場合、どのように動作しますか？
すべてのチームメンバーから伝え、受け入れてもらう必要があると私が考える重要なメッセージは、すべて同じチームに所属しているということです。製品が完成していない場合、製品は完成していないであり、チームの責任であり、特定のメンバーではありません。
チームは、「私の仕事ではなく、私の責任ではない」タイプの態度/マントラではなく、一緒に取り組む必要があります。
合格基準は次の形式で提供されます。
- 事業受入
- 品質保証の受け入れ
通常、ビジネスの受け入れは通常、次の質問に答えます。
- 実装された機能は私がやりたいことをしますか？
この機能には、ビジネス指向の多くの要件があります。たとえば、このボタンを押すと、このアクションが発生すると予想されます。予想されるビジネスシナリオと予想される動作を一覧表示しますが、すべての可能性のあるケースについては取り上げません。
品質保証がビジネス以外の要件に関する技術を開発できるように、反復の前にビジネス要件を定義する必要があることが予想されます。品質保証は、破壊的なケースだけでなく、必要に応じてEdgeケースも開発する必要があります。
ストーリーの作業を開始する前に両方の要件のセットを確認して、作業単位に対して正式な見積もりとコミットメントが発生するようにする必要があります。これが完了すると、機能/ストーリーを処理できます。この時点で、誰もがビジネスと技術の両方の観点から何が提供されるかについて明確です。
ビジネスおよび品質保証チームのメンバーがストーリーを承認すると、ストーリーは最終的に承認されます。これは、ビジネス受け入れと品質保証受け入れの両方の反復中に発生します。これは、追加のストーリー作業を開始できることを示す完了（DoD）の定義です。
新しい発見事項はすべて、欠陥または追加のスパイクとして記録される場合があります。完璧な世界ではこれは決して起こりませんが、実際には通常、機能/ストーリーの作業中に発生するある程度の「発見」があります。これは自然なことです。
チームは協力する必要があります（ビジネス、QA、開発者）は、曖昧な発見タイプの要件をハッシュ化します。これが俊敏である場合は、全員が同じテーブルに座って、発生する可能性のある質問に対するコミュニケーションと迅速な解決を促進する必要があります。次のようになります。
QA：
「開発者、この特定のシナリオを処理する必要があります。このデータを入力するとエラーが発生することを発見しました。」
DEV：
「それはどの要件でもカバーされませんでしたが、これをカバーするためにいくつかの追加機能を追加できます。OK、ちょっとビジネスパーソン、この場合のアプリケーションの動作はどのようにしますか？」
ビジネス：
「標準のエラーメッセージを表示して、このシナリオでユーザーに再試行させましょう。その場合、さらにどのくらいの労力が必要になりますか？」
DEV：
「それは簡単です。あと1、2時間だけです。この反復のためにコミットできます。QAこのシナリオの承認基準を更新してください。これについて追加のストーリーは必要ありません。ありがとう！」
または、作業量が多い場合は、新しいストーリーがバックログに追加されます。チームは元の要件をすべて満たしているため、元のストーリーを受け入れ、次の反復でスパイクストーリーを取得できます。
不正確またはあいまいな入力に直面しても堅牢な動作をするソフトウェアを作成することは、ソフトウェア開発者の仕事の重要な部分です。
開発者がそれをそのように見ない場合は、この要件を明示的に示す追加の非機能要件を要件仕様に含め、開発者にテストプロセスの例を提供して、最終的に提出する前にそのプロセスを適用できるようにします。レビュー用のコード。
いずれにしても、受け入れテストは、要件ドキュメントの重要な部分です。要件に受け入れ基準も記載されていない場合、それは実際には要件ではありません。それは願いです。
ここで起こったことは、あなたが発見された値をしたということです。入力値は、ストーリー（および受け入れ基準）がいつ記述されたか、またはコードがいつ記述されたかは考慮されませんでした。それが許容基準の一部ではない場合は、ストーリーを拒否する根拠はありません。
私たちのチームで行うことは次のとおりです。
- 予想される動作と実際の動作を詳しく説明するバグを作成します。
- 新たに見つかった要件が文書化されるように、受け入れ基準を更新します。
- 次のイテレーションでは、他のすべてのストーリーおよびバグとともにバグに優先順位を付けます。
ここでの利点は、このバグを修正することが次に重要なことであるかどうかを検討しなければならないことです。修正するのに十分なほど重要ではない場合もありますが、その値を考慮することが重要です。
もちろん、開発者（および自分自身）がこれらのEdgeケースを前もって検討するように促す方法を見つける必要があります。開発チームがストーリーの分析に時間を費やしていない場合は、開発チームが作業を始める前に詳細な計画セッションを行うように勧めます。
いくつかの観察：
...彼の話を拒否したとき
私はあなたの仕事の文化やプロセスを知りませんが、私にとって物語を拒否することは深刻な一歩です。私が開発者である場合は、プッシュバックを生成します。これは、私とチームに悪影響を与える記録されたアクションであるためです。
私はEdgeケースを指定していないので、彼は不公平だと言います。
Edgeのすべてのケースを知っていると期待するのは不公平です。しかし、同時に、彼にそれを期待するのは不公平です。すべての変更にはリスクがあり、問題が発見されると、全員がチームとして協力してそれらに対処する必要があります。
彼がそれを実装するまで、私は物語の彼のデザインを知りません
デザインを知っている必要はありません。どのストーリーがバックログ管理にとってより簡単またはより困難であるかについて、最初の知識に基づいた推測を行うために、設計を知ることは役に立ちます。ただし、ストーリーを作成するときに、開発者をデザインに閉じ込めないでください。 POの音声起動キーボードだけの場合、それはすべての楽しみを吸収します。
皆さんはプロセス改善に取り組み、チーム構築を行う必要があるようです。私がプロセスのために提案するかもしれないいくつかのこと：
- 開発者に、発見されたEdgeケースを修正するカバーまでの時間をストーリーに含めることを提案します。一体、それを各ユーザーストーリーの一部にしてください。これは、新しいバグを0件導入することを目標として簡単に防御できます。問題は、開発者が現在それを計画していないことです。そして、あなたが問題を発見したとき、彼は時間切れです。どちらにしても時間がかかるので、計画中に見えるようにストーリーに入れてください。
- テストが終わったら（ところでテストしてくれてありがとう！）、発見された問題のリストを開発者に送信します。これらの問題の修正は、「エッジケースの修正」の満足条件に反します。
- 修正されていないものや発見が遅すぎる場合は、ユースケースを実行できるかどうかに基づいて、ストーリーをプッシュする必要があるかどうかを判断します。既知の問題と回避策が発生します。それらをリリースノートで公開し、新しいストーリーを作成して修正します。
- プロセスでプッシュバックを生成する特定の荒い部分がある場合は、プロセスを変更してください！結局のところ、プロセスの改善はスクラムの一部です。たとえば、ストーリーを拒否したときに開発者が動揺した場合は、拒否によって修正がトリガーされないように、プロセスの変更をチームに提案します。完了して拒否される前にテストと修正を行います。
- チームと協力して、チームが生み出したものを活用し、それを最大限に活用します。彼らは完璧な仕事をしませんし、あなたもしません。したがって、そのための計画を立てます。私のチームは通常、精力的に取り組んできました。そのため、計画されていないサポートのユーザーストーリーがあり、緊急の問題が発生するたびにスプリントします。