DevOps Zone is brought to you in partnership with:

Having worked as both a developer and an operations manager, I’ve gotten all too familiar with the ever widening gap between what developers and customers consider “done”. In order to help narrow this, I’d like to share some of my ideas and experiences concerning the software development processes with a vision towards actually releasing what customers need. Daniel is a DZone MVB and is not an employee of DZone and has posted 28 posts at DZone. You can read more from them at their website. View Full User Profile

Why Teaching Developers to Test is a Good Investment

  • submit to reddit

Test a developer’s software and you’ll find bugs.

Teach a developer to test and they can release their software.

A bit of a twist on the old fish and eating maxim, but the same idea: teaching a skill enables self-reliance and self-confidence. And, while it’s harder than quickly doing someone a big favor, teaching is scaleable in a way that quickly refutes another old adage: we have so many bugs because we don’t have enough testers!

Now, imagine all your developers are also testers. As they realize code quality is now their responsibility, the production of bugs slows to a trickle. Because laziness is their most prized virtue, automated testing tools begin to spread through the team. Cucumber andSelenium enable developers to start thinking like a tester while writing the tests in committable and executable code.

Sure, the initial hit in perceived productivity can turn away the bravest of managers. But push through for just a few months and you will have forever revolutionized your development process. Coupled with Continuous Integration systems like Jenkins or Travis, developers doing automated testing empowers your business to release earlier and more often. Faster time to market is one of the best ways to truly outclass your competitors.

For my team, I purposefully picked a testing language and framework that differed from our application. It had to be fun and intuitive to use but, at the same time, a powerful tool for ensuring code quality. Once the developers realized they got to learn a new language during work hours, their motivation outweighed their reservations of losing the safety net of a testing team. Meanwhile, the testers largely moved on to other areas, while the lead tester stayed on to help write test cases – arguably the most valuable skill of professional QA staff.

This step had a profound effect on the way the team worked together and our capability to do multiple releases per month. Have you challenged your developers to think about automated testing?

Published at DZone with permission of Daniel Ackerson, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Loren Kratzke replied on Tue, 2013/07/16 - 6:56pm

 In my experience, developers are the last people that you want testing your product. Sure it is nice for them to be test-aware and test-enlightened, however if their development represents any challenge at all, they will focus on testing the "hard part" and the "happy path". The rest will go untested and your test results will of course look great - all tests will pass every time.

The most valuable asset of a professional QA staff is their eyeballs (located not in the skull of a developer) and their willingness to explore corner cases (the ones that developers always seem to overlook).

Personally, I would have issues if I was hired to write Java and then re-purposed to perform QA tasks. I would have even bigger issues if I were hired to perform QA and was then forced to "move on to other areas" because developers think that they could do my job better. At least their manager thinks that.

One could drive a nail into their forehead and get used to it protruding from their skull in a few months, and perhaps find the payoff in a convenient place to hang their hat. These are only words of caution... Be sure that you do not introduce your team to self management or you may yourself need to "move on to other areas" which would totally suck.

Lastly, as a manager, you really don't want to be the smartest person in the room. It sounds like your team had no choice. Perhaps their was a rebel, he or she is probably gone. Those who remain smile and nod vigorously and the very opportunity to learn a new language on the clock. It is my opinion that new languages can only be properly learned off the clock, late at night, in a dark room lit only by a monitor, preferably in a basement littered with pizza boxes and Mountain Dew cans. 

Hope I didn't offend. Cheers.

Daniel Ackerson replied on Wed, 2013/07/17 - 3:12am in response to: Loren Kratzke

No offense taken at all, Loren - on the contrary, thanks for your comment and the discussion!
I don't believe coding for coding sake will be tolerated in our field for much longer. The days of the Wild West and cowboy coders are about over. Writing automated tests is generally quite hard for pure QA folks, but I agree with you 100% that QA staff are the best qualified to coming up with solid test cases

When developers and QA work directly together writing solid, automated test cases (i.e. in Cucumber), it's much more than just testing. It's about reaching a common understanding of the business case. In turn, as the developer must think about edge conditions while implementing the test, further questions about the business requirements automatically bubble up.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.