Part 3 in the series on how wisely designed pairwise testing plans can help when faced with a combinatorial explosion (part 1, Combinatorial Explosions Explained (Software Testing Example), part 2, How Many Pairwise Tests Required (In the Face of Combinatorial Explosions)).
This webcast continuing from where, Combinatorial Explosions Explained (Software Testing Example), left off.
This video shows how well designed test plans can achieve full pairwise testing coverage with a very small number of tests. And as the total number of permutations increase exponentially as more parameters and parameter values are added properly designed test plans can provide full pairwise coverage with very few tests.
This is not possible for a person to manually do but using the right algorithms to create a test plans can provide amazing benefits.
Related: More Coverage, Fewer Tests™ – 84% of Software Defects Found in Production Could Have Been Found Using Pairwise Testing – Looking at the Empirical Evidence for Using Pairwise and Combinatorial Software Testing – How to Pack More Coverage Into Fewer Software Tests – How Do You Know You are Executing the Right software Tests?
This short video gives a quick overview of the Hexawise software as a service solution and a very high level overview of software testing with a focus on interactions between parameters/factors.
Learn more about pairwise and combinatorial software testing practices: Introducing the Hexawise Coverage Matrix! – How to Pack More Coverage Into Fewer Software Tests – Create a Risk-based Testing Plan With Extra Coverage on Higher Priority Areas
Do you have too many software tests to execute, and not enough time in which to execute them? Hexawise can help.
Justin Hunter’s presentation at the 12th annual international software testing conference in Bangalore, India, December 2012.
The techniques discussed focus on how to reduce the amount of time spent selecting and documenting test scripts, reduce the amount of tests needed for execution by creating unusually powerful tests and thus increase the thoroughness of software test suites.
The talk explored the significant risks, for users, companies and employees of failing to catch software application failures before release (for example, looking at releasing Apple Maps with significant failures). And discussed how combinatorial (also orthogonal array or pairwise) software testing can be used to create test plans that test a large number of parameters/factors quickly.
The slides from the presentation:
This is an 8 part series of videos showing, in detail, various steps that can be used in creating a pairwise software test plan. Many test plans will not require many of these optional steps. Most of the videos have run times of 1-4 minutes.
The series of videos looks at how to create a set of functional test cases for customers purchasing products on Amazon.com using the Hexawise, a tool to create software test plans with pairwise and combinatorial test coverage.
Video 1 of 8, getting started creating up a new test plan.
Video 2 of 8, marking invalid pairs. This allows a test planner to avoid pairs that are not sensible – for example, if a certain product is not available for payment with a check (perhaps a service that requires a monthly payment). Hexawise will then avoid creating any test conditions that contained the invalid pairs that were identified.
This video provides practical tips for selecting appropriate test inputs for pairwise and combinatorial software test design.
Our experience shows as software testers begin to use pairwise test design strategies selecting the correct input parameters to test is often a bit of a struggle. This video will help testers get up to speed with designing pairwise software test plans effectively.
A basic introduction to pairwise software testing, designing a set of pairwise tests for a simplified banking application, and answering the following questions:
What is pairwise testing?
What challenges does pairwise testing solve?
How do pairwise software test design methods prioritize which specific test conditions are included in each of the tests in the plan?
What two aspects of pairwise test solutions don’t receive as much attention as they deserve? (Variability between tests, and front-loading of combinatorial coverage)
Video 2 of 2:
This video demonstrates:
- How should you think about including parameters and values in your inputs so that they trigger specific business rules?
- How can you remove “impossible to test for” scenarios from presenting?