For me, Testing is a mindset, not just a role that needs to be performed. Testing isn’t just part of the development cycle, it should be ingrained in every stage. Every aspect can be ‘tested’, whether that be requirements, architectural diagrams, code, unit tests, test scripts, user docs etc.
When Does Testing Start?
If I’m starting work on a project, I am starting to test from the moment I am assigned. There is a good reason for this, I feel that testing is more than just writing test plans, executing test cases, developing automation or even exploring the product in a time boxed exploratory session.
Testing isn’t just Test Cases
From the moment the first discussion about a new product or feature starts, I am testing, I am learning about the changes, I am understanding the features, I am thinking of pertinent questions which will both aid my understanding and assist development with design decisions and enhancing the testability of the code they will be producing. Yes, I will be documenting my thoughts and providing some form of test plan (maybe as a mindmap), I may be writing test cases, I will be involved in creating automation to verify test cases and raising defects, but these are just part of the overall role.
Testing is used to Improve Quality
Testing isn’t just about how something can be broken, it should be about how we can help to improve the quality of the delivered product, if that means having a discussion at the start of a cycle where you question the design and offer improvements to enhance quality, then you are finding a way to create better quality products, this is still a form of Testing. It is certainly more efficient and effective to invoke the change at the design phase than raise a bug and development having to fix an issue later. That’s not to say that when you ask those questions in the design meeting, you aren’t highlighting a possible test case that can be executed at a later point and it is true that test cases can be identified at any point, not just when you are writing a test plan.
When is Testing Finished?
A testers job is never done, there may always be more test cases to identify and more scenarios to run, but it’s about being confident that a high enough level of quality has been proven and the risk associated with the outstanding work is low. This will often be defined by criteria set by the team or by your own standards. That means, just the fact that all tests are passing is never enough to say testing is complete, there is always more that could be done.
And with it being a mindset, the fact more can be done, will sometimes mean you probably could’ve signed off earlier than you did on the testing but you “just want to make sure”.
In fact, I’ve never met a tester who signed off before they’ve put in a bit of extra work.
Simon Prior 
Interesting post. I agree that testing has to start from as soon as you have the idea, but we need to be careful that we don’t lumber the test engineers with the entire load of ensuring we get it right. Testing is part of the engineering process and has to be undertaken by all. I also worry about the term ‘Testing is used to improve Quality’ – yes testing can, and does, find bugs of different flavours, but we have to design quality in, rather than rely on testing. It might help if you clarify who you expect to do the tasks on the way through the product’s engineering.
Nothing new.