- 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.
- 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
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.
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.
- 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.
- Feature sweep, Compatibility sweep etc for every feature.
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.
- 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
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.