What to do when there is not enough time for thorough testing ?

What if there isn't enough time for thorough testing? The first answer (and applicable in a world that is more ideal) is to not be in such a situation. If you are releasing a software that is not thoroughly tested, then you are potentially sitting on dangerous ground, not knowing when and where the software could fail. However, there are cases when you are not able to spend as much time as you would like in testing the application. The rest of the article is about getting the right questions to answer if you need to determine what you should do when there is not enough time for thorough testing.
Use risk analysis to determine where testing should be focused. If the failure in a specific area could lead to a higher impact, then testing that area becomes more important.
In an ideal world, you have the time and ability to test every possible aspect of an application, every possible combination of events, every dependency, or everything that could go wrong, but in a ream world, there are constraints. Given this, risk analysis is appropriate to most software development projects. Risk analysis however is not so simple, and is a specialist field by itself requiring judgement skills, common sense, and experience. (There are training courses and other formal mechanisms that can train people to become more knowledgable in the area of risk analysis). Some of the factors or considerations that are useful when trying to estimate the procedure when you do not have enough time for thorough testing:
• Figuring out which functionality is most important to the project's intended purpose? This is a business decision and would need consulting from business analysts.
• Which functionality is most visible to the user? Users tend to be more concerned about things they can see, and those should seem to work perfectly.
• Which functionality has the largest safety impact? In this world, with legal worries about impact of software, it is helpful to make sure that areas of the application that can impact safety (human, structure, financial information) need to be tested in more detail.
• Which functionality has the largest financial impact on users? Users get real worried if their is a perception that a software flaw can have a financial effect.
• Which aspects of the application are most important to the customer? From the above points, it should be more clear as to which are the points that a tester should focus on, things that matter to consumers.
• Which aspects of the application can be tested early in the development cycle? In any development cycle, there will be parts that will be developed first, and there will be parts that will be developed later on in the development cycle. It is necessary to understand which are the items that will be available early.
• Which parts of the code are most complex, and thus most subject to errors? A part of any design and development process is the estimation of which workflows and areas of code are complex, where there is a greater chance of errors.
• Which parts of the application were developed in rush or panic mode? This is not a scenario that most people would like to see, but in rushed projects, there are parts which are developed faster (could be parts that are developed near milestones, could be components that are based on existing code and where there is a perception that this area need not have much focus).
• Which aspects of similar/related previous projects caused problems? Heuristics is a big help. Working on the basis of previous cycles and evaluating problems that came in similar situations gives a good overall pointer.
• Which aspects of similar/related previous projects had large maintenance expenses? There are many projects which are in maintenance mode, and for which there will be a large amount of data regarding problems that have cropped up, and error prone zones of the application.
• Which parts of the requirements and design are unclear or poorly thought out? Such a situation is more difficult to evaluate; the common thought in such cases is to deny that any implementation has not been well thought out, and so on. One needs to probe much deeper to find answers.
• What do the developers think are the highest-risk aspects of the application? Typically, the people who have actually developed the application are the ones who have the greatest idea about which area of the application is the most risk-prone. The dev and QE need to spend time in discussion so as to make sure that the most risky parts of the application are identified and tested.
• What kind of problems would cause the worst publicity? This is a difficult area. A part of the application that prints names improperly could be a trivial task, but could cause the application to become a laughing stock.
• What kinds of problems would cause the most customer service complaints? Customer service complaints cost money due to the need to have an active customer service, and can quickly eat away into revenue.
• What kinds of tests could easily cover multiple functionalities? Such a situation is most welcome. If tests can be tweaked in a way that the same test or series of tests can help in the testing of multiple areas of the application, that is great.

If you can add to this article, please add a comment.