Software Testing 3.0 is a strategic end-to-end framework for change based upon a strategy to drive testing activities, tool selection, and people development that finally delivers on the promise of software testing. For more details on the evolution of software testing and Software Testing 3.0 see:
Also see a previous case study on Software Testing 3.0 principals in action: Software Testing 3.0: Case Study #1
Following is a second case study of Software Testing 3.0 principals in action.
Testing Mature Software that was Never Tested
|Environment Prior to LogiGear|
A networking software company was testing core back-end functionality of their networking software manually utilizing a high-cost, on-shore based testing partner using manual testing methods. Because of the time consuming nature of manual testing, and the high cost of the on-shore manual testing partner:
- The company was not testing the GUI component of their solution that they deemed to be “mature” and not subject to a lot of change.
- The company’s customers were finding GUI bugs with every new release.
4,000 automated test cases
Coverage expanded from 0% to 90%
Automated GUI testing in only 20 machine hours
LogiGear implemented an automated testing program that made use of:
- Low-cost off-shore LogiGear testing resources in Vietnam. These resources are all trained by LogiGear University in Software Testing 3.0 concepts and tools.
- TestArchitectT, a tool set that integrates the latest methodologies and technologies in one easy-to-use package.
LogiGear has created an automated software testing program for this customer that:
- Has implemented 4,000 automated software test cases for the GUI software
- Expanded testing coverage from 0% to over 90% of the functionality of their application’s GUI
- Runs the entire automated test suite in only 20 machine hours
- Finds bugs that were previously found by the company’s customers helping to improve customer satisfaction with the software and lowering the burden on the vendor’s support staff
Generally accepted industry estimates indicate that bugs found by customers are at least 10 times more expensive than those found by software testing prior to release!
See: Quality Doesn’t Just Happen, By Judy McKay, CIO, May 24, 2007
LogiGear’s testing resources are now moving on to automating testing for search and data import functionality. In the future, LogiGear will also be implementing an automated software testing program with low-cost Vietnam-based testing resources for the company’s back-end software replacing the existing expensive on-shore manual testing.
Are you looking for the best books on software testing methods? Here are 4 books that should be on your reading list! The Way of the Web Tester: A Beginner’s Guide to Automating Tests By Jonathan Rasmusson Whether you’re a traditional software tester, a developer, or a team lead, this is the book for you! It ...
First, let me ask you a few questions. Are your bugs often rejected? Are your bugs often assigned back to you and discussed back and forth to clarify information? Do your leaders or managers often complain about your bugs?
Do testers have to write code? For years, whenever someone asked me if I thought testers had to know how to write code, I’ve responded: “Of course not.” The way I see it, test automation is inherently a programming activity. Anyone tasked with automating tests should know how to program. But not all testers are ...
The Testing Domain Workbook is the most extensive and exhaustive work you will ever find on a specific testing technique (or related techniques if you include equivalence class analysis and boundary testing as the book does). What I like best is the combination of academic background and roots combined with practical experience and industrial practice. All the concepts are ...
LogiGear Magazine March Testing Essentials Issue 2017
As I write this article I am sitting at a table at StarEast, one of the major testing conferences. As you can expect from a testing conference, a lot of talk and discussion is about bugs and how to find them. What I have noticed in some of these discussions, however, is a lack of ...
Internet-based per-use service models are turning things upside down in the software development industry, prompting rapid expansion in the development of some products and measurable reduction in others. (Gartner, August 2008) This global transition toward computing “in the Cloud” introduces a whole new level of challenge when it comes to software testing.
Trying to understand why fails, errors, or warnings occur in your automated tests can be quite frustrating. TestArchitect relieves this pain. Debugging blindly can be tedious work—especially when your test tool does most of its work through the user interface (UI). Moreover, bugs can sometimes be hard to replicate when single-stepping through a test procedure. ...
Introduction This 2 article series describes activities that are central to successfully integrating application performance testing into an Agile process. The activities described here specifically target performance specialists who are new to the practice of fully integrating performance testing into an Agile or other iteratively-based process, though many of the concepts and considerations can be ...
I’ve been intending to write a book review of How We Test Software At Microsoft, by Alan Page, Ken Johnston, and Bj Rollison, but for whatever reason I just never found the time, until now. In general, I like this book a lot. It’s a nice blend of the tactical and the strategic, of the ...
Introduction All too often, senior management judges Software Testing success through the lens of potential cost savings. Test Automation and outsourcing are looked at as simple methods to reduce the costs of Software Testing; but, the sad truth is that simply automating or offshoring for the sake of automating or offshoring will only yield poor ...
When it is out of the question to delay delivery, the solution is a prioritization strategy in order to do the best possible job within the time constraints. The scenario is as follows: You are the test manager. You made a plan and a budget for testing. Your plans were, as far as you know, ...