Letter from the Editor – April 2014

Testing tools – very important, very often overlooked, and very often where mistakes are made.

First, the most common mistake people make about tools is thinking tools are only about test automation! False. Automation tools are merely one type testing tool. We will try to balance this issue between test automation tools and other test tools.

I heard a story about test automation, very recently in fact, of a company that paid a large licensing fee to a major tool vendor, and invested a lot of training and time to develop a phase 1 automation project. The intent was to scale up the initial phase into a large product suite automated regression tool. After just 6 months the project was dropped due to high test maintenance costs, over-idealized expectations and time demands. A whole lot of money, time, and tester goodwill went down the drain! I have heard too, too many of these stories with test tools, and specifically automation tools.

This story is not new. I heard nearly the same thing in 1994. This really highlights the need to address issues like designing code for testability, high reusability automation frameworks, lower maintenance test design, unrealistic tool vendor marketing, unrealistic staff expectation, etc.

Even after twenty years, too many teams still suffer from the problem of shelfware. Shelfware is slang for owning or licensing software that you don’t use (e.g. it sits on a shelf). It was a story I first early in my software career. And it’s particularly problematic with test automation tools.

Clearly, do whatever it takes to avoid shelfware at all costs! Be part of the tool evaluation process; Demand training; Get direct vendor support; Make sure teams are aware of possible long ramp-up efforts; Make sure there is significant set-aside automation time, separate from testing time. And, always, treat automation development as its own development project!

A great suggestion these days is to get professional services help to jumpstart your automation program. There are experts who can build a framework specific to your application of environment or work with you side-by-side and who can give 1-on-1 coaching to get the project started right or repair a broken automation effort. Yes, shelfware is a preventable problem.

Tools are meant to be the solution not the problem. But evaluation and selection is a unique process. We provide a few tips and there are many great articles on how to go through a tool evaluation process that will help you and your team get the process right! Don’t just rely on a tool comparison article. For starters there are some past LogiGear Magazine issues devoted to test tools. In 2012 (logigear.com/magazine/2012/09), we focused on Integrated Test Platforms such as ALM tool suites like TFS/Visual Studio, Jira, Rally, Rational/IBM, Thoughtworks. It’s worth a read. When carefully selected, carefully implemented, and you allocate the time and effort to maintaining your automated tests, automation tool are a huge bonus!

In this issue, Joe Luthy and I recommend that utilizing professionals can help you avoid epic testing fails; Robert Galen of Velocity Partners explains that picking the right automation tool can drive down test time and impress business folks; LogiGear staff present a set of criteria to pick the automation tool that’s right for you; Jim Holmes reviews Implemented Software Testing by Elfriede Dustin, Thom Garrett and Bernie Gauf; I provide some insight into the varieties of test execution tools and utilities for your toolbelt and Randall Rice of Rice Consulting provides a list of free and cheap software test tools that can help you across all phases of testing.

Tools help you do things. They can help you test better, faster, more informed, and help you isolate issues. Good luck! I hope you add some useful tools to your test effort.

Michael Hackett
Michael is a co-founder of LogiGear Corporation, and has over two decades of experience in software engineering in banking, securities, healthcare and consumer electronics. Michael is a Certified Scrum Master and has co-authored two books on software testing. Testing Applications on the Web: Test Planning for Mobile and Internet-Based Systems (Wiley, 2nd ed. 2003), and Global Software Test Automation (Happy About Publishing, 2006). He is a founding member of the Board of Advisors at the University of California Berkeley Extension and has taught for the Certificate in Software Quality Engineering and Management at the University of California Santa Cruz Extension. As a member of IEEE, his training courses have brought Silicon Valley testing expertise to over 16 countries. Michael holds a Bachelor of Science in Engineering from Carnegie Mellon University.

The Related Post

API testing– an old school technology gets way cool again. APIs and testing them is nothing new; the technology has been around for decades. The most basic definition of an API is an exposed function— a producer (person or company) writes a function and exposes it so that others, consumers, can use it. We copy ...
On the whole, everyone wants to do a great job, have a better work environment, happy clients and customers, and to be employed by a company earning lots of money. All great goals! But this is not always the case. When it is not, you can suggest process improvements, better tool use, different estimating techniques, ...
I remember the times when test teams sat in their own area and we were not allowed to “bother” developers.
Big and complex testing. What do these terms conjure up in your mind? When we added this topic to the editorial calendar, I had the notion that we might illustrate some large or complex systems and explore some of the test and quality challenges they present. We might have an article on: building and testing ...
I have been excited about this issue since I included it in the 2011 editorial calendar. This issue of LogiGear Magazine dives into an exploration of agile automation—from the most efficient methods for test automation, to skill sets and better preparation for test teams, and even to understanding the variety of tools in question. We ...
Because of the type of work I do (consulting projects at different companies), I’ve been lucky in my Software Development career to have worked on a bunch of software projects specific to hardware devices or integrating new hardware into software systems. Starting with the Palm Pilot, I worked on some operating systems (OS) projects, firmware, ...
I once consulted for a company to give a week-long course on testing and QA. It was a survey course covering a wide range of topics. I was setting up and chatting with students in the room. One man came over to me and said: “I have been testing for 6 months and I am completely ...
Continuous Testing… what is it? When we first decided to do a magazine issue dedicated to the DevOps practice of Continuous Testing, I joked with someone: “It’s about testing continuously.” And their reply was: “Yeah. What else would it be?” I was joking, but clearly the joke didn’t land. Continuous Testing is about testing continuously, ...
If you are reading this issue, you are probably aware of the impact on the business world of cloud computing. Most people do not have a good grasp on what the cloud is or how people and products can use it. BTW, you are already a cloud user. If your email is stored somewhere “on ...
Integrated teams Something we’ve learned in the Covid-19 pandemic is that we have to work together-whatever together means. Very few teams stayed co-located; even teams in the same town worked at home. We’re all working remote. Hopefully all the thinking, tools, work and effort we put into having offshore teams work together benefited us here. ...
“Why do we need to understand a bunch of test methods? I write test cases from user stories or requirements, automate what I can and execute the rest manually, and its fine.” If this is your situation: good for you. If you are time crunched, if your automated tests have lost relevance, are hard to ...
I spend about half my work time in the role of a consultant assessing, auditing and examining software development team practices and processes for the purpose of process improvement. I am regularly surprised to find teams that lack basic skills, management support, tools, information, access to users, Product Owners and to developers. And yet they’re ...

Leave a Reply

Your email address will not be published.

Stay in the loop with the lastest
software testing news

Subscribe