アジャイルプロジェクトは簡略化された欠陥レポートを使用しますか？
私はこのような比較的厳格な欠陥報告に慣れています。
Steps to reproduce:
1. Access customer manager for user Test01
2. Check "User must change password" and click Apply
3. Access login page
4. Enter user name and password
5. Click Login
Expected results:
6. Site displays user profile page (see use case 21.1.2)
Actual results:
6. Site displays error page (see attached screen shot)
私は最近、欠陥レポートが次のようになるアジャイルプロジェクトに参加しました。
Can't sign on with user Test01, see screenshots
私の長年の開発経験では、より長い欠陥レポートが多くの目的に役立つことがわかりました。正確な問題を簡潔に伝え、いかなる判断の言葉も避け、QAエンジニアが間違っていると思われる動作の欠陥を補うのではなく、必要な動作からの逸脱として欠陥を明確に表します。
アジャイル方法論は、ドキュメントの重要性を強調しません。代わりに、電話を取り、お互いに話すことをお勧めします。
これはアジャイル原則の有効なアプリケーションですか？それとも、アジャイルを目指している場合でも、欠陥レポートはかなり冗長にする必要がありますか？
単純な怠惰のために人々が頻繁にお互いを妨害することを奨励することがアジャイルと見なされる場合、私はアジャイルの私の理解が深刻に壊れていることを認めなければなりません。
十分な問題の説明は、（潜在的に不要な）製品ドキュメントではなく、問題を再現して解決するために必要なすべての事実の明確なコレクションです効率的に。
どんな形式の説明でも十分であれば、問題ありません。そうでない場合は、「再現できません。新しい情報が利用可能になった場合は再度開きます」として閉じます。ただし、1つの例外があります。調査が必要だと感じた場合この問題によって明らかになる潜在的なリスクがあるため、弾丸を噛んでフォローアップすることを検討してください。 （たとえば）不十分な説明のためにセキュリティ問題が修正されずに残されたくない場合。
「アジャイル」とは、ルールやプロセスがないことを意味するのではなく、できるだけ少ない労力でやり遂げる必要があるということです（ただし、アインシュタインの見積もりを言い換えると）。アジャイルマニフェストは、これを「プロセスとツールを介した個人と相互作用」と表現しています。
あなたの場合、それはあなたがあなたの同僚とこれについて話し合うべきであることを意味します。より構造化されたバグレポートを作成することで得られるメリットを説明し、誰もが作業できるソリューションを見つけてください。
おそらく、同僚の中には、より構造化されたレポートを必要としない正当な理由があるかもしれません（たとえば、バグを報告したいユーザーを怖がらせない、または構造がまったく意味をなさないことがわかったため）-または、単に考えたことがないかもしれませんそれ。あなたは尋ねるだけでわかるでしょう:-)。
ユーザーからのバグレポートは常にこのテンプレートに従っているようです：
できません{ここでのアクション}私が{ここでの別のアクション}
または
私が{action here}が機能しない場合
それについてできることはあまりありません。ただし、開発方法に関係なく、QAテスターからこれらの種類のバグレポートを取得することは絶対に受け入れられません。 QAがその小さな情報を使ってバグレポートを送信すると、私はそれをキックバックして、何がうまくいかなかったのか、何が起こっているのかを再現して明確に述べる手順を教えてくれます。
QAが上記のいずれかの形式でのみバグレポートを提供できる場合、QAテスターは開発者の助けを借りて問題がある場合、またはテスターがプロジェクトに不慣れでビジネスルールに精通していない場合。これは許容されますが、テスターからのデューデリジェンスが終了するまではありません。
より詳細なバグレポートを提供するようにユーザーに働きかけることができますが、おそらくほとんど情報を得られないことを知っています。その場合は、QAにバグを調べて再現できるかどうかを確認するか、クライアントに連絡してウォークスルーを設定してもらいます。
アジャイルは厳格なルールのセットではなく、プロセス改善の考え方です。デイブ・トーマスが有名に指摘しているように、アジャイルは形容詞であり、名詞ではありません。定義上、アジャイルを行うことはできません。アジャイルになることしかできません。
したがって、アジャイルチームがバグレポートを処理する方法は、機能するソフトウェアの提供に役立つチームが発見した最も効果的な方法に基づいている必要があります。これは、チームが作業するコンテキストによって、チームごとに異なる場合があります。使用しているプロセスが機能しない場合は、変更してください。それがより良い方法を見つけたら、それを変更してください。 （変更できない場合は、アジャイルではありません）
やるべきことは、なぜそれがそのようになっているのかを知ることです。ここでの他の回答は、可能な説明を提案しています。技術リーダーまたはチームリードと話し合い、彼らが現在のプロセスにどのように取り組んだかを尋ねます。プロセスを改善する方法について提案します。
アジャイルには、バグレポートを短縮する必要があるというルールはありません。バグレポートの種類は、チームまたは組織に最適なものによって制御されます。省略されたレポートがすべての人に役立つ場合、それはアジャイルです。複雑なバグレポートが最適に機能する場合、それもアジャイルです。
アジャイルは、チーム外の誰かによって確立された特定の一連のルールに固執することを強いられることなく、チームが最も生産的になるためのあらゆることを行う力をチームに与えています。
どちらの例も完全にアジャイルである可能性があります。それはすべて、あなたのニーズ、あなたの人々、そして開発サイクルの現在の段階に依存します。一般に、QAチームがスクリーンキャプチャと記録をサポートツールとして使用して、バグレポートを補完するのを見てきました。どうして？ QAの担当者によると、優れた画面キャプチャと記録を取得することは、入力するだけでは簡単ではありません。また、コマンドラインで構成を変更するなど、画面キャプチャとして表示される可能性が低いいくつかの手順があります。開発者はあなたがそれをタイプしたことを気に入るはずなので、彼らはただそれをc＆pすることができます。スクリーンキャプチャのみを添付した場合、彼らはあなたを憎むでしょう:)