Every tester has had to deal with crunch time during the test phase. Testing is always towards the end of the development cycle and invariably something goes wrong upstream that causes the testing crunch at the end. There could be various reasons for this crunch time: Budget cuts, scope creep, hitting the dates, uphill deliverable dates slipped, etc.
It is important to be prepared when marching towards this crunch time.
- When you have down time in the beginning, take it as down time. No matter how fast testers get their analysis done, test cases written there are chances things will change again. So don’t feel guilty in taking the down time. But the other side to this is that when its crunch you have to give it all. You will have to make up the time to get the work done. Its give and take policy that you can discuss with your project manager or team manager. What counts the most is getting what needs to be done to get the product out the door. We can sit and complain but if the product does not go out the door, then we have failed as a team including the testers. So we can complain about it or plan it ahead to balance work.
- When estimating, plan some buffer time that can be used in the end when there is time crunch. You can do this hidden (don’t share with your project team – beef up estimates 10%) or you can let the team know what you are doing. This is not the best way but if you have been burned in the past then this could be something that you can discuss with your manager or department head and get a buy in from them.
- Cross train people in different projects. So if you have tester colleagues who are working on other projects, you can train them on your project and you can get trained in theirs. So during crunch time you can use their help and vice verse.
- Constantly go over the list of changes that are being planned in the release. See if there are areas/features that are being heavily affected. Plan more testing in those areas. During your downtime clean up regression test cases for those areas so you can have good test cases that anyone from your project can execute. You can use your cross trained colleagues or other resources (BSA or SE) from your project to help with testing those areas. This way you know your test cases well (since you reviewed and updated them) and you know exactly what they are doing when testing.
- Risk Ranking everything including regression test cases will help. Communicate this to your team and let them know as the time is crunched, you will be taking things out of the list that have lower priorities (less risky areas). Use different colors to show things that will absolutely have to be executed and things you can compromise on. Get a buy in early on from the team and management.
Its easy to stress about crunch time since we know its coming or we can go into the war fully prepared.