D E V M A T E

Loading

When creating software, there is a constant iteration between development and testing. The below figure visualizes this phenomenon.

During development, new increments of the produced software are created, which are verified via testing. Defects found in this testing phase are reported to development in order to be fixed in future increments.
In this process, there are two roles, which are often seen as “opposing forces” in software engineering projects.

  1. The Software Developer who produces software increments during development. Every error that a developer makes in this step most likely results in a defect that has to be found by the tester. The aim of the developer is usually to provide functionality in order to satisfy requirements of customers.
  2. The Software Tester who tests these increments to showcase the errors that a software developer has made during development. The aim of the tester is usually to ensure quality and stability of software before it is shipped to production.

Although the different aims and natures of these two forces often make it difficult for developers and testers to work together, there are some lessons that each of them can learn from the other. I’ve summarized the most important ones in this article.

What Testers can learn from Developers

  • 100 % coverage is not the goal. Every test case costs money (salary of the tester writing and executing it, hardware resources for executing and maintaining it…). So usually, there’s a threshold in each project where the money spent on further tests simply does not weigh the potential benefits of maybe finding one more minor defect. However, testers tend to want to test everything (it’s their fault if some bug is detected in production). As developers are usually more interested in creating new features than testing existing functionality, they can act as a counterforce to this tendency of “testing everything”.
  • What is important? A tester alone usually cannot decide what are the parts of the software that are (i) more prone to defects, or (ii) more important to work correctly. However, especially for (i), the developer usually gets a very good feeling while writing code. By asking the developer, the tester can focus their work on providing maximum benefits to the work of the developer, and thus the quality of the produced software.

What Developers can learn from Testers

  • Documentation is key. Developers usually focus on writing code. When one part is finished, the tendency is to immediately jump to the next. However, after some time (at latest when a developer leaves a project), this leads to a state in which noone understands certain parts of the software any more, as there is no documentation about it. As testers base their whole work on documentation (to derive what is expected of the software), they can help developers understand what is important for someone else to understand their work and continue improving it.
  • Thinking something through. This “just code” tendency described above also often leads to developers working on something “just to code”. Writing code automatically gives a feeling of being productive. However, sometimes it’s more efficient to think something through, before working on one part of the code several days just to find out that this part was not even needed in the first place. I’ve written more about this here “Try This For a Week And Speed Up Your Coding Productivity 10x” . By talking to testers about the software before or during implementation, developers can learn to reflect about the purpose of a particular functionality, and how to best implement it. One way of approaching this is writing unit tests even before the actual implementation, which is usually refered to as Test-Driven Development (TDD).
  • Clicking through the ui is not enough. In my experience, “testing” for a developer often means running the software and seeing how beautifully it works. However, this is often not enough. A structured way of approaching tests helps here, and a software tester is the expert for that!

These are my main lessons that I often saw testers and developers make, when starting to talk to each other. What is your take on this topic? Do you have more lessons to add? Let me know in the comments section below!

Banner vector created by katemangostar – www.freepik.com

Leave a Comment

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

We use cookies to give you the best online experience. By agreeing you accept the use of cookies in accordance with our cookie policy.

Privacy Settings saved!
Privacy Settings

When you visit any web site, it may store or retrieve information on your browser, mostly in the form of cookies. Control your personal Cookie Services here.

GetResponse, Google Analytics

We use Google Analytics for marketing purposes. You can disable these cookies.
  • __utmz
  • __utma
  • _ga
  • _gat

We use GetResponse for marketing purposes. This service cannot be disabled, otherwise the website functions will be limited.

Decline all Services
Accept all Services
Get Free Access Now to
9 eBooks!
All about Automated Software Testing
Proven experts
Learn to save up to 75% of your test efforts
Get Free Access Now!
Get Access Now! & Save 50%
Personal Trainer FREE Nutrition Custom Workout App
Get Access Now!
eBook Download
Enter your details to get your free ebook!
All about Automated Software Testing
Download Free Ebook
SUBSCRIBE
MY WEB
NEWSLETTERS
Lorem ipsum dolor sit amet, consectetur adipiscing