Best Practices... 2

... Continued from previous post.

 

http://testingsoftware.blogspot.com/2007/06/best-practices.html

 

1. Plan real life resource intensive tasks in advance and procure resources accordingly

Some applications may require processing large number of data for final output. During

functional testing of such applications, for quick results, a tester keeps on doing testing with

small set of data, which may take very less time. But user of that application will work with real

data, which may take significant time. A QE should process real time data that requires

application long time to process the data. Testing such cases in the end is not good idea. A

failure for long duration run is difficult to isolate. Isolating of such bugs is time consuming

activities. In the end of cycle such bugs will create panic and may delay major milestone.

Proper planning should be done to ensure smooth testing for long duration tests.

 

2. Test smartly

As the project/product becomes more and more complex, testing becomes a bigger challenge.

It is indeed impossible to test each and every scenario. Hence there is a need to test smartly.

Some of the smart testing approaches that one can adopt are:

a) Catching them early

One important thing to remember is to catch the bugs as early as possible in the life cycle.

The cost of fixing a bug early in the cycle is very less in comparison to the bug logged late in the

cycle.

b) 80-20 rule

This law states that eighty percent of the functionality should be covered in twenty percent of the

test cases. This method is a very handy resource of saving time and helps to cover the most

important scenarios as fast as possible.

c) Automation

Automation helps a lot in covering a lot of regression features thereby reducing the overhead of

the test team to test out the old features. Automation saves the tester time and can do repeated

tasks over and over again.

 

3. Sanity testing on every build

The sanity testing is very important and after every check-in, the sanity needs to be run.

Sometimes a change in one module may affect the other modules as such and also the entire app/product.

Sanity on every check-in/change will ensure that the basic things are working fine.

The issue with sanity is how many tests and which tests are you going to cover in the sanity pack.

The sanity pack should contain at least one test from all the features.

4. Feature sweep, Compatibility sweep etc for every feature.

a)Feature sweep

Feature sweep covers basic test cases of functionality. For every major milestone, these test

cases should be executed to ensure that functionality is not broken.

b) Compatibility Sweep

There are many features that require test cases for multiple hardware platforms,

Operating System among others. For a application that is supported on multiple OS (e.g.

Windows, Mac OS), different hardware configuration (AMD, Intel, Dual processor, hyper

threaded machine, different RAM etc.) and hardware (e.g. different printer for printing

application) such sweeps are very important.

 

 

5. Proper documentation

Documentation is a very wide term and includes any kind of written communication that helps the

project in sailing through. Documentation can be classified into four broad categories:

1) From the developers point of view

• Feature spec

• Design document

• Commenting

2) From the testing point of view

• Test plan

• Test script

• Execution matrix

• Resource planning document

• QA plan, among others

3) Documentation meant for the external users.

• User guide

• Help files

• Readme documents

4) Project management and Product management

• Requirement Specs

• Project Schedule

As a good Quality Engineer one should try to do the right amount of documentation ensuring that

the documentation helps smooth execution of the project and also helps to catch bugs early in

the cycle. Also the QE should make sure that the Developer has done the proper documentation

and if not the QE should follow up with the developer to get it done.