User Tools

Site Tools


bridging_the_communication_gap_-_specification_by_example_and_agile_acceptance_testing_-_gojko_adzic

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
bridging_the_communication_gap_-_specification_by_example_and_agile_acceptance_testing_-_gojko_adzic [2016/10/12 13:02] – [Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing - Gojko Adzic.] hpsamiosbridging_the_communication_gap_-_specification_by_example_and_agile_acceptance_testing_-_gojko_adzic [2020/06/10 12:50] (current) – ↷ Links adapted because of a move operation hans
Line 1: Line 1:
 ====== "Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing" - Gojko Adzic ====== ====== "Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing" - Gojko Adzic ======
  
-====== Reference ====== 
- 
-[[http://www.amazon.com/Bridging-Communication-Gap-Specification-Acceptance-ebook/dp/B008YZ993W?ie=UTF8&redirect=true&ref_=docs-os-doi_0|"Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing"]] by Gojko Adzic. 
  
 ====== Review and Notes ====== ====== Review and Notes ======
  
-If you are having troubles collaborating with all stakeholders on user stories, if you find you are not clear on requirements, then the advise in this book will help you get started. This is the book I wish I had when I started down the pathway of using examples and "given-when-them" descriptions in place of conditions of acceptance criteria (see [[blog:how_can_we_improve_collaboration_on_user_stories|How Can We Improve Collaboration on User Stories?]] for more information).+If you are having troubles collaborating with all stakeholders on user stories, if you find you are not clear on requirements, then the advise in this book will help you get started. This is the book I wish I had when I started down the pathway of using examples and "given-when-them" descriptions in place of conditions of acceptance criteria (see [[how_can_we_improve_collaboration_on_user_stories|How Can We Improve Collaboration on User Stories?]] for more information).
  
 One of the ideas that we push with agile development is the idea that we should move away from requirements documents and move to face-to-face communication to ensure that we are all on the same page. When teams start to do this, they often find that there has not been clear communication of requirements or something has been forgotten in the thinking process and so we feel like we are constantly re-visiting work that "if we only had a requirements document" we would have addressed. Another of ideas that really help teams get better in agile is the idea that you don't have a serial workflow in sprints, design - development - testing, but rather try to do more in parallel and in a more focussed way. If you are working either of these issues that this book will introduces you to (thinking) tools that will help. One of the ideas that we push with agile development is the idea that we should move away from requirements documents and move to face-to-face communication to ensure that we are all on the same page. When teams start to do this, they often find that there has not been clear communication of requirements or something has been forgotten in the thinking process and so we feel like we are constantly re-visiting work that "if we only had a requirements document" we would have addressed. Another of ideas that really help teams get better in agile is the idea that you don't have a serial workflow in sprints, design - development - testing, but rather try to do more in parallel and in a more focussed way. If you are working either of these issues that this book will introduces you to (thinking) tools that will help.
Line 40: Line 37:
   * Tester: "You can influence the development process and stop developers from making the same mistakes over and over. You will have a much better understanding of the domain. You’ll delegate a lot of dull work to developers, who will collaborate with you on automating the verifications. You can build in quality from the start by raising concerns about possible problems before the development starts. You’ll be able to verify business rules with a touch of a button. You will have a lot more time for exploratory testing. You will be able to build better relationships with developers and business people and get their respect."   * Tester: "You can influence the development process and stop developers from making the same mistakes over and over. You will have a much better understanding of the domain. You’ll delegate a lot of dull work to developers, who will collaborate with you on automating the verifications. You can build in quality from the start by raising concerns about possible problems before the development starts. You’ll be able to verify business rules with a touch of a button. You will have a lot more time for exploratory testing. You will be able to build better relationships with developers and business people and get their respect."
  
 +====== Want to Know More? ======
 +
 +  * [[http://www.amazon.com/Bridging-Communication-Gap-Specification-Acceptance-ebook/dp/B008YZ993W?ie=UTF8&redirect=true&ref_=docs-os-doi_0|"Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing"]] by Gojko Adzic.
  
-{{tag>Book Learning Improvement AcceptanceCriteria ConditionsOfSatisfaction Review}}+{{tag>Book Learning Improvement AcceptanceCriteria ConditionsOfSatisfaction Review BDD ATDD}}
  
  
-~~LINKBACK~~ 
-~~DISCUSSION~~ 
/home/hpsamios/hanssamios.com/dokuwiki/data/attic/bridging_the_communication_gap_-_specification_by_example_and_agile_acceptance_testing_-_gojko_adzic.1476302541.txt.gz · Last modified: 2020/06/02 14:22 (external edit)