With software development, testing is integrated throughout the life-cycle. The software should be continuously throughout its development. Software development should not have a separate test phase. Developers should be more heavily engaged in testing and writing automated repeatable unit tests to validate their code.
Apart from being geared towards better quality software, it is also important to support the principle of small, iterative, incremental releases.
With automated repeatable unit tests, testing can be done as part of the build, ensuring that all features are working correctly each time the build is produced.
The purpose of these principles is to keep the software in releasable condition throughout the development, so it can be shipped whenever it’s appropriate.
Testing shouldn’t only be done by developers throughout the development. There is still a very important role for professional testers.
The role of a tester can change considerably in software development, into a role more akin to quality assurance than purely testing. There are considerable advantages having testers involved from the outset.
This is compounded further by the lightweight approach to requirements in software development, and the emphasis on conversation and collaboration to clarify requirements more than the traditional approach of specifications and documentation.
Although requirements can be clarified in some detail in software development (as long as they are done just-in-time and not all up-front), it is quite possible for this to result in some ambiguity and/or some cases where not all team members have the same understanding of the requirements.
So what does this mean for an software tester? A common concern from testers moving to an software development approach is that they don’t know precisely what they’re testing for. They don’t have a detailed spec to test against, so how can they possibly test it?
Testers can test that software meets a spec, and the product could still be poor quality, because the requirement was poorly specified or because it was clearly written but just not a very good idea in the first place! A spec does not necessarily make the product good!
In software development, there’s a belief that sometimes these things are only really evident when the software can be seen running. By delivering small incremental releases and by measuring progress, the acid test is seeing the software and only then can you really judge for sure whether or not it’s good quality.
Software testing therefore calls for more judgement from a tester, the application of more expertise about what’s good and what’s not, the ability to be more flexible and having the confidence to work more from your own knowledge of what good solutions look like. It’s certainly not just a case of following a test script, making sure the software does what it says in the spec.