Part way through your test cycle, do you often realize you do not have enough time to test? You had it all under control, to begin with, but soon you are reaching the contingency plan’s “What to do when there isn’t enough time to test?” section.
I have been there too and it is not fun. :)
I thought about this long and hard. How can something that started so well, go down so badly, so quickly. And, here is my analysis.
Firstly, Why does this happen? Many reasons – some of which are:
#1) Incorrect Estimation:
If you started with an inaccurate expectation, things are bound to fail. A good test estimate must take the following into account:
Recommended read => Check this for more information on test estimation success and methods
#2) Unstable builds and other technical problems:
#3) Lack of agreement between all parties involved:
This might be a rare problem with teams following Agile or SAFe due to the close circles they work in, but many teams still suffer from disagreement or miscommunication as to when Dev, Ops, and QA is supposed to receive deliverables from one another. Hence, delays.
To understand communication subtleties, check this => How Business, Development and QA Can Work Together to Get the Project Completed
Now that we know the problems, here are some ways to fix it.
#1) Estimate accurately. When in doubt over-estimate by a reasonable margin, but not underestimate. Don’t forget to make estimate adjustments based on your team, tools and processes. When done, seek official sign off so everyone is aware and is in kept in the loop.
#2) Take historical data into consideration – The Test Management tool is your best friend.
#3) Ask these questions and plan accordingly in crunch time:
Considering these points, you can greatly reduce the risk of project releasing under less time constraint.
#4) Use a Test Management tool. This will significantly reduce the amount of preparation, reporting and maintenance time and effort.
=> For the list of the most popular test management tool choice, check out here:
#5) There is not much we can do about incorrect builds/technical issues, but the one thing that can help is looking at the Unit test results. This will give us an idea as to whether the build was a success or not and what kind of tests did it fail – so we don’t reinvent the wheel.
If your Test Management Tool supports CI integration, you have that information available without any fuss so you understand the stability of the application better.
#6) Measure your productivity and progress often. Don’t let status reports be a deliverable just for the benefit of the external teams. Make sure you are closely monitoring your daily targets and your ability to accomplish them.
Also, be sure to not get into the classic conundrum of ‘Velocity vs. Quality’. Because, when you report, say, 50 bugs a day, it might appear as if you are being super productive. But if most of them are coming back as invalid ones, you have got yourself a problem.
So monitor, monitor and monitor a little more :)
Finally, despite all the precautions and measures if you still find yourself crunched for time, ask help.
Most teams are willing to participate in a war room session to get things back on track.
About the author: These helpful testing tips are provided by STH team member Swati S.
Now, what are your tricks to stay on time and deliver a quality testing service? Also, what points in the above article resonate with you?
We appreciate your feedback and cherish your readership. Thank you for reading!