Testing-after-all-coding-is-done

In a blog post my former collegue Anko – who is a tester – states that “… in discussions with testers … there seems to be only one belief: the fact that structured testing can only be done based on detailed, documented specifications and test execution-after-all-coding-is-done.” As Anko is very familiar with agile testing he knows better than this, and hence he ends with wondering: “why don’t we, as test professionals, have more answers than just one to structured testing?”

Well, I think there more than one truth out there. Agile and iterative development methodologies all embrace the idea that testing is a vivid part of each of the iteration. During each iteration a number of (similar) work items are produced, such as (smart) use cases or features.

In fact, testing already takes place before code has been written. We, for instance, test our smart use cases using a similar technique as TMap proposes in process cycle tests. But, here we test based on minimal use case description – and as a part of getting concious about the requirements for our use cases.

This presents our testers with a totally different role in projects – being the prmary designer for the project that is. Hence we approach testing not based on fully specified documentation (whatever that is, and whenever it’s produced – mostly never) but testers play an important role in our projects.

Having the illusion that testing should only be done on fully qualified documentation places testers in a very dependent position at the end of a project, and often in a very destructive role, as you are about to bash on the work of all other team members…

Anko Tijman’s blog post can be found at: agiletesting-anko.blogspot.com.