Where does the QA TEAM fit in the Project Lifecycle?

It can be hard to know where to start when discussing when is best to get the QA team involved in a project.

I have found that there are many different answers to this question and none of them are wrong, all have different challenges and arguments for and against.

Here’s just a few.

Just get them involved once everything is developed and ready to deploy as they will not add anything to the project until then

They should be involved from the requirements/User Story gathering stage of the project.

But ultimately the answer is this does come down to time and money as many things do.

My personal opinion is the earlier the QA tester is involved the earlier defects can be identified and as we all know the earlier a defect is identified the cheaper it is to rectify/ fix.

It is often incorrectly assumed or simply overlooked at which point of a project that a QA Tester should become involved. Although the QA Testers main role will involve the testing phase, they could (and should) also be involved earlier on in the project lifecycle (the ‘Shift Left’ approach). The QA Tester should apply their analytic skill set to assess the quality of the documentation that is being produced, for example the Requirements/User Stories. They will be able to add huge value in identifying any errors or issues with the document prior to any End User or Customer receiving the documents to provide sign off.

It also can be a huge advantage to the QA Tester, who themselves are trying to understand the system and the impact of change in order to decide their test coverage.

The QA Tester’s role is to oversee the system, be the gate keeper of quality and ensure the End User is receiving this at all times.

However, the role is not just identify bugs but also to try and anticipate potential bugs or problematic areas that may arise from new code development that is to be implemented into the system. Obviously, it can be every difficult to anticipate regression issues but with experience and good relationship with key stakeholders, including the End User it may be possible to agree which areas are impacted or at least pose a significant risk if there was an issue in LIVE.

Ultimately, all project or release stakeholders want to achieve the same goal and that is to resolve defects at the earliest opportunity to avoid financial and reputational damage, rather than after the deployment has gone LIVE.