Agile development approach, software testing, business analysis … What is the relation between these notions and the ATDD abbreviation? Here is the answer.
TDD
For sure, before discussing the notion of ATTD, it is worth mentioning the source of this agile development approach, TDD, or Test-Driven Development. Usually, in traditional software quality control, the process of testing looks in the following way. First, you write the code. Then, you test the code. But that’s not the case of Test-Driven Development. In TDD, the procedures are reversed. Puzzled? How can we test something that is to be developed yet? The scheme is simple. First, you write a test that will initially fail. Then, you write some code that will satisfy the minimum need for test to be passed. And after that, you refactor the whole process.
How is ATDD different from TDD?
Acceptance test-driven development (ATDD) is the evolution of the idea of Test-Driven Development. While the TDD approach focuses on the implementation of a feature, ATDD focuses on satisfying the requirements.
These requirements are described in the ready-made scenarios. Scenarios model how the designed feature will be used in the future. If the scenario is implemented and the expected result is obtained in practice, then the problem is solved correctly and the work can be considered complete. A set of such scenarios in quality assurance is called acceptance tests.
The main idea lies in developing the requirements of the conducted work and the requirements for the acceptance of the work. That plays a key role because from the earliest stage of the project discussion you extract the most necessary information on what should be done, how should the processes of software quality assurance be conducted, and what should be considered as the desired result.
Unit and acceptance tests
Unit test gained its name not by coincidence. This kind of tests focuses on testing one small piece of code with just one feature. The main object of the unit test is to affirm that the system’s internal structure works as one would expect. We can compare unit tests with the bricks of the building. If all the bricks are in their place the building will be kept from falling. When you need to change anything in one piece of code you do the refactoring of the code and then, run the test one more time to see it pass.
In turn, acceptance tests are run to check the functionality of the program. Imagine yourself as a property buyer. You don’t know anything about concrete and sand, you just want your house to be appropriate for living. Acceptance tests submit a review of the individual parts working properly together. They are usually black box system tests, written on scenarios specified by the customer. It means that no application details should be included in the tests.
Given-When-Then
This input-output quality control algorithm is performed in the “given-when-then” scenario.
“Given a defined context - When a defined action is performed - Then the system is expected to respond in a defined way”
If there is any information that needs more clarity you should add the “AND” step.
For example:
Scenario: Delete a received e-mail
GIVEN: That there is a message that should be deleted
WHEN: I click on the button “Delete”
THEN: The message is deleted from my box “Received”
AND: Send to the box “Trash”
As you may see, no technical details were mentioned and the focus was made on the user.
Benefits
Summing up all the information, we can list the following advantages:
- ATDD connects multiple teams. It creates an effective collaboration between developers, testers, and business analytics.
- ATDD improves the effectiveness of the process of developing. The idea of ATDD eliminates the ambiguity of requirements.
- ATDD helps the team to share a common understanding of the complete task. It is much easier to set up whether the software is ready if the whole team was engaged in the process of creating the criteria of completeness.