Extended Role of QA in Test-Driven Development (TDD)
TDD is an Agile Development technique in which developers write test cases before writing the corresponding code for the user story assigned to him. Once the code passes the Acceptance test, the code is then refactored /simplified to be used as production code. TDD focuses on writing the necessary code to pass the test thus making the process simple and clear.
What is the primary goal of Test Driven Development (TDD)?
The primary goal of TDD is to enable developers to think through the requirements like a QA does before they start writing functional code and create Unit test cases to be executed on Development Environment.
How TDD is different than others?
In normal development phase, developers write code and then unit testing is performed. If any errors are observed, they are fixed by the developer. This cycle continues until the code is released to QA.
Whereas in TDD, developers write test cases first rather than the code. The test is then run even if there no code for it to make it fail intentionally. Thereafter, the developer starts creating classes, add functionalities, and so on to make sure the test passes this time. This cycle is then repeated for another new functionality.
Steps involved in a TDD cycle:
1. Adding a new test:
Add a test case even though the code is not implemented. This helps the developer in clear understanding of the requirement before writing the actual program code
2. Execute the tests and make sure that the code fails:
If the new test fails which it should as the test case was executed without any code being written, then we are sure the test environment and test case is working fine
3. Write code:
The next step is to write code such that the test passes. The new code is now updated as per the requirements
4. Run automated tests:
If every test case passes, it implies that the code meets all required specifications by the client
5. Refactor code:
Refactoring helps in removing duplication between production and test codes without doing any damage to existing functionality
The complete cycle is then repeated as per the above steps with a new test
Limitations of TDD
- The amount of time taken by the Developer to get used to TDD approach is huge initially
- TDD takes up lot of time to refactor the code, write new test, and so on for every small bug fix
- TDD is difficult to implement in Maintenance projects where the type of work are micro bug fixes, small enhancements, and so on
- TDD is also difficult to implement when the requirements are not clear initially but does gets cleared up gradually. In this case it becomes increasingly difficult for developers & QA alike to derive test cases with correct expected results
Role of QA - in a TDD Environment
As it can be seen, in TDD approach both developers and QA use test cases to develop their code and execute test cases respectively. So it can be concluded that the major dependency is on test cases. So writing test cases that have good coverage of requirements is important for making TDD successful. It’s known that QAs know the overall system much better than a developer as they test the system End-to-End. Therefore it is required to involve the QA team in every phase of TDD and that too from the very beginning. QA should work together with the developer to make sure that unit testing is built into the core of the application.
Acceptance Test Driven Development (ATDD):
In the planning phase, QA will enquire customers about the acceptance criteria of each functionality. Then the QA will work together with developers to create test cases. Developers working with QA help in designing better test cases. However QA can set up the acceptance tests upfront, that are at higher level than Unit tests and thus realizing Acceptance Test Driven Development (ATDD).
ATDD helps developers in deriving Unit tests based on requirements captured as part of acceptance tests.
Developers would be using TDD to test at lower level i.e. individual units. Developers will be concerned with the functional implementation whereas QA would be concerned about the overall implementation where individual units are integrated to form the complete system. Finally QA team should be the final judge of whether or not your product meets the quality standards set by the client and your organization.
Advantages of TDD compared to traditional approach for Developers
- Better understanding of the requirements by the Developers which in turn will help them in developing the product as per the requirements & relatively bug free. This will in turn help QA to save time on finding requirement related defects
- When a new functionality is added /modified there is a high chance of a new bug being introduced or existing functionalities getting affected. But with TDD, developers can run all the tests and they will find immediately whether the change has failed or affected some other tests. Hence regression related bugs are easily identified in Unit testing phase itself rather than getting passed on to QA Environment
- Unit tests are kind of documentation to the application under test. Each unit test tells about an individual requirement to the system. The unit tests can be used as alternative documentation for the system by QA also
- When TDD is implemented, testing phase is likely to see less unit/regression bugs and thus QA can focus more on exploratory/Adhoc testing to uncover probable real time issues
Extended Role of QA in AGILE
Firstly, one needs to understand that TDD is not a QA method, it is a development approach.
- TDD is moreover meant to restrict itself to unit testing only
- Having a separate team of developers and testers has benefits of increased specialization or when any product is needed to be tested on multiple hardware/software platforms independently
- QA is involved in Agile all the way through and it’s an integral part of any team designing the test cases when the requirements are still evolving
- An independent testing team serves as an objective third-party and they are able to see "the AUT in complete end-to-end sense". The testing team helps in validating the functionality while also keeping in terms the quality of the product. While the tendency of a developer’s is to prove that the AUT functions as required, a good test engineer will always ask "what happens if...?"