Improving the Speed of Manual Testing
Manual testing requires a significant amount of time, especially if you’re testing a lengthy list of settings with multiple parameters without any tool. The next time you do that kind of work you’ll definitely want a specialized tool to save your time and sanity.
We found a series of testing tools from James Bach that are free and open source, offered under the GPL 2.0 license. James is a noted speaker and YouTuber and has some very interesting insights about testing.
One of these tools is known as ALLPAIRS, specifically ALLPAIRS Test Case Generation Tool (Version 1.2.1).
Review of Pair-Wise Testing
Before diving into ALLPAIRS, it’s a good idea to refresh your knowledge about pair-wise testing. It’s a technique for generating test data sets from a complete set of input data in the system, which can significantly reduce the number of test cases. Essentially, the formation of such data sets in which each tested value of each of the tested parameters is at least once combined with each tested value of all other tested parameters.
Pairwise Testing helps accomplish several goals:
- Remove redundant checks;
- Provide good test coverage;
- Identify the most bugs on the minimum set of tests.
Here’s some outside references that talk about the benefits of this type of testing:
- “…we measured the coverage of combinatorial design test sets for 10 Unix commands: basename, cb, comm, crypt, sleep, sort, touch, tty, unique, and wc. […] The pairwise tests gave over 90 percent block coverage.” [D. M. Cohen et al., 1996]
- “…a set of 29 pair-wise AETG tests gave 90% block coverage for the UNIX sort command. We also compared pairwise testing with random input testing and found that pair-wise testing gave better coverage.” [D. M. Cohen et al., 1997]
“Our initial trial of this was on a subset Nortel’s internal email system where we able cover 97% of branches with less than 100 valid and invalid test cases, as opposed to 27 trillion exhaustive test cases.” [K. Burr and W. Young, 1998]
Using ALLPAIRS Effectively
To start using this tool just unzip everything into a directory to get started.
Inside you will find a document with detailed installation instructions. Follow them and be attentive!
Applying Pairwise Testing
This method is effective only in the later stages of development or when it’s supplemented by basic functional tests. For example, if you perform configuration testing before using pair-wise testing, you should make sure that the main scenario works on all operating systems with default parameters (perform Smoke testing or Build Verification Test).
Doing this will greatly facilitate the localization of future bugs because with pairwise testing in one test there are many parameters with non-default values. And each of these can cause a failure, and its localization is very difficult. And in case of failure of the build testing, you should abandon the use of the pair-wise testing method. This is because many tests will fail, and the exclusion of even one test entails the loss of several pairs, and the meaning of using the method is lost.
Allpairs is not a remedy for all cases and you should use other well-known techniques before you try to play with Allpairs in other words to prepare correct data for test-cases generation using the tool we are talking about:
Inputs to the application are divided into groups that are expected to exhibit similar behavior. The key goal is to complete the test coverage and to lessen duplication. Partition system inputs and outputs into ‘equivalence sets’ . If input is a 5-digit integer between 10,000 and 99,999, equivalence partitions are < 10,000, 10,000 – 99, 999 and > 100,000.
Boundary Value Analysis
In this technique, the test data chosen lies along the data extremes. Boundary values include maximum, minimum, just inside/outside boundaries, typical values, and error values. The idea is that if a system works correctly for these special values then it will work correctly for all values in between.
Choose test cases at the boundary of these sets : 0, 9999, 10000, 99999, 100000.
Decision Table Testing
Test cases are designed with the combination of inputs that contain logical conditions. In the entry decision table it consists of four areas called the condition stub, the condition entry (TC1, TC2 etc,.), the action stub, and the action entry. Each column of the table is a rule that specifies the conditions under which the actions named in the action stub will take place. Where 1 is True and 0 is false, and X is a condition that is not applicable or irrelevant (optional).
Use Case Testing
Test cases are designed based on the use cases built by the functional designers. In the use case, the description between the actors, users and the systems is given along with the alternate flows. This helps the tester to grab all the scenarios clearly and base the test cases on those scenarios. All the preconditions required before testing are clearly mentioned . The flow graphs are useful to understand the way in which the system operates. Use case diagrams are also helpful in the acceptance testing phase since they are designed with the customer and consider user participation.
Here’s a graphical demonstration:
Testing is done based on the skills, intuition, and experience of the team. There are no strong test cases for this type of testing. An example of ad-hoc testing is exploratory testing, which is defined as simultaneous learning, and means that tests are dynamically designed, executed, and modified. When you first look at a new feature or system, you don’t know much about the system. So you design experiments (or tests) to help learn more about it. You then explore the system qualities and risks that you believe the customers, users, or other stakeholders may care about.
Testing to Ensure Quality
Accomplishing a triumphant position in the IT business means delivering astounding products. Improvements in your software products has the greatest effect on your business and its financial position.
Throughout your work processes don’t try to save money by skipping out on testing, as the expense of errors is excessively high. Therefore your quality procedures should cover every key angle: powerful arranging, test-situated quality administration approach, and a devoted QA group using the latest technology that makes manual testing faster and safer.