Test Execution - How can we do faster?

Development deadlines always slip, but release dates do not change; caught between these 2, the testing time is always compromised. Hence the testing teams need to work faster. If the application has withstood the first one hour of critical tests, it indicates the basic stability of the app. But every test is important from functional point of view. Here are some simple techniques to make it faster.

Testing teams may have a mix of people with different experience levels. It is very uncommon to see a testing team with uniform experience level. The first thing we need to do is to assign navigation and field level validation tests to the junior-most members of the team. The number of tests will be more, but they are relatively simpler to execute. For every screen, let them do the same, and in one or  two rounds they will get familiarized with the app.

Assign the form level tests to mid-level experienced testers. This will involve submitting a variety of data thru forms and trying add, modify, delete, view test cases. 

Assign business flow tests to seniors and leads. They need to wear the cap of the end users and move data across screens to achieve the business flow. These people are the best bet to test the reports. The senior people must start feeling the semantics behind the data that flow across the application and understand the business value of the flows. If this is not done, end user testing will always find finer problems and that may lead to escalation.

Always people feel happy to execute new tests (progression tests, for new features added or for change requests). But by principle, a fix or new feature introduction may create issues at some other place. So we try to cover those areas by doing regression tests. The first set of regression tests must be performed for the form in which  the new features/changes are introduced. The next set of regression tests must be done at the module to which the form belongs. The next set of regression tests must address the path in which the feature or change is introduced. Once these are covered, then only do other regression tests. This will ensure the the impact of the changes are minimal.

For every round of testing, reallocate people. Doing the same test again and again will make them slow. You cannot reallocate a person to a totally unrelated module. Every application has a flow of information from one module to another; e.g. request spare item in spares module, cater the service in service module, raise invoice in accounts module. If tester A has done testing of round 1 for spares module, for round 2, assign tester A to service module and in the 3rd round assign to accounts module. This way, the tester also logically moves to the next step rather than landing on a dark area.

Last but not the least. Ask every tester to stand up and do a simple neck and shoulder exercise for 20-30 seconds every hour. Remember, you need good blood flow towards head. When you are too attentive for hours, doing testing, with eyes locked to the monitor, you will develop neck and shoulder pains. You must be physically good to perform better. So take care of your body well.

For free learning courses, please visit http://www.openmentor.net

The first hour of testing

When a person suffers from heart attack or stroke, the first one hour is crucial. If we can treat the person in that first hour, there is about 90% chance that the heart or brain reacts positively to the medicines. This is true in testing also. The first one hour of testing can bring out a great insight about the health of the application being tested. To achieve best results, we have to execute the tests in a structured manner. Here is how.

At this point we assume that the test bed is ready and the application is already installed and ready to be tested. We may have 100s or even 1000s of tests documented and reviewed. Before test execution, ask this question on every test case - "If this test fails, is there any point to continue testing?". Mark all those test cases for which you get an answer "No". That means, those are the vital test cases that must necessarily work or pass. Let us take an example of testing a car. To test a car, we may have to do 1000s of tests; but if ignition does not work, if door does not open, if clutch does not work, if brakes do not work, if accelerator or gas pedal does not work, if steering does not work, is it worth saying that as a car? In your software testing, identify those test cases before test execution.

In the first 5 minutes, navigate to all screens in the application. Simply check the loading of forms and the look and feel. End users do care about screens more and more nowadays.

After this, in every form, if there is a provision to add or create new records, perform those. If no data is added, no data can be viewed; hence do add data. Add with valid data. negative data conditions can be done a little later. Ensure all these tests work well. In every screen try to view all existing data. If you see missing data on screen, we have a problem.

Then, execute critical workflows with valid data. One of the flows in a retail banking scenario may be, create an account, perform a few deposit transactions, perform a few withdrawal transactions, view account balance and transfer some amount from checking to savings account. The flow touches a set of screens with connected data. Usually every application will have top-10 workflows or top-20 workflows. Perform those meticulously. 

Generate a set of key reports and charts that the management people would view on the application on a daily basis. These are the heartbeats of the application to the customer's management; one wrong data in that, the management will lose the confidence in the product.

If we can pack these in the first 1 hour of testing, we can definitely see whether the application is ready to do what it is supposed to do, i.e. it works for positive data. All other invalid data validations, invalid flow tests. non-core features can be tested after the first hour. We call this as BVT (Build Verification Tests). No failure can happen in BVT. Only when all these tests pass, we ask our testing teams to proceed further. You may still ask a question, brakes in car not working does not mean that the horn may not work. I agree. But, if a critical part or path is not working, there is no point in testing less critical part. So let us not waste time and this will ensure that the build or dev teams to ensure they pay proper attention to the paths of the application according to their importance. 

Usually 10-15% of the total tests will fall under BVT category in every application. Attack those first.

For free learning content, visit us at http://www.openmentor.net