Thursday, May 30, 2013
Do a good job while doing the initial design and preparation, and it can be of big help later. How many times would you have heard this, but it is true, and we recently had an example of how relevant this actually is. Consider that you have a test plan and test cases to deal with the testing of a feature. It is a large feature with many workflows, and a number of combinations of inputs and outputs. These different input and output variables are what make testing of the feature difficult and lengthy, since each of these variables has to be tested along with the possible combinations. Overall, in any big software product, there can be many such features that need to be tested thoroughly, and possibly tested many times during the development of the product. So, if there is a big set of test cases dealing with the feature, then it makes it easier to test on a regular basis.
Now, let us consider the cases where the feature does not need a complete testing. If you consider that the complete testing of the feature may take more than 2 days, there will be times when you will be able to spend not more than a couple of hours on this feature. And if you do not have an automation run for the test cases, then let's continue with this post (if you have built automation for testing these cases, then it would not take 2 days, much less, more like the 2 hours that is part of the requirement, but building automation cases also takes time and effort, and most teams cannot build automation for all of their test cases).
However, as you get closer to your release times, you cannot afford to spend the full testing cycle. You diminish the risk by controlling the changes that are made, and then do a reduced testing of the features given the constraints on time available. And then there is the concept of dot releases or patches. These typically have far less time available for the entire project from start to end, and yet, there needs to be a quick checkup of the application including the features before there can be a release. Another example is when the team is releasing the same application in multiple languages and operating systems. If the same application is released across Windows XP, Windows 7 and Windows 8, Mac OS, and in a number of languages (and the large software products are released in more than 25 languages each), then it is not a realistic assumption that each feature needs to be tested on these various languages and operating systems in full detail. In fact, most testing teams do a lot of optimization of these testing strategies, and try to do a minimum of testing for some of these platforms.
But how do you get there ? When the testing team is preparing their test cases, they need to think of these situations. The tendency is to create test cases that flow from one to the next one, and are meant to be followed in a sequence. But to handle the kinds of situation above, the test cases need to be structured in such a way that they can be broken up into pieces for situations where the testing needs to done in shorter periods of time, and yet make the team still feel fairly confident that the testing has been done to the extent required. It also requires this kind of breakup information to be listed in a way that another tester later on who was not informed during the preparation of the test cases needs to use a subset of the cases for one of the special needs mentioned above (which can happen all the time, the original tester may not be a part of the team any longer, and may not even be a part of the organization).