I was asked in a fairly recent job interview how, when faced with a developer who didn't want to fix a bug that I raised, I would convince them to fix it.
Ironically, I was asked exactly the same question in my very first interview for a testing job, when my answer was, well, incredulous that such a thing would happen. Oh, how much I've learnt since then.
My answer in the recent interview was that firstly, I have learnt not to be too protective of my bugs - they aren't my babies, they're my opinion with evidence of actual behaviour but not necessarily correct expected behaviour, and secondly that over the years I've managed to amass a whole range of techniques to get all of us to agree on what the expected behaviour should be and to want the system to behave that way.
I didn't go into many details in the interview, it was not one of the main questions, but I thought I'd share some ideas here for how I reduce the conflict that can arise.
- My first step, in any project, is to build a good relationship with the developers whose code I am testing, and the product manager whose system I am hoping to perfect. I'm the epitome of a team player, even if I am shy and introverted, so this bit is quite easy for me, but I use an enthusiastic approach - none of us* want to be in weekends working on last minute fixes to be pushed through to production immediately because the customer demands it, so testing is essentially a service to the developers so that we can spend our weekends doing stuff we enjoy.
- Chattering around what I think might be a bug. "There's something weird", "Can you tell me what I'm doing wrong here?", "Why why why?", "I don't know, what do you think should happen here?" and occasionally just looking pointedly pained - we're helping each other out, I'm not pointing at somebody else's booboo. (And truthfully, there is a good chance that it is my booboo anyway.)
- Looking deeper and deeper into the consequences of the current behaviour. Does it break the user's flow, will it confuse technical support, is there a memory leak near it or because of it, is there something fundamentally shaky about how that whole area has been implemented that will come back and bite us later? Will we, heaven forbid, have to come in at the weekend??
- If I should have (or even could have) found a problem earlier, confessing that I should have found it earlier. This gets us over the whole discussion about how long it has been that way and not been a problem before, and it ties into my approach that I provide a service to the team.
- And now into the fun ways, once the team is comfortable together. Everybody's favourite gif at the top of this post, I have this pinned to the wall of my cubicle, so that I can (jokingly) point from one side to the other during an explanation of why the bug isn't a bug.
- "You mean, you want it to work that way?" This is great for those problems that are a result of poor design decisions, and even if these are the least likely to actually get fixed (depending on what stage of the project we are at, the legacy that we are working with, budget and so on, although I do make an effort to catch this stuff early) then they are still acknowledged as not being desirable behaviour.
- Looking more and more doubtful during an explanation of why it isn't a bug. And can I emphasise again, I am still open to being convinced, but if I have doubts then I just ... convey them in my facial expressions.
- Asking a lot of questions. If this is correct, then does that mean that that is wrong? How will the user recover from this situation? Should we put in some explanatory text? What is supposed to happen when I dongle the widget, given that the widget creation makes me pick this doodad? Can we change the default setting of the flahullah so that dongling the widget doesn't mean the automatic inclusion of the performance impacting gewgaw? (What kind of verb is dongling?) Doing this often finds easy fixes for bugs, or just convinces the developer that I have a point, or (perhaps) makes them put in a fix just so that I will stop talking.
The times that I still struggle are usually with developers who just assume that I am stupid - as you can see, I don't put myself up as a figure of authority, and there are times when my questions are met with condescending, trivial answers ("When you dongle the widget, the widget should be in a dongled state"), and while I manage to quash my immediate reaction ("Ugg want to know what dongled state") I may not get much further.
What are your strategies?
* I am not dead against working overtime or weekends (dear future employers), but I do hate having to rush through a fix. It seldom ends happily for anyone, and in my experience can kick off long chains of fix, push, discover new problem, start all over again.
