In what phase or stage of the project should QA testing start?

Question

Is it more efficient to start testing during project development or before deployment?

Answer 1

I noticed you did not ask whether it was better to start testing during project development or before deployment; you asked which was more efficient. You also did not specify whose efficiency you wanted to maximize. You did not say who would be doing the testing, but since you mentioned testing before deployment, I assume your refer to testing by someone other than the developer, regardless of whether the developer does their own unit testing. Finally, you asked about when to start testing, not about when the tester should get involved.

If the tester is overworked and forced to share their time between too many projects, it may be a more efficient use of their time to test after development is finished; that way, the tester does not need to redo work to compensate for changed decisions during development.

If the tester is not overworked, it may be more efficient for the overall team for the tester to get involved as early as possible. That way, for example, the tester may be influence decisions that eliminate problems before they are manifested in code. Moreover, assuming the tester has the time, testing should begin as soon as the interfaces they want to test are mostly stable.

I am not sure what you mean by "before deployment" -- in your organization, are there other phases between development and deployment? If you can clarify that point, I can try to address that aspect of your question, too.

Answer 2

It is more efficient to start testing at requirement phase during project development.

Answer 3

Starting testing during development is too late, and starting testing before deployment is usually a recipe for disaster, missed deadlines, and high unexpected costs.

Testing should start as early as possible. If you have a prototyping stage, then testers should be involved in the prototyping before any requirements / stories are solidified.

Early involvement not only empowers people to be a voice in the project, but also enables testers to start designing tests, modeling, reviewing, etc. that may prevent bugs and help promote quality throughout the project.

Answer 4

Testing team should be involved in the project from the very beginning. Especially important are gathering system requirements and design phases. Basically speaking you have to design your system for testability. It's quite difficult to implement test automation if your system hasn't been designed to support test automation.

It also depends on your organization what kind of tests do you use (unit tests, functional test, E2E tests, etc.) and what is your supporting infrastructure e.g continuous integration, nightly builds, etc.

You may also consider using of Test-Driven Development process.

Answer 5

Katrina, there are some great answers here already but I would like throw a monkey wrench into the mix. Requirements have been mentioned a few times. Requirements are nice but in the development team where I work, they are nonexistent. I test when the code is delivered to me, sometimes 2-4 weeks prior to deployment, and with zero requirements. Is this ideal? No, but it is a system that works for our development team. What I am trying to say is there are "ideal" testing environments and timelines, and then there are "real world" testing environments and timelines. It is more 'efficient' for your employer, dev team and customer for the tester to start testing in the timeline that works best for their own environment. While it is immensely helpful and valuable to know the latest QA paradigm and "best practices," if you try to conform to them and the rest of your team is not, you might go crazy. Always keep the big picture in mind.

Answer 6

You should clarify your question to define what is meant with "start testing".

Take a look on this diagram (taken from here):

There are various aspects of tests.
They are defined and run at all phases across Software Development Life Cycle (SDLC):

• Acceptance Tests are defined just at the same time with Business Requirements - e.g. they are defined at the very beginning of an SDLC and run at the very end;
• System Tests are defined along with SRS and are usually run for each alpha/local release;
• Integration Tests are "mid-range" tests for components; They are defined and run pretty often, e.g. on weekly scrums;
• and so on, till the very low-level Unit Tests that are defined and run on practically the same time;

So the answer to your question:
You should define and run different types of your tests at all phases of entire SDLC.

P.S. A common mistake is not allocating QA engineers from the very beginning of the SDLC. If it happens, they often don't have time for tests definition. I always ask myself, if I have nothing defined, how do I run it?

Answer 7

From my point of view testing should be started from the start of the project. Meaning from analysis phase through to documentation, design, code and deliver to stakeholder .

QA team is the Busy in all the Project from A to Z.

Answer 8

Many of the testers at my place of work are experts in the product domain, and have seen over-and-over what can go wrong. Including them up front is almost always worth the effort. They will:

• Identify potential problems, before implementation
• Help guide the development team during implementation
• Be more effective with testing after implementation