Testing is a skill and just like any other skill you learn it by practicing time to time. You practice it while you conduct testing on the job, offline when you are not testing, by visualizing different problem and thinking about how to solve them (or find defects) or by learning any technique and tool to enhance your knowledge areas.
Testing includes high level of observing skill. If you are a good observer then you can be a good tester (Off course you will also require other skills in addition!). When you test you observe:
#1 You observe the behavior of the application
#2 You observe the process and workflow in which application works
#3 You observe what's going in and what's coming out
#4 You observe how application behaves when induced with negative inputs
#5 You observe how application manage error handling
#6 You observe how application responds to a failover
#7 You observe how application works under high load and stress
The key difference between an average and good testers lies in their ability and capability to observe what is being presented to them in a product. You observe based on what you understood from requirement specification or a design document or based on how a application is built and presented to you.
I have seen many times that good testers will find more defects as compared to average testers even if they are provided with same test scripts. The key difference lies in the ability of a good tester to visualize and observe the behavior of the application in addition to just exercising the steps mentioned in the test script. Good testers see more than average testers and they are able to test more conditions and increase their chances of finding more defects.
You can observe and practice following things while testing:
#1 Observe the behavior of the function. Think whether the behavior of application is appropriate and as required?
#2 Before executing any step think what are the possible states in which application can move and then check all of them one by one. Once you move between different states then compare the data to see if it is as required.
#3 Monitor logs and identify any error generated by system. Read and try to understand the error as it may help you identify the cause and check other related scenarios.
#4 Observe the trend of issues reported. This will help you identify weak areas of the application and help you focus on potential areas around which you may find more defects.
#5 While conducting testing whenever you are taken to a new window or screen quickly scan through and identify any other problems in addition to the function tested by you. Even though this may de-focus you from testing your key function at that particular moment but with some practice you can improve this skill area.
What You See is What You Test. It's all depends on you on how far you want to see...
Showing posts with label Testing Techniques. Show all posts
Showing posts with label Testing Techniques. Show all posts
Tuesday, July 6, 2010
Tuesday, June 8, 2010
How much details Test Cases should have...
This is a very crucial aspect for designing the test cases. Even though it vary from situation to situation, but I'm giving some of the guidelines that may help you decide the optimal level of test case you should keep:
1. Test cases should cover positive, negative, boundary conditions, If it is a new requirement then we should try to cover full functional testing and if it is a patch or hot fix then we should focus more on Impact Assessment to the existing functions.
2. Wherever possible database testing should be planned have SQL related tests
3. We should keep number of steps to minimal and provide most of the tests data driven
4. Keep test data combinations in tabular format and try to make it compressed from easier maintenance and consistency
5. Use test techniques like DOE and Orthogonal array (also pair testing) for the scenario where we have large combination and data parameters
6. Identify and keep screenshots for test execution for future references and audits
7. Try to keep test cases modular and keep cross reference between different scripts for easier maintenance
8. In case you have related specifications available then you should try to keep references instead of repeating the scenarios e.g. For UI testing you can keep Style guides, for configuration testing, you can keep Configuration Baseline Document (CBD), for report validation, you can keep Report Mapping document etc for consistency purpose
9. Have different sets (and levels) of test cases focusing on Functional testing (Validation of functional requirement), Platform testing (Validity of different environment combination), Installation Qualifications for Upgrades (Upgrade from older version to new version) as per applicability to your situations
10. For Regression testing you should try to focus more on positive and business scenario level details
11. Following criteria should also be considered while deciding the level of test cases needed:
a. Test case detail dependency on the kind of lifecycle you are following e.g. Iterative vs. V-Model vs. Agile
b. Details of test cases depending on critically and priority of modules
c. Type of work is being planned - If you have your internal experts working vs if the testing work is outsourced
d. Level of available requirements and design specs
e. Level of testing performed functional, security, automation, performance
1. Test cases should cover positive, negative, boundary conditions, If it is a new requirement then we should try to cover full functional testing and if it is a patch or hot fix then we should focus more on Impact Assessment to the existing functions.
2. Wherever possible database testing should be planned have SQL related tests
3. We should keep number of steps to minimal and provide most of the tests data driven
4. Keep test data combinations in tabular format and try to make it compressed from easier maintenance and consistency
5. Use test techniques like DOE and Orthogonal array (also pair testing) for the scenario where we have large combination and data parameters
6. Identify and keep screenshots for test execution for future references and audits
7. Try to keep test cases modular and keep cross reference between different scripts for easier maintenance
8. In case you have related specifications available then you should try to keep references instead of repeating the scenarios e.g. For UI testing you can keep Style guides, for configuration testing, you can keep Configuration Baseline Document (CBD), for report validation, you can keep Report Mapping document etc for consistency purpose
9. Have different sets (and levels) of test cases focusing on Functional testing (Validation of functional requirement), Platform testing (Validity of different environment combination), Installation Qualifications for Upgrades (Upgrade from older version to new version) as per applicability to your situations
10. For Regression testing you should try to focus more on positive and business scenario level details
11. Following criteria should also be considered while deciding the level of test cases needed:
a. Test case detail dependency on the kind of lifecycle you are following e.g. Iterative vs. V-Model vs. Agile
b. Details of test cases depending on critically and priority of modules
c. Type of work is being planned - If you have your internal experts working vs if the testing work is outsourced
d. Level of available requirements and design specs
e. Level of testing performed functional, security, automation, performance
Tuesday, June 1, 2010
How to reduce number of tests using test techniques
Many a times we are required to perform validation with a large number of test scenarios that will require significant time and effort to cover the complete coverage. Most of us face this challlenge on a day to day basis due to following reasons:
1. Large number of Permutation and Combination of tests
2. Lack of resource and time available for testing
3. History data is not available that will help identify prioritization of test
To tackle this problem we may use test techniques that may help in reducing the number of tests and at the same time provide high level of coverage. This will ensure that we are using our resources effectively and optimally. one of the techniques that was used extensively in manufacturing domain and now used in software testing is Design Of Experiment (DOE).
DOE allows statistical analysis by experimenting behavior of different combinations of data. When you have large number of combinations then you can design your test data with Orthogonal Array (All Pair) techniques to reduce your number of tests. In this case instead of testing all n * n-1 combinations we create all possible pairs of data and test them. Let's take an example:
Suppose you have following parameters to test:
O/S
Win 2008
Red Hat Linux
Mac
Browser
IE
Mozilla
Print size
A4
A5
In this case if you take all combinations then you will get a total of 3*2*2 = 12 combinations, with all pair technique you can get this validated in only 6 combinations:
As the number of test combinations increased you will see lot of difference between all nth combination test and all pair test.
1. Large number of Permutation and Combination of tests
2. Lack of resource and time available for testing
3. History data is not available that will help identify prioritization of test
To tackle this problem we may use test techniques that may help in reducing the number of tests and at the same time provide high level of coverage. This will ensure that we are using our resources effectively and optimally. one of the techniques that was used extensively in manufacturing domain and now used in software testing is Design Of Experiment (DOE).
DOE allows statistical analysis by experimenting behavior of different combinations of data. When you have large number of combinations then you can design your test data with Orthogonal Array (All Pair) techniques to reduce your number of tests. In this case instead of testing all n * n-1 combinations we create all possible pairs of data and test them. Let's take an example:
Suppose you have following parameters to test:
O/S
Win 2008
Red Hat Linux
Mac
Browser
IE
Mozilla
Print size
A4
A5
In this case if you take all combinations then you will get a total of 3*2*2 = 12 combinations, with all pair technique you can get this validated in only 6 combinations:
TEST CASES | |||
Case | O/S | Browser | Print |
1 | Win | IE | A4 |
2 | Win | Mozilla | A5 |
3 | Linux | IE | A5 |
4 | Linux | Mozilla | A4 |
5 | Mac | IE | A4 |
6 | Mac | Mozilla | A5 |
As the number of test combinations increased you will see lot of difference between all nth combination test and all pair test.
There are tools also available but I have found tool provided by James Bach site as very effective and easy to use. There is a document inside the zip file that illustrates on how to execute the tool.
I would be more than happy to answer any related question on this.
Subscribe to:
Posts (Atom)