If you were to Google ‘Tester Developer Relationships’ it returns pages upon pages of advice on how to “get along with your development team”. Let me ask a question and please ponder on your answer to this. “How would you feel if you were a meeting with your surgeon and they kept referring negatively about your anaesthetises skills or previous cases? That would not fill me with confidence about their abilities particularly if they were that unprofessional they couldn’t sort out personal differences. I know I would be looking for another surgeon but what do you think?
Years ago, as a 18 year old, I worked in a fisheries in New Zealand as a packer, and I saw how issues were resolved on the floor when a dispute arose. It could become extremely verbally abusive, with the potential to escalate to a physical altercation, but once sorted, the two parties usually never spoke again. This level of adversary was not common but not unexpected either, as a professional attitude was not required just excellent knife skills. Do we as professionals demand more of ourselves as we hold ourselves accountable to the ISTQB Code of Ethics for test professionals?
A friend recently told me of a new position they are starting with a company as a QA testing role. My friend enquired why the previous tester left and was told they had to let the tester go because they had formed close relationships with they developers. Because of this close relationship, the tester had allowed bugs into production for fear of reprisal from the newly formed team relationship. I asked if they team works within a Agile process, which my friend confirmed they did. Does anyone else hear alarm bells ringing right now? For me it starts with the Product Owner who was at the interview and I believe made that statement. Let’s go back to Scrum 101 all the ceremonies that involve communication within the team (team includes Product Owner, Scrum Master, Developers & Testers (QA)).
- Backlog grooming
- Sprint Planning
- Daily Stand up
On top of the above meetings as a tester you have access to anyone including the Product Owner to be able to express your concerns about any risks you may have uncovered. Ultimately it is the Product Owner who will accept the risk based on information from all parties concerned or choose not to. There should never be a time when a tester feels that much pressure to not be able to approach the Product Owner about concerns. Here’s the point, I would always talk to the developer first and try to work with them about the concerns I have. I may of missed an important piece of the puzzle or I didn’t understand what the AC was and if that has happened, then Backlog grooming has just failed. My natural assumption would be ‘What have I missed and can you help me see it please‘ within my relationship with the developer. If along the journey it’s uncovered it wasn’t me, then I leave it to the developer to sort it out by reassigning the card back to them. Software development is a complex, intricate piece of engineering that I never expect to get right first go. What I mean by that is it takes so many pieces of the puzzle to put it all together that I expect to find piece that have been overlooked. I am very aware I look at things differently to my developers due to my own professional experience across different areas, my personal background and my age. These I realise are great attributes to a team and helps us to be well rounded.
In a nut shell my job as part of the team isn’t to break stuff or report on someones alleged coding mistake but to look at everything, all the puzzles in the giant picture. Starting with the initial code change through to the entire flow ensuring the pieces fit smoothly. If they don’t I raise the issue with the team, working with them as part of a single unit working together to deliver a good quality product to market.