What is T3D (Test and Defect Driven Development)?

We are living in that time of the world where there are so many product development methodologies:

1. Agile (Scrum, TDD, BDD, XP etc.)

2. Waterfall model

3. V-Model (an extension of Waterfall)

4. Iterative model and several others.

But with the advent of agile methodologies QA’s role has gone through a drastic change. Once a major force in the overall development process now mere an executioner with Dev, IT and Business faction of an enterprise sharing credits among themselves.

What we need is a methodology that satisfies:

• Ego of all the groups within an organization to create harmony among employees leading to the creation of a harmonized quality product.

• Makes feel everyone in the team valuable.

• Doesn’t affect the existing methodologies much thus making the transition easier and smooth.

And here is your answer, Test & Defect Driven Development. Please note that you might find some read on DDD on the internet but that’s not what I am going to talk about in this article. Might sound like Test Driven Development (TDD) but it’s not, which you will eventually realize after reading the complete article.

To explain DDD I will walk you through the steps as to what development process would like in both agile and non-agile paradigms.

1. Requirements or user stories will be baselined and frozen after planning sessions.

2. Instead of writing code first, QA would write test cases and will get them reviewed by the leads, BA or the Product owner.

3. The developers in the meantime can complete all the SCM related stuff, and start writing unit tests (TDD).

4. After review, the testers would baseline the test cases and mark them as ‘Failed’ in their test management system.

5. Next part of the process would be to raise defects for all the above test cases. Now a day’s test management tools have a feature to raise defects from the failed test cases itself. It copies all the relevant information from the test case onto to the defect enabling testers not to spend time writing defects.

6. Defects will then be assigned to the developers. Once assignment is complete the developers can start writing the actual code.

7. After developer/s finishes writing code for his/her requirement or user story they will quickly look at the defects assigned to them and will perform a quick check whether any of them of it exists.

8. If the developer finds a defect in the above step they will fix the code.

9. The defects for the user stories which are going be delivered to QA will be marked as ‘Fixed’.

10. Once QA receives the build they will simply retest the defect and take appropriate action (Close or Re-Open).

11. If the defect closes the tester would then mark the corresponding test case/s as ‘Passed’.

12. Along with retesting, the testers would spend time doing exploratory testing and regression just to make sure no new defects are introduced.

13. Just like any dev methodology the defects, requirements/user stories and test cases would undergo several iterations within a sprint or the complete lifecycle until:

14. Almost all the test cases have passed.

15. Defects are closed, while some minor low priority defects can remain open.

Advantages

1. Since this process/methodology can gel well with both waterfall and agile paradigms AND if your agile teams have good collaboration between them then this new process will have no negative effects on it at all perhaps it will be an add-on thus enhancing collaboration within the team because the Devs will know the defects in advance and can fix them without even rolling out a single build to QA AND Devs would be consistently communicating with QA regarding the issues.

2. This proposed methodology is not going to change existing dev methodology, if you are following TDD nobody is stopping devs to write unit tests, if you are following BDD nobody is stopping you to write automation scripts, all these activities can happen in parallel. What I would suggest everyone to do is to visualize this process with in an open mind and try to fit in into their existing practices.

3. Increased visibility of QA organizations as they are the ones who are starting the process and giving food for thought to the developers.

4. This methodology gives QA ample time to do regression testing, ad-hoc testing and to automate them as well reason being builds will be more stable than the builds other methodologies would have produced.

5. Test cases that QA have been writing are slowly becoming meaningless as Devs doesn't care about them at all BUT with this practice in place they will carry weight as Devs will be providing feedback about the gaps, what's right or wrong etc.

6. Increased code quality:

7. The developer/s will know in advance what defects to expect. Points (4 and 5) mentioned above.

8. The defects would get fixed at a very early stage without even delivering a single build to QA. Point 6 mentioned above.

9. Team cohesiveness will increase because of increase in communication. Developers thrive on defects and if you give them a lot of them they would try to fix them ASAP and to fix them ASAP they will interact with the testers much more than they do now.

10. The project reporting will become very easy, all you must care is bringing the defect count from say 100 to 0 (or any acceptable figure).

11. Last but not the least developers will become better coders.

Disadvantages

1. Sounds like TDD except for unit tests are replaced by functional tests.

2. Team dynamics might change a bit, developers might raise few concerns as well but after few iterations things would stabilize.