I assume ‘every’ fellow Tester in my network have experienced this situation at least once in his/her career. One of the most common Testing situation – How do you handle timeline crunch?
Since Testing is the last step before client demo, the Test team has to make-up for the delays encountered till the build is deployed in Test environment. Now how do you handle crunch timelines without impacting the quality?
- Consider some buffer in planning phases to accommodate the usual delays.
- The most common: Extended & Weekend working hours.
- Prioritize the Test efforts and communicate the same to all the stakeholders.
- Do nothing & complete as much Testing as possible in the given timelines. Convey the sorry picture to stakeholders at the end to get an extension.
- Highlight the delays to buy some extra time.
- Plan & make efficient use of working 9 hours.
- Convey the situation as-is to the stakeholders, asking for some time to complete testing.
- Quicken the defects turn-around time by communicating it to the development counterparts.
Whatever be the approach, always take a retrospective look once the testing is complete in order to avoid delays the next time. How did you tackle the timelines?
Alexander Pushkarev | Software engineer [in Test] | Trainer | Speaker
Michael Bolton has posted on his blog “Testing problems are test results”. It seems that situation you have described shows significant issues in overall quality management. My position is pretty simple:
- Every team member is responsible for quality
- Nobody should (and I would never encourage this either) overtime
- If there’s not enough time for testing we either decrease test Scope
- Or ask not test-focused team members help with testing
- Not ship/demo not tested (hence – not done) functionality
Abhijeet Vaikar | Software Engineer Test @ Carousell | Test Automation Practitioner
One common strategy I see working is to keep all stakeholders in loop continuously from the beginning, with the status of testing and any blockers/impediments that impact the delivery timeline.
Priyanka Samal | Test Lead at JK Technosoft Limited.
Have faced this many times. Use the first half in the office as many of the team mates would not be there to avoid distraction. Select scenarios to cover maximum functionalities and variety of actions from user point of view. Keep a track of all the regression issues occurred in the past and maintain it as a test case sheet. If you do not have time at all, this checklist is quite a safe bet to see existing functionality or repaired areas of the application is intact. If you see any risk, shout out loud and ASAP.
Ajey Kulkarni | QA Test Lead at nuVizz Inc.
If you don’t receive built on time, execute high and medium priority cases and give demo. QA need not be apologetic for that. This is project manager’s responsibility.
Ajay Garga | Technical Architect | Engineering Leader
My suggestion to tackle the time lines:
- Understand the use cases and end to end flow to test the functionality better
- Follow the order of importance of aspects of Quality assurance(with compliance with all stakeholders)
- Positive flow from end user perspective
- Performance and user experience
- Negative / Corner cases testing
- Communicate often and with clarity on meeting, defect tracking board and emails. This could help for quicker defect turn around
- Team spirit – from project and delivery perspective, Product, developers, quality assurance and deployment teams belong to the same team. Own the responsibility of the delivery with quality and time line collectively.
Deepti Sinha | QA Lead at Compunnel Digital
I personally try to postpone the release and buy extra time if it is possible. Also I make sure that if am not happy with the quality I convey it very clearly so that QA doesn’t become scapegoat later on!
Praveen Haridas | Test Automation Solutions Architect
Quality is everyone responsibility. The whole team should be engaged while testing for successful deliver in this digital world. Utilize more automated test from all level (unit, Integration, UI). Consider these automated test while regression, it will reduce your effort. Don’t repeat same test that is already been covered in various level. Focus more on high risk areas that potentially impact customer.
Jeff Nyman | Quality and Test Specialist
“Since Testing is the last step before client demo” That, right there, is a key problem. Testing is never the last step. Or at least should not be. When you frame testing as a design activity and an execution activity, you realize it takes place all along the life-cycle. As such, there should not be the time crunches.
When there are time crunches, that’s a sign that testing is only being treated as an execution activity and, even then, a purely reactive one. This isn’t to say we shouldn’t have plans for how to deal with time crunches. But it is to say that we should be re-framing a bit to deal with the systemic problem.