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

Methods and strategy have been my favorite topics since I started working in testing. It’s essentially engineering problem-solving. It’s both looking for efficiency and attempting to measure effectiveness. So, how do we develop a set of practices to solve our Software Testing engineering problems?
Hello everyone – I’m hoping each one of us is having a great October. This time of the year is always my favorite, with the changing of the seasons, Fall was always my favorite time of year; it signified change and renewal – but I don’t want to digress to much from what’s going 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. ...
I have been training testers for about 15 years in universities, corporations, online, and individually – in both a training, managing and coaching capacity. So far, I have executed these various training efforts in 16 countries, under good and rough conditions – from simultaneous translation, to video broadcast to multiple sites, to group games with ...
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, ...
A lot has changed since I began staffing test projects. From hiring college students and interns for summer testing programs, to building networks of offshore teams around the world, and from having 24-hour work schedules to having instant crowdsourced public beta or bug bounty testing—things have changed.
Happy New Year from LogiGear to those of us who celebrated New Years on January 1! And for our lunar calendar followers, an almost Happy New Year come February 3rd. We look forward to an exciting and full 2011 as its predecessor was a tough year for many in the software business. At LogiGear Magazine, ...
I was just recently at a company that had a beautiful test architecture, framework, and Cucumber with tons of well-automated tests. But there was no good test management on top of the Cucumber tests, and they did not do a good job tagging the tests. Although almost everybody on the team could write and maintain ...
This is our third issue concerning topics of Continuous Delivery (CD) and DevOps with the inclusion of Continuous Testing. DevOps has been around for a while and I hope the period of buzz is over and companies moving towards building a development pipeline have begun their process, including changing their test strategies.
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 ...
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 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