How to test on a tight testing schedule?

If you have spent some time in the field of testing, then you must have faced situations where you were asked by your test manager to test the application on the fly and deliver your report in XYZ days [replace XYZ with as few days as you can]! In case, you have not faced such a situation yet, then either you are unbelievably lucky or with all due respect, you have not worked on sufficient projects. But either way, it won’t be long before you encounter such a situation in your career as a software test engineer.

Contrary to popular belief/myth, proper skilled testing requires lot of planning, effort and work, and hence a substantial amount of time. But unfortunately, when projects get delayed, the time planned for testing invariably gets the hit while squeezing the schedule. What? The development team is running 2 months behind the schedule? No problem. Time for the magic trick! Squeeze the testing schedule by 2 months and presto! Congratulations, we have got ourselves back on the project schedule. Cool, isn't it? Well, probably not!

If you have started to presume that this post is going to criticize how project management stinks, then thankfully, you are mistaken. Because, as a tester I believe that a part of my job is to act like a “problem solver”. So instead of whining about how the rescheduled testing time frame keeps killing the poor tester, I would rather concentrate on finding a way to deal with such a situation. When you are hit by such a squeezed testing schedule, first thing that you could do to help yourself deal with it, is to “accept it”. This kind of things keep happening to everybody who works on a software project. Once we accept it as a part and parcel of our profession, dealing with it would suddenly start looking easier.

When facing a short time frame available for testing, you have to make the best use of the time and resources available. Starting testing with an assumption that “we can’t test everything, no matter what”, can really help. Even from an economic stand point it does not make any sense to spend lot of time and energy testing areas of the application where the chances of having bugs are low [this we can fairly tell based on our previous testing experience]. Also identifying areas where the impact would be negligible [based on expected user behavior] even if bugs were found is a good strategy while starting testing. As a rule of thumb determining what to test first and in which sequence, so that you spend the limited time testing areas that really matter, is an important decision that requires certain amount of analysis, intuition, and experience. Start doing a risk analysis to identify functions with the highest risk [thus most important and need highest attention] and functions that would be used most by the end user. Having a checklist to remind you of key areas that you would not want to miss certainly helps. Here is a checklist that I often use when I have much less time than I would have wanted to bargain for testing an application:

» Functionalities that are often used by the users. Start by asking yourself, “Which functionality is most visible to the user”.
» Functionalities those are most important to the project’s intended purpose.
» The most risky areas of the application with the largest safety impact. Areas, which if broken can bring down the entire application to it’s knees. [Talking to the developers for suggestions on the same is probably a good idea here].
» The areas of the application with the largest financial impact on the users (and hence on the project stakeholders).
» Newly added functionalities. Often they are the least tested ones and hence the dirtiest.
» Complex functionalities those are easy to be misunderstood (and hence misinterpreted). Look for parts of the code that are most complex, and thus most prone to errors.
» Functionalities that are based on parts of the requirements and design that are unclear or poorly thought out.
» Functionalities that are developed using challenging new technology, tools, architecture.
» Functionalities that are developed in rush or panic mode.
» Functionalities that demand a consistent level of performance.
» Functionalities that reflect complex business logic.
» Functionalities that require interfacing with external systems (e.g. third party shrinkwrapped software). These are often classic areas to look for integration bugs.
» Functionalities developed under extreme time pressure.
» Functionalities that had recent updates or bug fixes.
» Functionalities developed by many programmers at the same time.
» Functionalities those are most important to the project stakeholders.
» Identify related functionalities of similar/related previous projects that caused problems (in terms of user reported bugs). Correlate them to the current application and try to use it to your advantage.
» Identify related functionalities of similar/related previous projects that had large maintenance expenses. Correlate them to the current application and try to use it to your advantage.
» Identify functionalities, which if gone wrong could result in bad publicity.
» Identify functionalities, which could cause most customer support complaints.
» Devise tests that could cover multiple functionalities/features at the same time.
» Devise tests that could cover high-risk-coverage at the minimum time.

This is clearly not the exclusive list of guidelines/checklist to test under a tight testing schedule. But still, it covers quite a lot of important areas that usually needs attention. Being a context driven tester, I am well aware of the fact that using this checklist may or may not help a tester who is trying to test an application on a jam-packed schedule. However, it has served me quite well whenever I was in need of it.

What do you do when faced with such a situation of a tight testing schedule? How do you react when you suddenly find yourself being stripped off with some valuable testing time at the very last minute of a project deadline? How do you readjust your testing strategy to cope with it? Do you have any such checklist that you follow? I would be delighted to hear your ideas.

Happy Testing…

Share on Google Plus

About Debasis Pradhan

Debasis has over a decade worth of exclusive experience in the field of Software Quality Assurance, Software Development and Testing. He writes here to share some of his interesting experiences with fellow testers.