TDD - some cheese with that wine?

I am seeing alot of talk about what's going to happen to the QA department with TDD - good news - it's going to be better - you might learn some new skills - your going to help development (it's a whole new relationship) - your no longer doing nitty gritty testing - start by reading as much as you can about TDD and the process get a head start it'll be worth it.

I've been doing alot of research on TDD and how it affects the whole System Development Life Cycle. I am excited. I've been in the Software QA world for some years doing both manual and automated testing, I really believe that TDD is going to be the best thing to happen for the QA team. In saying that I also believe QA people will need to start a new learning curve in using tools like XUnit in my case NUnit, MbUnit, and a bunch of others.

Developer's are not tester's nor are they suppose to be ... with that said in TDD they maybe writing a test before they actually write code but that does not mean that every possible assertion has been included nor does it mean that they have interpreted the requirement correctly. The test may pass but does that test cover all possible scenario's - probably not. Was the requirement interpreted correctly, was anything left out or missed. Keep in mind that requirements are not alwas telling the whole story or are they always complete. How many times as QA people have you had to ask questions about a requirement which resulted in adding more test cases/functionality to that requirement? This is still going to happen.

FYI - Assertion definition: A statement in a program that a condition is true at this point in the program. Useful for reasoning about how a program is supposed to behave.

Can we say each assertion is equal to a test case?

One approach in fitting QA into the TDD process which is my favorite is to pair with developers during the test code phase. QA people can work with the developer's making sure all assertions (scenario's) are covered in each test. Help in interpreting the requirement and what's required of it. It has been said that the developer's have to write their own tests they cannot wait for someone else too, I agree but a tester can help. I do not see pairing as slowing down development it's been shown that two minds are better then one and you have two different skill sets working together to create what will end up being more right then wrong. In fact in this approach the developer is writing the test code so the tester is doing their thing coming up with all the possibilities that need to be addressed by the requirement. For testers there maybe a side effect in this they'll likey learn how to write the test code not a bad thing to know.

Another approach is to pass over  QA a copy of the developers test code (often, as testing earlier is more efficent and less costly for all) at which point QA examines the assertions in the test code and makes sure that all scenario's have been covered. In this approach either the tester passes over missing assertions for development to add and make sure that they pass, if not they'll need to refactor the test code and implementation code. Or, have tester's that can add the assertions missing themselves run the test suite reporting to development any test failures.  I like the idea of adding the assertions myself makes my job more interesting.

Either approach is an asset to the whole project in that QA knows what has been tested therefore possibly eliminating test duplication which in return allows for more high level testing like performance, load, stress etc...  Note that if the test code covers all scenario's and are build as a Test Suite they can be run along side of each build therefore regression testing is being done daily. It is also possible to write xUnit integration tests they are more difficult but it can be done.

In thinking about this I have a suggestion for QA teams - learn how to code assertions in tools like xUnit it's not that hard then your team has the ablility to help development and take advantage of using these tools for further testing.

TDD does not replace QA there is still the usability of a system to test, depending on how involved in the test code you are a little or alot of functionality testing, another testing style I can see happening more openly is exporatory testing. QA can help out with the User Acceptance Testing which in TDD it should happen with each build not at the end, it's being called Customer or Business Facing tests - does this meet the expectation of the “Customer”. I call it looking for requirement omissions.

I had the experience last fall of using TDD with the system architects to test first using Microsoft Visual Studio ACT  the architecural design approach for performance and load ability. The design was proved to be able to handle performance and load requirements then it was built.

QA people do not be afraid that TDD is going to replace you - it's not - your going to end up with more interesting tasks and a new found respect for your skills.