Have you ever encountered a situation when there is a conflict between the program manager and the QA manager saying that there isn’t enough time to test or may be that the estimates have gone wrong due to some resource issues or the like? What’s the answer? Is it the end? Can nothing be done to fix the situation? You guessed it right. There’s definitely a way out. Such hurdles can be easily overcome by careful planning, risk analysis and by identifying areas where testing should be focused more.

Since it’s seldom possible to verify every facet, path, scenario, workflow or dependency of a product or an application, risk analysis is appropriate to most software development projects. Be it a mobile application project or a web application or a localization task. Most of the times, it is not possible to test the entire application within the stipulated time. In such situations it’s better to find out the risk factors in the projects and concentrate on them. The answer lies in a combination of factors such as judgment, common sense and experience. Apart from this there are other more formal approaches as well - orthogonal array-based testing, combinatorial testing strategies to name a few. But for now, let’s look at the former approach.

Let us look at what you should resort to while planning out your strategy. Some of the key considerations that one needs to take into account are:

  • Parts of the application/product that are most significant to the customer
  • Requirements or features that have the largest financial impact on your users
  • Features that are most visible to the customer
  • The functionality that is most important to the project
  • The aspects that have the greatest impact on security
  • The list of testcases that could encompass multiple functionalities or requirements
  • Which testcases would cover the best high-risk-coverage to time-required ratio?
  • What can be tested early enough in the development cycle
  • What lines of code are most complex to test
  • Which lines of code are yet to be revisited and have not undergone a thorough check yet
  • Which parts of similar or related projects in the past caused problems and defects
  • Which requirements, design or fragments are unclear or ambiguous
  • What are the highest risk factors if any, of your application?

Combining these considerations with risk management and deliberations with project stakeholders leads to finding out where testing should be focused the most. And that leads to answering the main question which is being sought after. However, there can be multiple solutions to this dilemma and it is absolutely okay for you to devise your own methodology as long as you have weighed all pros and cons of your project and have evaluated its scope. And nevertheless, don’t forget the customer and what’s important to him! After all he is the reason behind the existence of your project…

SocialTwist Tell-a-Friend