Bug Shaming. Is it helpful and does that matter?

There’s a thing you see on social media sometimes where people call out bugs they’ve found in other people's software. Okay, maybe I see it more because I follow other people in tech but if you’ve read this far so I reckon you move in the right circles to also see this behaviour as well.  I don’t know if this has an accepted name but I’m going to refer to it here as Bug Shaming.  I’ve done it myself in the past and I’m sure I’ll do it again but I think it might be an unpleasant habit. I found myself wondering why people do this, because I think it’s unhealthy.

When people do this is it so the company can fix the bug? If so then really you should try and direct it to the correct account and fill it with enough details for someone to investigate it. If you are a tester, there is no excuse for not treating this like a real bug report. If you truly are trying to help a company improve their software or hardware, you would want to utilise your known skills to increase their understanding of what you’ve found.

Unless you don’t want them to fix it. If you haven’t included the known ‘Support account’ in your public message then maybe the right people won’t see it. Or if you’ve tweeted at the general company when you know that your bug lives in a specific product with it’s own more niche address then maybe you want it to be seen by more people rather than the right people. So if you aren’t trying to get it resolved is your intent to show how clever you are? Is your aim to highlight how you are better at finding the bug than the team who worked on it were? Are you vocalising how appalled you are at the team who allowed the bug to get out in the world? Or are you just showing off? Because I think it might be okay if you are.

Lots of people do this and why shouldn’t testers be allowed to highlight bugs they’ve found in the public? More importantly who do I think I am with the authority to tell people what they are and aren’t permitted to do? Obviously I can’t stop people from doing this, and neither would I want to, remember, I still want to retain the right to show off myself occasionally. There is a type of sentiment which appears in Bug Shaming which I specifically dislike though, phrases such as; ‘Which idiot tested this?’ or ‘Why wasn’t this tested?’

If you’re an old fashioned software developer or a civilian (normal human who lives outside the software industry) then you are probably forgiven for doing this. Like you even care about my forgiveness. However if you’re a professional tester or an enlightened developer, (a test ally if you like), who works in a slightly modern agile environment then I think maybe you should avoid Bug Shaming testers. Be passionate to your fellow tester.

Here’s why I think this. If you are a modern tester then you’ve probably practised risk based testing in the past. You’ll know that you can’t test everything. Or you may work in an environment where the tester is not the sole quality gate. It’s fairly common for a product owner or the team as a whole to prioritise issues found in releases, deciding sometimes that bugs which have been discovered should be permitted to be let loose into the outside world.

I would guess that every agile tester out there has been aware of bugs going live that they really wish could have been fixed but which they have been told aren’t high enough priority.

At which point we should each of us be aware that sometimes bugs go live and it’s not because the tester was an idiot or that it wasn’t tested at all. Maybe the bug was a perceived edge scenario not worth running or the cost of fixing it was deemed too high.

So I suppose what I’m saying is, finding bugs in other people's software is fun but calling out the testers is mean. Let’s not be a mean community, let’s support each other. The people we should really hate are the developers who put that bug in there to start off with, right? I am of course joking with my last remark. Oh, you know what, live your own lives and do whatever you want, it’s just my opinion.

A Tale of Two Products

The following story is not wholly based on any singular experience but rather a conflation of multiple real situations in order to create a compelling enough story to discuss. (Any resemblance to real life people or products is largely coincidental.)

Premise

Product A has a pretty strong team who work on it. Everyone on the team has been specifically recruited because they’re good at the technologies it uses. They are all experienced in the tech stack and though some of the devs would like to rewrite sections of it they are mostly bought into it’s worth. It is the primary focus for most of the Developers, Business Analysts and Testers in the team and they commit as much time to it as possible. The more experienced members of the team are passionate in improving the quality of the code in Product A, taking every opportunity to get newer members of the team involved in their endeavor.

Product B is ostensibly owned by the same team as Product A. None of the strong developers work on it and it is primarily coded by those with less programming experience. It is written in a very different tech stack to that of Product A and as such only a small portion of the team are interested in understanding the languages and technologies used. At least one of the developers in the team refuses to look at the code at all, arguing that the amount of context switching required is unreasonable. It is difficult to improve the code because the stronger developers are reluctant to get involved in it.

The Product Owner is in constant communication with stakeholders and works closely with Business Analysts, Developers and Testers to shape Product A and set a strong roadmap. Changes are undertaken with as much understanding as possible of the scope and the dependencies involved. If bugs arrive they are prioritised to get them fixed as quickly as possible. The Product owner is occasionally frustrated at having to spend time on refactoring Product A but understands it is the cost of doing business.

It is difficult to get the team’s product owner interested in Product B. He has been told that it belongs to him but he resents spending money on something that doesn’t seem to help him achieve any of the wider organizational goals being set for him by the management team. Product B is intrinsically linked with Product A and almost all of the changes that come in are caused by that of Product A. The Product Owner gets frustrated if people discuss bugs in Product B and frequently brings up the possibility of scrapping it altogether arguing that his team would have more time to spend on Product A without Product B. As Product A grows, Product B becomes much bigger too and is frequently accused of being unwieldly and difficult to run. It is rarely discussed if Product B is actually helping to improve Product A, which should be the intention.

Everyone understands what Product A does and why. It was largely designed by a couple of developers who had built things of a similar size in the past and even though one of them has now left the team people agree that some of the foundations seem to work. Only one or two people understand how Product B works and in fact it was largely designed by a developer who hasn’t built a piece of software this large before. There is a similar Product (Product X) which was written by a developer who has since left the team and so it has been decommissioned. It performed similar functions to Product B, but no one understand how it worked and when there were problems in it is was decided to simply replace it. This took a great deal of time and effort and delayed the development of Product A.

A lot of time and effort goes in to understanding how successful Product A is proving to be and a great deal is invested in coming up with new ways to improve it. It’s actually quite difficult to measure what success means for Product B and occasionally some of the Developers who never touch Product B will get frustrated with its existence and the fact that they need to consider it when they make changes.

Conclusion 

Is it any surprise that Product B is a failure? The game has been rigged against it. I’m betting that it was obvious within the first couple of paragraphs that Product B is an automated test suite.

I think sometimes people don’t treat their automation tests like their other software, but if you look at it as just a different product it all becomes almost absurd how we act towards it. It is sometimes a product without a clear roadmap or obvious metrics. Dependant on another product, with frequently only testers working on it who let's face it,  are rarely hired for their software development skills alone. It is rather more likely that they’re being expected to be good at a whole host of other things at the same time.

If we accept just the premise that Product B is worthwhile what could we do to try and solve this problem?

·      Try and get all of the team to love both products.

·      Find out if Product B is actually providing benefit to Product A and in fact what benefit would be worthwhile.

·      Discuss what would make Product B more tolerable for the Developers to work on, as it’s currently only the testers who work on it.

o   Maybe building Product B in the same languages as Product A as possible to facilitate reduce context switching.

o   It could even be an idea to try the risky approach of allowing Product B to incorporate shiny new technologies that get the strong developers interested.

·      Try and identify what success means for Product B and always optimize for success.

·      Try and get everyone in the team to understand and agree on what Product B does and how it can improve Product A.

·      Maybe limit the scope of Product B and accept that it can’t do everything. This may help it to be considered alongside Product A when changes are suggested so the Product Owner grows to understand that it is part and parcel of making changes. In time you may even get the Product Owner to appreciate the benefits it gives him to Product A.