Are you looking for information on how to make software testing easier, more standardized, and more productive — and are answers out there? Noel Wurst, software testing evangelist at SmartBear, shares his insights on approaching testing with the right perspective, avoiding mistakes, and finding the framework that will address your current needs.
Is there a software testing framework that will work for every development team?
Wurst: There’s really not one single source of truth that can provide the essential components of every software testing framework. Though, when most people are looking for a testing framework, they’re talking about one that can apply to their test automation efforts. We see many teams looking for frameworks they can use to support their behavior-driven development (BDD) efforts. BDD has risen in popularity due to its enablement for greater collaboration between developers, testers, and other non-technical stakeholders — all of whom play a vital role in contributing to software quality.
Are there any common mistakes that developers make with test automation?
Wurst: I think again, that the most common mistakes are made when we try to deal in absolutes. “100 percent of testing should be automated,” “Developers should write + run all unit tests,” “Testers must learn how to code.” Every organization, every app, every business case is different, and there’s no single way to test or department who should test — or department who the results of those tests should be shared with. I think one of the most common mistakes that developers make — and it’s because the departments around them are making the same mistake — is to remain siloed and not frequently collaborate, and share success (and failure!) stories with others.
Are there ways to make testing easier and more efficient than methods developers commonly use?
Wurst: That’s a tough one. I’m not sure testing will ever get easier. Software grows increasingly complex with every release, testing windows shrink as organizations look for ways to ship software more frequently, teams are asked to “do more with less,” more and more teams are distributed geographically, the list goes on and on.
All that being said, testing can often be done more efficiently. From the time it takes to write test cases, how test reports are generated, shared and analyzed, what manual efforts (handoffs, code commits, test suites run, bug duplications, revisions, etc.) can be automated — again, the list goes on and on. Greater efficiency is one of those “continuous improvement” areas where developers, testers, and every team who plays a part in the software development lifecycle can make iterative gains.
What additional advice on testing can you provide to software teams?
Wurst: The challenge of meeting customer demands and expectations for better software faster is not one that will ever be “solved,” and every developer, tester, and operations professional knows this, which makes it all the more commendable that they continue to show up for work each day. There’s no “our software can’t have any fewer bugs than it does today,” or, “we couldn’t possibly ship faster,” and any organization that does believe either of those things won’t be around for too much longer. Just as teams can never “be” agile (you can only be more agile) nor can you reach the “end” of DevOps, today’s development teams have never been under more pressure.
But on a positive note, the development community has never backed down from this challenge, and has always been one of the most eager communities to share what they’ve learned, what new tool they’re using or what new methodology or platform, or framework, or container technology, or cloud is helping them meet these accelerated demands. Whether its someone doing live coding on stage for all to see how they tackled a longstanding problem, or a significant contribution to the open-source community, developers are constantly sharing solutions to roadblocks, bottlenecks, and inefficiencies that prevent transformative software from getting out the door and into all of our hands as quickly as we would like. I predict that a continuous mindset of “how can I help my peers?” will always be a well-known quality found in the development community, and one that we’ll all continue to rely on. 
