When software testing activities should start

It entirely depends on the context, type of testings, the SDLC you’re doing or even what you mean by “software testing”. Anyway, “it depends” doesn’t seem the answer you’re looking for, so here are few ideas to when you have software testing started.

As soon as possible:

This is the general and ultimate goal in testing. This is what people often recommends these days called “early testing”.

The idea is to start your testing activities whenever you have “something” which can be tested.

That something can be a document, a early version of your software/hardware, a prototype…even an idea.

The whole point is to detect and prevent the problem as soon as possible before it’s too late or too costly to change or fix the problem.

So if you have a first draft of specification, send it to your testers so they can proof-read and detect “unreasonable” requirements, designs, logic. They may ask many questions but it’s a good thing.

As frequent as possible:

It’s good that you have started your testing activities early but you also need to make it as frequent as possible.

Disregard of the models you’re following, you need to make your testing as frequent as possible. It doesn’t matter if you’re doing 2-week sprint, 2-month release or you release the build whenever you want, you need to have your test team test your software whenever you made some changes in your software.

This not only helps you discover new problems but also confirms what worked still works now.

This is called regression test in case you don’t know the term.

As fast as possible:

The output of testing is information. When it comes to information, you need to provide it as fast as possible.

It means you can’t test your software for a few weeks/months and then you tell your development team/management team that you have a few showstopper issues that need special attention.

What??? I know you may like surprises but this is not the kind of surprise people expect.

So when you have an important problem, inform it right away and make sure that your team is aware of the issue. Tracking your problem on the bug tracking system maybe not enough, you need to write an email to bring the problem to the attention.

Please also consider test automation for repetitive tests to reduce the test cycle and to provide faster feedback. But be careful, automation test is another monster and if you don’t do it right, it soon becomes your technical debt.

Hope it helps.