QA Does Not Have Enough Time to Test

We sometimes are not given enough time to test…and that is okay!

How it starts

Most projects begin slowly. Devs complete their tasks and QA picks them, tests them, and approves them (or not). We are all on the same page, the workload is manageable. We are working as a well-oiled machine. Everything is alright.

As application functionality increases, so does complexity.

We’re suddenly spending twice or even three times longer to get tickets “out the door”.

As if that is not enough, the program manager tells us we have half as much time to test as anticipated.

By now, we are feeling the pressure to overperform to meet the deadline decided for us.

Photo by Tim Gouw on Unsplash

Do not panic

Take a deep breath. Everything is going to be alright.

As Quality Assurance Engineers (QAE) we have already planned for this. We have communicated loudly and clearly that the timeline presented to us is unrealistic. Based on our estimates, we no longer have adequate time to test.

Voice your concerns

Let the team know there is now a risk to the QA timeline.

Putting together a new estimate with the updated timeline will be beneficial to the others in their decision-making.

After voicing our concerns, our Project Manager will present them to the Program Manager, Product Owner, and any other business stakeholders.

Communication is key here. The sooner we let the team know our estimates have been blown to bits, the sooner we can course-correct them.

If you have not yet voiced your concerns, do it now!

Correcting Course

Those responsible for the planning of the overall program timelines will review our concerns. They will use the new estimate presented by QA to weigh the pros and cons. They measure testing against other company-related factors. These other factors are out of our control.

Remember this — This is no guarantee we will be given enough time to test everything we expected to. We can consider ourselves lucky if everything goes according to plan.

The Verdict

The timeline and our updated estimates have been reviewed. There are one of two outcomes:

  1. The project timeline has been reverted to meet our original estimates. All is well. We continue on the same path.
  2. The project timeline is not changing. The business is willing to risk less QA for a faster launch. In this case, we use our revised estimate to test what we can do with the time we are given.

Outcome #2 is more likely.

Our testing effort is now dependent on the length of time we were given to test.

If the length is short, we will cut our testing scope. For example, if the timeline is kind of short, we will exclude edge cases.

If the timeline is very short, we might cut certain edge cases, some negative scenarios, and maybe types of testing (performance, security, etc.).

Keep cool, calm, and collected.

  1. Create revised estimates for increased scope or decreased timelines.
  2. Present your revised estimates to the team. The team will review the risk of cutting testing scope vs providing enough time.
  3. If you are given enough time to test, great! If not, go to the next step.
  4. Revise your test plan to accommodate the new timeline. This revised plan will not include 100% coverage. The business side of the project already understands this.
  5. Present your revised test plan to the project team. Incorporate their feedback into your revised plan.
  6. Get to testing!

Conclusion

Quality Assurance testing timelines rarely go according to plan. At any moment, timelines can change, scope can increase, or both! Don’t take it personally.

  • Communication is key.
  • Voice your concerns as soon as possible.
  • Give the team what they need to make informed decisions.
  • Do not take decisions personally.
  • You are great at your job.

Curious to hear your thoughts! Let’s ensure quality together by sharing your insights.

Share this: