Despite what your boss might like to think, Bugs are a fact of Software. There’s a number of things you can do to minimise the occurrence, the severity and the impact bugs might have, mostly centring around having a reliable set of Unit Tests. Regardless of your best efforts, they will still find a way through the net, it’s how you handle them that matters.
My first piece of advice would be to be honest about them, and the root cause, however embarrassing to you or your team it might be. It’ll be too late to cover it up, so don’t waste your time thinking of excuses. Get to the root cause and come up with a plan to resolve it. If it’s a major problem in Production it’ll be on your shoulders to come up with a strategy to expedite a resolution.
There’s a right way to communicate what the problem was, sufficiently detailed such that the client feels involved (they’re part of the team) and sufficiently vague such that their head doesn’t explode with the minutiae of your code base (they won’t care). Don’t show your hand too early, make sure you fully understand the problem before you blurt out any half baked guesses.
One of the core principles in Agile is to have Cross Functional Teams whereby all members can develop and test. I suspect the reality (this is true of my workplace) is that this doesn’t happen all that often.
A Tester’s role is to ask questions and query everything to the Nth degree, particularly in the sprint refinement stage, so don’t be surprised (or irritated) when you’re their first port of call.
Testers have a different outlook on your Sprint. A Developer will ask whether they have enough information to start working on a problem and are likely more happy to fill in the blanks later. A tester will ask whether they have enough information to feel comfortable in signing off any change into the Production Environment.
This mindset is a valuable ally for ensuring that your backlog is in order, or at least a marker for the acknowledgement that perhaps not everything we are working on is in the best shape.
It’s a tester’s role to find bugs, don’t get offended when they do, or offended when they raise non-issues. It’s better to be safe than sorry!
The division between Support Staff and Developers is something that has always bothered me, (I might follow this up in a further post at some point). When starting out in Software I was a Support Analyst, fixing bugs, maintaining a fairly large infrastructure estate, implementing minor changes and having regular interaction with customers. This experience has proven invaluable in my subsequent career.
There’s a massive overlap in the skills that are required for a good Support Analyst and a Developer, this has obviously been noted in the explosion of the DevOps movement.
The analytical skills you get from having been required to fix real problems under pressure is something that a lot of Developers that I’ve come into contact with would benefit from. Not only this but it also gives you a slightly different slant to the code you produce, not only do you think about functionality but you also think about long term real world maintainability (not just following SOLID principles).
Many support staff given the right environment can become extremely competent developers with little effort to make the transition (that’s not to say they all fall under this category, or even want to!). Should your organisation insist on having dedicated support teams, the prior are definitely worth investing time on, they’ll make your life easier in the long run.