Agile software development approaches encourage a collaborative setting in software development projects. Software developments and software testers and quality assurance people have to create a better context for working together. This article discusses how programmers can improve their relationships with the software quality assurance people.
Author: Kendrick Curtis, Stainless Software, http://www.stainless-software.com/
Programming and quality assurance (QA) attract quite different people to work in them, and communication between these groups can often suffer from misunderstandings due to the different mindsets of those involved. Programmers are more problem-solving-oriented, whereas testers tend to be more meticulous and rigorous.
Beyond mindsets, software developers and QA teams are often located at a geographical distance, whether it’s the other side of the office, or the other side of the world. Here we look at some ways for developers to communicate effectively with QA teams in order to deliver better products:
Solve the Problem Together
Developers submit code. QA comes up with long lists of test cases that fail. Often developers have to submit several fixes, claiming each time that they have solved the problem, only to have the case failed back to them before the tests finally pass.
Is it any wonder that developers dislike QA for rejecting their fixes, or that testers think developers to be slapdash?
The truth is that no developer writes perfect code, and even if they do, often they are solving the wrong problem, or solving the right problem the wrong way. QA exists, the same way that code review and incremental development processes do, to try and close this gap between the possible and the perfect, and no developer should take personally the efforts of QA teams to verify that the code works as desired.
When QA come to you with cases that fail, or when you communicate with QA to give testing advice, the single best thing you can do is to try and cast this as a problem that you are all trying to solve together, rather than placing blame. Talk about code failing or tests failing, and not about personal mistakes; because testers make mistakes too and if you can cast those in a non-aggressive light you will help turn the conversation from “who broke this?” to “how do we fix this?”.
Bear in mind that QA will make mistakes too, so it is up to you to communicate sensitively when this happens, as well. If a test has been done incorrectly, say that rather than “you did it wrong”. If tests haven’t covered the functionality, suggest “these tests don’t exercise the fix” rather than “you haven’t tested the right thing”.
Share Knowledge
Where developers see an engine with pistons, spark plugs, fuel lines, a cam belt and drive-shaft, testers see an accelerator and a speedometer. Both groups can learn something from the other: QA people often have a better grasp of the UI and the use-cases of a product, whereas developers have a better grasp of how individual actions take place.
So as a developer, it’s worth understanding how it is that QA are using your code. If you can sit with them while they recreate a fault, you can often learn something valuable about how the program you are writing is operated.
Similarly, if you can explain the steps that you need to take to fix a bug, to give the QA people and understanding in broad strokes of the subsystems that you are touching, they will begin to get an understanding of how the system hangs together underneath. If there are system diagrams that can be shared, all the better – that leads to things like QA departments spotting a subsystem being at fault by seeing an error through the different interactions that rely on that subsystem, instead of reporting several seemingly-unrelated bugs. If QA can characterize which subsystem in a chain is failing, that can only make your job as a developer easier when it comes to writing the fix.
Document Everything
Ideally, any piece of work you have to do as a developer should come ready-packaged with all the documentation necessary to exactly describe the change you are going to make, and how that affects any end-users.
This ideal case is extremely rare, as we all know. But that’s not just a problem for developers, it’s a massive headache for QA teams, who are often left at very short notice trying to figure out from a few vague words (e.g. “fix login process”) in a trouble ticket what exactly has changed, what needs to be tested and what the outcomes should be.
It’s relatively easy to get into the habit of documenting any additional information you as a developer come across, on the trouble ticket itself. Where the error is, what subsystems need to be changed, any clarifying conversations you’ve had with the customer that change the requirements. Forcing yourself as a developer to ensure you clarify exactly what changes you are making as a comment on the ticket will actually help you think through what changes really need to be made, and how to deal with corner cases.
So this documentation effort will not only benefit you by helping you organize your own thoughts, but leaves an audit trail that QA can pick up when they come to test, which should reduce the number of questions they have to fire back at you in order to understand how to test the ticket.
Own your Mistakes
Sometimes the spec was unclear, sometimes the solution turns out to be undesirable, sometimes there are conflicting change requests that lead to pathological designs. Often, code that you write doesn’t take into account an unexpected failure mode – by not handling an exception, or by treating an empty variable as if it were filled; all of these things are grist to the mill of development.
But sometimes, you do actually do something stupid. The absolute best thing to do here is not grumble at QA picking up on your errors but to proudly stand up and say “yeah, I screwed up”. It happens to everyone and the more humble you are about your mistakes, the more respect everyone else will give you. You’ll also hopefully be more tolerant of mistakes in QA, which are also inevitable.
Conclusion
Developers that co-operate effectively with QA staff are better developers. Work together to cast your issues as shared problems that you fix together. Learn and teach with your QA department so that you can all get better at what you do. Make sure you write down what you know, too, both to solidify your ideas and so that others can better understand what you’re doing. Finally, when you screw up, put your hands up to it. These few steps may not solve all your communications problems, but if there are any you aren’t doing, making a start will make a difference.
About the Author
Kendrick Curtis is a web developer with ten years experience. He is co-founder of Stainless Software, a freelance web design, development, testing and content authoring company. More info on http://www.stainless-software.com/