Should Developers Design Test Cases?
In the 1970s, 1980s and well into the 1990s, software developers wore countless hats. As the IT industry evolved more specialized roles were created, like the QA Tester and Developer in Test, and more recently, the Test Automation Engineer. Very small teams creating small applications could still get away with “blitz testing”, where all personnel jump in to test shortly before a release, but this approach is hard to scale up for anything beyond a small app. Companies making enterprise software realized the need for quality assurance beyond developers testing their own code.
Developers should of course write unit tests to “make it work”, but they aren’t in a position to design real world system or end-to-end test cases that mimic user behavior. Even if the developers also happen to be users of the system under test, there are other concerns.
Mid-to-senior level software developers are expensive. It is not cost effective to have them continually context switching between developing and testing, and to additionally have them worrying about maintaining regression scripts. Ideally, developers should be focused on adding value to your product by doing what they do best: Developing.
Some years back I made a small video game, and I smugly assumed that there were no major defects since I was the sole developer and had a comfortably lengthy testing stage. Shortly before I released it, a friend play-tested and within minutes he reported a major showstopping bug that occurred when his character died. I was of course very good at my own game, and never died during my testing and in-turn I never checked that eventuality. As the creator, I had my own “happy path”. A developer’s job is to make their component work right, and so they often lack the negative “what can go wrong” mentality of a tester. They don’t always know their own blind spots, routes outside of the “happy path”, or even what real-world test data looks like. Most developers just aren’t able to test from the standpoint of an end user.
Even the biggest authors have editors, as people tend to look at their own “masterpiece” creations with rose-colored glasses as opposed to someone with a more objective eye.
The perceived savings of not having anyone designated for QA are out the door when your top developers are sifting through old regression testing scripts or doing research on user experiences for exploratory testing instead of focused on adding new features to your product to keep up with, or hopefully surpass, the competition. Catching defects early is critical to reducing cost, though “shift left” shouldn’t mean that all of the testing burden is shifted left to your developers.
So, you want to reduce cost somewhere and we’ve established that you need people who represent the user experience intuitively exploring every path of your system, and then designing end-to-end test cases and maintaining the related regression scripts.
Why not automate your manual test cases? You don’t need to hire a coder to create the scripts if you choose a testing solution that is based on high-level business readable English. Doing so also allows implementation staff, business analysts, and other front-line personnel who best understand your user’s end-to-end behavior to join the testing fold, and this in-turn increases testing coverage and lowers risk.
Interested in automating your testing and deploying with confidence? Contact Sales for a Cycle demo.
This post was written by:
Technical Pre-Sales Consultant
James has been working in software pre-sales and implementation since 2000, and has more recently settled into focusing on technical pre-sales. He takes care of our hands-on demonstrations, and eagerly awaits your request to see our Cycle test automation software in action. Drop him a line at: james.prior[at]tryonsolutions[dot]com.
Essential Checklist for Deciding Which Tests to AutomateTo automate or not to automate? That can be the question a lot of test professionals ask themselves. When deciding which test automation solution(s) your team adopts, which tests do we focus on automating and...
What We Covered: High level explanation of Cycle as a behavior-driven test automation solution Overview of advantages including collaboration, lower maintenance, streamlining, and how Cycle is used to mitigate deployment risk Overview of Cycle interface, syntax, key...
The retail landscape is transforming--do you have the people and processes in place to excel? In this whitepaper, we outline the 5 ways to succeed in this consumer-driven landscape.
Who Should Watch: Chief Information Officer Chief Technology Officer Developers Business Analysts QA Team Project Managers What We Covered: How the feature upgrades will increase productivity and decrease system downtime More Modern UI/UX. A new Inspector Panel,...
In this case study, we look at how Cycle was used to save a 3PL time and money by testing their heavily-customized Warehouse Management System (WMS) upgrade.