What's involved in taking software testing from good to great? It's true that a well-developed process that incorporates an effective toolset makes things easier for everyone. But more than anything else, being a good software tester is about taking personal responsibility for making things better. Just ask Jim Holmes, Director of Engineering for Test Studio at Telerik. He challenges all our preconceived notions about software testing and helps us appreciate it for the art form it really is.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Testing as a vocation
When Jim talks about testing, he goes right to the heart of the matter. "As a craftsman, first I need to have some spark inside me about wanting to improve. Or, I need to have a mentor who has invested some time in me to get that ember going." His favorite analogy about this particular specialty comes from Matt Barcomb, another consulting specialist with a keen understanding of the integral nature of testing.
If you're building test suites that are taking you more and more time to fix when your system evolves when there are timing changes or small component changes, you're not getting the benefits of automation.
Jim Holmes, Telerik
Matt likens the role of the tester to that of a village blacksmith in days of yore. This craftsman had a very specific skillset that was honed through years of experience. But being plugged-in to what was happening in the larger community was just as important as the alchemy the blacksmith worked with iron and fire. He had to plan ahead for peak seasons to prepare farming implements–or even keep an ear to the ground to know when a conflict was brewing in the region. In the same way, a good tester is deeply embedded in the development team and touches all aspects of the process. He knows the cycles of development and deployment inside and out and understands the long-term game plan as well.
Are you asking the right questions?
How can you shoulder the full responsibility of a master tester who brings value to the team, the enterprise, and the customer? How do you decide what steps to take next in advancing your craft? If you want to make a real difference, it all boils down to two basics. "Craftsmanship is learning to grow yourself and learning where you fit in the broader ecosystem." You can start by asking yourself the following question:
How am I making our stakeholder more successful?
What sort of information do I need to take back to them?
What things aren't working well in our development process?
How can I collaborate better with our developers to get the work done and identify risks?
What conversations do I have with the product owners who are setting backlog priorities?
Will machines replace testers?
According to Holmes, tools will never replace the toolmaker—nor should they. Testers aren't just meant to set up automated testing then sit back and service the testing software while it does the work. In fact, he says the goal of 100% automation isn't just unrealistic. It's inadvisable. The purpose of automation is to get checks in place. These tripwires are set up as an early warning system so you can focus your efforts elsewhere, preferably on improving processes and adding value. If your automated testing becomes too bloated, you miss out on the real benefits.
"If you're building test suites that are taking you more and more time to fix when your system evolves when there are timing changes or small component changes, you're not getting the benefits of automation." Fortunately, today's tooling, including Telerik's Test Studio, is making it easier to maintain testing with less upfront and ongoing time investment. This frees testers to dig in to meatier strategic objectives.
Getting it all together
The role of the tester in bringing the team together is absolutely critical. Jim says the way development is happening in the average enterprise has got to change. "Get rid of stovepipes. I think the enterprise community for a long time has operated from the mindset of ‘let me do my little piece of the work and throw it over the fence to someone else.' That's a horrible way to build software."
He says that testers, developers, and PMs shouldn't be separate. They need to be working in a smoothly integrated way. It's a valid point, especially since the divisive way things have been done for decades clearly isn't working—and has never worked. It's time to break down the cubicle walls and bring everyone together. It takes a village to build software.
How are you pursuing excellence in your craft as a tester? Let us know.