Solve the "Dev vs Testing" dilemma
This is part of my "5 Ways to Build Quality in Software" article. You can find links to the introduction and all the other hints at the bottom of the page. Hope it helps!
In all companies I've worked there's always been a "dev vs. testing" dilemma: developers "code apps" and testers "validate them". The truth is this approach always creates an unnecessary chasm between roles and sends a very bad message about quality accountability.
Good software and test engineers know there is no "development" without "testing", nor "testing" without "development". They are one and the same in the same way a wall is formed by bricks and cement. What would you think if a wall was being built by one person putting just bricks and another person lifting each brick to put the cement around? Also, would you live in a house where some walls might have cement and some others only bricks? Exactly. Tests are the cement of the software, what makes it stay strong, and thus they need to be used properly so that the "weight is well balanced". This is also why quality accountability should be in the whole team!
What I've come to realise is that this dilemma usually appears when teams don't understand each other's work. Solving it is just a matter of proper visibility, transparency and/or removal unnecessary role "tags".
The most important step to be taken depends only you: start asking your colleagues how can you support their job better. If the question does not provide specific answers or they don't know what to answer at all, it means your team doesn't understand the full potential of what you can achieve together. Focusing in 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:
- 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 testers create to get information on how any code change affected the existing parts
- Ask testers to demo their test libraries to the dev team so that they realise 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)
- Challenge testers to use the same rules as devs do. This way devs will see tester's code in better eyes and will start doing code reviews for them. Then using their tests. Then adding more tests themselves. Then testers will have time to build better, more reliable tools to test, and working in parallel with developers, perhaps even pairing!
Would you like to get more hints? Check the other parts here:
