blog logo
[ultimatesocial count="true" networks="linkedin,facebook,twitter" url="" skin="minimal"]

Why Software Developers Should Test Their Own Code

Nataliya Hordiy • May 31, 2016

With hundreds of eCommerce implementations under our belt, the implementation process here at LYONSCG requires that developers test their own work before releasing it to quality assurance.

Why do we require this?

Aside from saving QA’s time and keeping the folks who sign off on code happy, this is an essential practice for a few reasons:

  • Process efficiency. Consider the productivity cost of correcting a small code error, such as a typo, after a developer has stopped working on the relevant code. In these cases, it might take QA longer to open the relevant file, find the mistake, and rebuild the software than it would take the developer to fix the error on his own. When you consider the time it takes for a software build to reach QA and the tester’s time spent pointing out the defect, it’s pretty easy to see that this is an awfully inefficient way to fix a simple typo.

  • Memory limitations. Anyone who’s ever worked on a software project for more than a week knows that code is easier to fix when you’ve got the big picture in your head. That picture fades fast. If the turnaround time for QA to report a defect is more than a day, a busy developer may spend extra time investigating an issue that would have been obvious at the original time of writing.

  • Technical insight. The developer has a “clear-box” view of the software’s technical functioning that can be useful for anticipating faults. This translates into more issues found in a given amount of testing time, as compared to the equivalent time in QA.

  • Self-improvement. The easiest bugs to fix are the ones that don’t happen in the first place. By testing their work immediately after performing it, developers may get a better sense of why they make certain common mistakes, and learn to avoid repeating them.

  • Meditation. Sometimes a little breathing space between writing and releasing code can be a source of valuable reflections. Observing bugs can prompt one to ask, “How could this code have been designed to prevent such bugs?” By the time code has been through a release cycle and the developer has moved on to other tasks, she may be (rightly!) less willing to consider other possibly better designs.

Finally, testing one’s own work is an important part of taking pride in it. At LYONSCG we encourage developers to consider quality assurance testers the same as clients. As a self-respecting developer, you’d be embarrassed to show software containing obvious flaws to your client, so why should you be ok with letting QA report those kinds of errors? The following is a prioritized list of the very least you should test before handing off your code:

  • The software still builds..!

  • Basic smoke tests like checkout flow and account functionality all pass.

  • The requirements for the feature you just wrote are met. As obvious as this sounds, every programmer has at some point made the mistake of building the gist of a feature while missing some subtle details. As far as the computer—and the client—are concerned, the details are all essential.

  • Edge cases, like the outer bounds of a value range, have been tested. In the same vein, inputs should be checked to ensure they don’t allow invalid data into the system. Basic negative test cases are attempted; that is, can you break the system with a little bit of mischievous thinking? Hopefully you can. A non-trivial feature that works perfectly on first implementation is probably a sign of insufficient testing creativity.

Finally, having talked a lot about what developers should spot check and why, it’s worth reviewing what the dedicated role for QA should be. If developers are thoroughly checking their work, does an implementation team even needed a QA department?

Of course the answer is yes (and not just because this writer happens to work in one!). In the first place, just as we acknowledged developers have technical knowledge that helps guide their testing, they also have assumptions that can cause blind spots. It’s just as important to have someone who doesn’t think like a developer examine your software as it is to have someone who does.

Secondly, the productivity improvements from developer testing that we mentioned above have diminishing returns; we don’t want expensive developers to be spending half their time on anything other than programming. Good testers become familiar with all the nuances of an entire system, and very efficient at testing; they also have a broader knowledge of the system’s regression history (for example) than any individual developer.

So to sum things up: in a successful project, testing has to be everyone’s responsibility. Developers and dedicated testers each have unique strengths and limitations when it comes to testing. When we work as a team, we ensure defects will be caught in a timely, cost-effective manner, and system requirements will be delivered to the letter.

Nataliya Hordiy is a quality assurance analyst at LYONSCG.

Nataliya Hordiy

About the author

Nataliya Hordiy

Subscribe to our blog

Let's discuss the next step in your commerce journey.

XSchedule a meeting