A Word with the Wise: Expanding Testing Horizons

In this Sticky ToolLook interview, Danny Faught shares insight onto his earliest days as a tester, the skills he's acquired throughout his career, and skills and tools he believes every tester should posses.

Danny Faught began testing software on supercomputers a few days after getting his bachelor's degree in computer science in 1992. The degree didn't give him any knowledge about his new field, he now says, but the opportunity of "working on the big iron" intrigued him.

"It was sort of a fortunate accident that I became a tester, because I'm good at breaking things," he says. "I was good at it and I loved it, so I've been doing it ever since."

Danny primarily uses open source tools and programming libraries in his daily work, though he says commercial tools have their place. According to Faught, today's testing industry expends resources on functional test automation—particularly GUI—that would be better used on exploratory test automation.

"I'm amazed that people can get any work done just using a GUI. I would feel completely trapped if I had to work that way," he says. "I'm sure that my GUI skills could improve, and I could learn new ways that you can use an operating system through the GUI, but I'm so happy just dropping into a command line shell."

Success in the field doesn't necessarily depend on a tester's ability to program, Faught says, especially if the tester is also a domain expert. But for those hoping to compete as the testing industry grows, Faught recommends studying the basics of programming.

Learning a scripting language is also useful—and easier to tackle than learning a compiled language. It is important that testers "broaden their scope of what they think tools can do for them."

He recommends varying the sources of the tools as well. Some situations call for commercial products, while others may work best with open source or—for those with the programming knowledge—self-authored tools. If a company or client requires professional support, a commercial product is probably the way to go. Those who don't require a highly sophisticated tool may do just as well with open source.

"Some commercial tools are more reliable and have fewer bugs than open source alternatives, but that's not always the case unfortunately," Faught says. "You see bugs on both sides of the fence, and it's sometimes hard to decide which (tools) work better."

Price is another seemingly obvious factor in choosing between open source and commercial products, but a "free" product might cost the consumer in other ways—the time it takes to install, learn, and maintain the tool.

"The total cost of using a commercial tool may be less than for an open source tool, if that open source tool needs a few features added or it's difficult to understand what in the world it does," Faught says. "Open source does not automatically make it a cheaper tool to use."

It can also be difficult to find an open source tool that meets a very specific need, according to Faught. If a tester needs only a small component of a much larger program, it might be easier to just program it from scratch or draw the code from a programming library.

"It's a different approach than having a plug-and-play tool that's just ready to go," Faught says. "It's important to have programming skills, so that that approach is an option." And for Faught, it's important that testers—and the software testing industry—keep their options and horizons wide open.

About the author