Chema Del Barco Aladid

5 Ways to Build Quality in Your Software Series: Solving the "Dev vs. Testing" dilemma

Blog Post created by Chema Del Barco Aladid Employee on Dec 18, 2017

In all projects we have worked there's always been a "dev vs. testing" dilemma: developers code apps and testers validate them. Where does the quality responsibility start and where does it end? Such an approach creates unnecessary chasms between development and testing activities and sends a very negative message about accountability to our engineering teams.

 

Good software and test engineers know that there is no development without testing, nor testing without development. They are one and the same. For example, think of a wall: we all know that they’re built from bricks and cement, right? Can you picture a wall being built by one person putting just bricks and another person lifting each brick to put the cement around? Or would you live in a house where some walls might have cement and some others only bricks? Exactly. Tests are the cement of software. They make it stay strong, but they also need to be used properly so that the "weight is well balanced". This is why quality accountability must be on the whole engineering team

 

What we've come to realize is that this dilemma usually appears when engineers don't understand each other's work. Solving it is just a matter of proper visibility, transparency and/or removal of unnecessary role tags.

 

The most important step to be taken depends only on you: start asking your colleagues “how can I support your work better?”. If the question does not provide specific answers, or they don't know what to answer at all, it means that your team doesn't understand the full potential of what you can achieve together. Focusing on such a trivial and simple thing as supporting others can start the ball rolling towards better collaboration!

 

Here are some tips to make it roll even faster:

  1. All test scripts and libraries should be used by the whole team, not just by testers. The goal is not to wait for "QA sign-offs" but use the tools that testers create to get information on how any code change affects the existing parts.
  2. Ask testers to demo their test libraries to the dev team so that they realize how it can help them. When the developers see the value, they will invest in it. There's even a side benefit: after their code becomes public, testers will start putting more effort in making it more readable and usable (it will be a matter of pride).
  3. Challenge testers to use the same rules as devs do. If we build test code in the same way application code is built it will be easier for devs to understand it. It will also be easier to ask them to be part of the test code reviews, use the tests, and eventually add more tests themselves. Then testers will have time to build better, more reliable tools to test and work in parallel with developers… Perhaps even pair up!

Outcomes