Monday April 15, 2013
Now that we have discussed Test Driven Development in detail, it is a good idea to explore Behavior Driven Development and Acceptance Test Driven Development methods next. This post will help you understand how are these two development strategies different from TDD and each other.
Behavior Driven Development is a variation of TDD methodology, where in the main focus is on behavioral specifications of the product or application. When BDD is adapted in a project, the technical nitty-gritty aspects of the requirements and implementation are outlined in a business-oriented language.
Acceptance Test Driven Development is a methodology that focuses on the overall collaboration between different stakeholders in a project. It encourages the whole team of developers, QA and business analysts to define the acceptance criteria of an application prior to commencing it’s development.
Though the above definitions provide us with a brief understanding of these methodologies, their differences need more exploration.
While TDD is about writing tests to satisfy system requirements as outlined in the BRD, BDD encourages developers to write tests such that they reflect the behavioral expectations from the system of the stakeholders, and not just the functional aspects. BDD uses Ubiquitous language that can be understood by the developers and stakeholders.
ATDD works on the similar lines with subtle differences. In ATDD, the tests are written together with/by developers, testers and customers. Instead of writing up a test case, here, an executable specification is created that can later be run to test the code.
The tests, and consequently, the code focus on the behavior of a feature thus making customers happy and content.
BDD helps developers concentrate on designing robust solutions.
Technical language is given a rest to pave way for better communication and understanding between various parties involved in a project.
BDD tools such as Cucumber and SpecFlow can be used to generate test scripts from the written test cases.
One can create executable specification in line with the requirement the can be refined and run at a later date.
Testing is moved to the beginning of the cycle thus reducing defects and bug fixing effort as project progresses.
Testers, developers and business analysts can work together to better understand what is required from the system.
The focus is on the ‘What’ and not the ‘How’ thus making it easier to meet customers’ requirements.
These three methodologies are closely related to each other. But neither can replace the other one as each one has its own merits and demerits. But many teams have successfully used a combination of these methodologies to DO IT RIGHT.
One common advantage of such development techniques is the availability of fast feedback to inspire better development and aid in quick release. The overall concept of ‘write-test case-first and then ‘write-code’ gives the development life cycle a stronger foundation and a stable end product.
Download TestingWhiz to Experience these 3 methodologies.