- Taschenbuch: 284 Seiten
- Verlag: Neuri Limited (5. Januar 2009)
- Sprache: Englisch
- ISBN-10: 0955683610
- ISBN-13: 978-0955683619
- Größe und/oder Gewicht: 15,2 x 1,5 x 22,9 cm
- Durchschnittliche Kundenbewertung: 4 Kundenrezensionen
- Amazon Bestseller-Rang: Nr. 125.790 in Fremdsprachige Bücher (Siehe Top 100 in Fremdsprachige Bücher)
Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing (Englisch) Taschenbuch – 5. Januar 2009
|Neu ab||Gebraucht ab|
Wird oft zusammen gekauft
Kunden, die diesen Artikel gekauft haben, kauften auch
Es wird kein Kindle Gerät benötigt. Laden Sie eine der kostenlosen Kindle Apps herunter und beginnen Sie, Kindle-Bücher auf Ihrem Smartphone, Tablet und Computer zu lesen.
Geben Sie Ihre Mobiltelefonnummer ein, um die kostenfreie App zu beziehen.
Über den Autor und weitere Mitwirkende
Gojko Adzic was bitten by the specification-by-example bug five years ago. He has helped numerous teams implement these practices, written two previous books on the subject and contributed to several open source projects supporting specification by example. Gojko is a frequent speaker at leading software development and testing conferences and runs the UK Agile Testing User Group.
Welche anderen Artikel kaufen Kunden, nachdem sie diesen Artikel angesehen haben?
In Bridging The Communication Gap Gojko discusses topics about requirements, Agile acceptance testing (ATDD), user stories as well as tools for specification by example. He gives a compelling overview into each parts. For the requirements part, specification workshops alongside with requirements by example build the basis for measurable and executable requirements. Gojko gives an overview on the Agile Acceptance Test cycle, and explains where it fits into the Agile development cycle. As user stories are the standard way to introduce new features in Agile projects, he also discusses their role in the ATDD cycle. On the tools in use today, he shows the most commonly used (as by 2008/2009) - FIT, FitNesse, Concordion, TextTest, JBehave and Selenium - and where the development of the tools from tomorrow are most likely to go. Last he takes a closer look on impacts of his approach on different roles in the software cycle - customers, developers, testers and business analysts.
This book is a must read for anyone struggling with requirements and acceptance testing. It shows how to a working approach, which Gojko applied several times on his consulting job. He wrote this book based upon his compelling experience helping organizations and teams with test automation and Agile testing.
Contains Background and examples.
The practices are described in a way that they can be applied in daily routine.
Die hilfreichsten Kundenrezensionen auf Amazon.com (beta)
What is it? Agile Acceptance Testing is a technique for closing the communication gap between business, developers and testers. A way to write specifications as examples which become executable. The specification are created together in a workshop and not handed over like traditional requirements.
The book is written in four parts. The first part is an introduction to the topic, describes an overview of the technique. An important part of this part (and the whole book) is the focus on communication instead of test. This is reflected in the excellent discussion about naming. Agile Acceptance Testing is perhaps one of the most poorly named practices, but... still... thats the name it became popular with (or with A-TDD). The second part is the most important parts of the book, which describes how to write specifications, why to work with examples, how to run specification workshops and what to do after these workshops. The part ends with a discussion about change in projects and how the automated acceptance test help with that.
The third part discusses implementation. It starts with how to fit this technique in an iteration and how to adopt the practice. Next is a chapter on user stories and its relationship with acceptance tests. Then the part dives in the tools by first covering the current tools and then discussing the requirements for the future tools. The last part of the book describes the impact of agile acceptance testing on the different functions: business analyst, developer and tester.
Bridging the Communication Gap is a small book (300 pages) and is easy to read. It could have been smaller, the writing is sometimes a little too wordy. It doesn't contain too much pictures, which is too bad when a book talks so much about workshops. Yet, despite these drawbacks, I think this is an excellent book and a much needed contribution to the modern software development/agile development literature. It was one of the few practices that did not have its own book yet and Gojko provided that.
I was doubting between 4 and 5 stars for this review. 4 because this book is certainly not perfect. 5 stars because it is good still. Because this is a first in a new area and because I consider this an important area, I decided to go for 5 stars. This will certainly be a book that I will be recommending to other people (and in fact, I already have). Great work Gojko!
This book not only explains how to use examples to understand requirements and create tests that drive coding, it explains the cultural shift needed for successful software development. The author explains the communication gap, why we should care about it, and how we can fix it.
Whether you're new to agile development, or are on an experienced team wondering why you keep missing or misunderstanding the business requirements, this book delivers critical value.
Thet second big lesson that the book describes is how specifications can me made more clear by working together as a team and saving lots of time when we store the specifications in testing tools in a format that customers can read and understand.
Personally I find the style of writing rather dry so pushing ahead through the material takes some commitment, but it is worth it. The lessons, techniques and value of the results provide an excellent payoff.