The discussions I attended shared a common theme:
This was that the focus of testing needs to be on business goals rather than narrow requirements. The best requirements are those that have examples or tell a business story. However, we do need robust stories – throwaway stories do not serve this purpose.
When documenting our tests we can then keep in step with these examples along with our test data.
We would increase our credibility by dropping the name “testing” from some of our activities. For example, a “testing workshop” could be better described as a “specification workshop” and acceptance testing be renamed “business process documentation”. The value of both being their collaborative nature, i.e. with the other stakeholders.
Some of our terms are actually confusing. E.g. “continuous integration” – the emphasis is sometimes on functional aspects not just integration and rather than continuous they can be long tests e.g. 10 hours. We should use names that “create the right picture in people’s heads”. “Validating frequently” would be an example here.
The tester challenge is thus to think from a business perspective. There is no IT challenge it is a business challenge. It is our job to make sure that the requirements match the business goals. The focus of our testing should be “the business process” not the “system”.
Regression testing has become an obsession because projects are dominated by rework. You don’t need automation if you get it right in the first place. “Refactoring is rework”. Just capturing large volumes of data can be useful for regression testing, but without examples it is difficult to know what is being “proved”.
The “code” is what the system does. So if we have example test cases that prove what the code does then we have living documentation of the system.
I have not attempted to cover everything that was said. The above is a brief summary of what I considered to be the salient points. I think the synthesis is that we need to build quality in from the start; we can’t test it in later.
