In part 1, I raised several issues regarding the gap between what software developers can develop and what software testers can test.  Here in part 2 are my thoughts on solving these issues…

What have outsource labs and in-house QA departments done to address these problems? Test labs have thrown more test engineering bodies at them.  This raises costs, and hurts their profit margins.  In-house QA organizations, typically with constrained budgets, cannot keep up with the volume of test code they have to generate to test the new software code in development.  They try to cover the most important business areas, if they know them, and hope for the best.

How do we get off this merry-go-round?  Where are the savings that automation is supposed to bring?  The litmus test for success is:  Does the automation allow the user to create and run reusable and repeatable test scripts?  QA organizations must utilize automation architecture techniques, not just arcane code "frameworks" to dramatically reduce their workloads.

Selecting the right functional tool set for the application under test (AUT) is the first step.  Many tools exist in the market today, from free ware to the expensive suites from IBM and HP.  The wrong toolset often leads to the" lipstick on the pig" approach to testing: testing is limited by the tool's ability to work with the AUT.

 

The next step is to optimize the test tool for the AUT.  While most tools advertise that they are "plug and play" – take them out of the box and they will work seamlessly with your application – this is rarely the case.  Tools need to be configured correctly for the AUT, or they will not work as they should.  Buying a toolset without configuring it is a waste of money.  Do your test scripts rerun on new software versions without requiring significant re-work?  If not, then you most likely have an "out of the box" test configuration, which means that you are losing significant sums each release.  To demonstrate the business case for software test automation requires showing that it reduces the testing time compared to a manual operation, and that it reduces the defects that go into production.  Rich Internet applications and agile development, in particular, are placing new demands on software testers to work even faster and more accurately.  Automation is becoming a must for these environments.  But if it is not done correctly, the investment in the development tools and the automation tools is wasted.  So if you are seeking to improve your software development process, look beyond just the IDE or code generation packages.  Assess your software testing practices and automation techniques to make sure that you are not stuck with a 1980's automation model.  The key to success is to keep your automated testing as current and state of the art as your IDE.