私は、Acceptance TDD と従来の TDD の概念を紹介したマニング TDD の本を調べていました。ここで、両方の概念にかなり精通している人々に尋ねたいと思います。Acceptance TDD テスト ケースの作成者は誰ですか? 開発者、QA 専門家、またはビジネス アナリストのいずれですか。開発者が受け入れテストを書くのに適しているとは思いませんか? 私に賛成してくれますか ？
1 に答える
1
短い答え：
あなたはこれらの2冊の本であなたのすべての答えとより多くを見つけることができるでしょう：
これらの本は、ATDD/BDDの主題に関して多くの時間を節約するでしょう。
長い答え：
理想的には、それらのツリーが受け入れ基準について話し合うために協力することを望みます。
時にはそれは実際には実用的ではないので、最初にBAにすべての明白な/曖昧でない受け入れ基準に取り組むようにさせることができます。
次に、わかりにくいものについては、QA / BA / DEVが連携して、困難な部分について共通の理解に達することができるようにする必要があります。お互いを理解するための最良の方法は、受け入れ基準として役立つ例/具体的なユースケースシナリオを使用することです。このコラボレーションは、BAまたはQAが単独で作業している場合に見逃してしまうものを見つける機会も得られるようにするために行う必要があります。受け入れ基準で重要なことを忘れることがあるので、目標はやり直しを制限することです。
同じ部屋でQA/DEV / BAを立ち上げることは、費用のかかる活動と見なすことができますが、非常に強力な組み合わせです。BAはドメインを非常によく知っており、QAは何が壊れるかを知っており、DEVは通常QAとBAの間にありますが、すべての技術的な実現可能性についても知っています。これらのツリーが連携している場合、見逃された可能性のあるものを見つけたり、複雑なもののあいまいさを取り除いたりすることができます。
一言で言えば、機能が本当に単純な場合は、それを行う必要はなく、BAは自分で作業できます。ただし、複雑な機能が含まれている機能がある場合は、これら3人が協力して、やり直しを制限する必要があります。
何をするにしても、もっと重要なことは、これらの受け入れ基準について、それらのツリーで話し合い、レビューできる瞬間を設けて、誰もが何をする必要があるかを共通に理解できるようにすることです。
于 2012-11-24T00:05:58.320 に答える