Hey all, I have a question for the community because I’m the only QA in my team and there was a situation today that made me think maybe I was being overzealous with a bug.
So some background, my company makes a point that they want us to be QA Engineers and not Software Testers because we are supposed to look after the overall quality of the products beyond just functional testing and regression. Also a point is that this application while technically internal, external clients do use it in conjunction with consultants from time to time.
Now for the bug I reported in a simplified way. There are 3 checkboxes in a grid element. 1 is read-only, 2 are editable. The rule is, when either one or both of the checkboxes are TRUE, the read-only is set to TRUE, when both are false, the read-only is set to false. The grid only saves, when a save button is pressed.
When testing what I noticed is that the read-only checkbox is only updating when you click out of the cell where the edited checkbox was toggled, or press enter on the keyboard (in no part of this application is the enter key used outside of line break in text fields).
Also as an aside, in other parts of the application, when there are these type of fields updating based on other fields, it’s immediate, although up until now there were only dropdown fields with this functionality.
So I opened a low Bug for this, due to the expected behaviour for consistency is an immediate update on the read-only field following the above rules.
I would be fine with it only updating on Save also, if that was the behaviour on the other mentioned dropdown fields. But either way I am not fine at all with the current behaviour, either update it immediately or on save.
Today the Developers on the team where shooting daggers at me while one was moaning about this bug, because it updated when you click outside the cell, because it updates on enter key, because it’s too hard to do this for checkboxes on Angular, etc, etc. I did stand my ground that first it’s not consistent with the expected look and feel, second it makes no sense for a field in a row to update when I’m toggling checkboxes in the following row.
So back to my question. Am I being overzealous?
Thanks for sharing here and welcome to the community.
First up, you’re not alone. This happens all the time when we testing professionals have our oracles which infer behaviour, where we use them to raise a problem – exactly like you did.
Those oracles may not be written down as requirements yet can be like you describe as another feature where you expect it to be similar. You mentioned “consistency” which reminds me of the consistency heuristic. And it’s completely valid to amplify problems with such a heuristic.
I’ve experienced subtle differences when I disassociated myself from “here’s the problem” and “here’s my opinion”. For example, merging the two together:
“We need to fix [this bug] because it’s not the same as how every other checkbox works elsewhere across the site.”
An alternative. Note how they are separated in conversation. One is a statement and one is a question.
“I noticed [this behaviour with the checkboxes].”
“What do you think about us updating this particular set of checkboxes so it’s consistent with other checkbox behaviour across the site? I’ve seen this done on other sites and I think our users would benefit from this level of consistency.”
Good on you for advocating for a consistent experience for your customers. I hope the next encounter with your developer colleagues goes well.
And please continue to stay connected to other testing professionals on the Club and across the Ministry of Testing community. We do share similar challenges, particularly being the only tester on a team. We’re all here to help each other out.
Which reminds me, are these handy things on your radar?
@zeh I feel seen.
Yep, have done that, and I think it’s a good trait to take ownership of something that looks unusual - even if it means the app still works as expected. Sometimes just asking the devs if the behavior is supposed to be like that is a good start. You never know until you ask, since it is often an accidental bug (actually I see this similar inconsistent behavior in apple macOS apps a lot). And the devs might fix it easily without having to raise a bug ticket. Bugs that never need tickets are the cheapest. But if not, sometimes just having a note of an unusual thing can help you in future when someone does decide hey that’s not right, then you have a note that shows you not only spotted it first, but also shows all of the other places that it’s happening in the app too. Sometimes these discussions with devs over “wierdnesses” are a good chance to learn more about how an app works internally.
A thing you will have to get used to is raising a bug, and then seeing it closed later as “won’t fix”, or “abandoned”, I also prefer these bugs to ones that float about in the system for years. Once you leave a company any bugs that are “open” on the day you leave wont get magically resolved, and you won’t own them anymore. So when I raise a minor bug, I have to also think, who will care when I’m gone, if the answer is “probably nobody but the next tester”, then let the team rather abandon the bug. I suggest reading the links Simon shared, those are pretty much the bible on this topic for most of us testers.
Thank you @simon_tomes and @conrad.connected for you great responses.
I already saved those 3 resources.
I’m especially interested in the “consistency heuristic” article. It is actually a big question mark in my day to day how to separate the two. In one hand it is asked of me to take care of these issues as bugs and all work done by Devs to have a work item, on the other is also asked of me to send anything perceived as changes to the BA. The line is very blurry and not easy to walk. Some things feel obvious and omitted from the requirements because they are some sort of implicit part of the design and turn out not to be, and the opposite is also true, some things feel built as intended and are in fact bugs by omission.
Usually there is a great communication with the developers, and I’ve opened a lot of bugs that I perceive a lot more inconsequential without much fuss. I’m not sure what was about this one that triggered them.
In this case it was clear from talking to them that this wasn’t a matter of built as intended but rather of the work to put in to make it function in the right way. Or rather what I perceive to be the right way.
Anyway I’m pretty sure the issue here is no one had a clue how to implement it right, since in the mean time I’ve been seeing Stakoverflow links on how to do this going around our team Teams channel and it was mentioned before that it was not easy to do in Angular.
But I find that how hard something is to implement is irrelevant for me. True bugs can stay years in backlog hell due to the effort and priorities but I’m there to find and report them and as long as I own them I’ll stay on top of it.
What are you guys relationship with the developing effort of what you report? From my point of view, cost, effort and priorities are not my main concern, product owners and business analysts should worry about those.
I may be wrong in my view though.
Are you being overzealous? Not in my opinion. User experience is important - lack of feedback when it comes to saving stuff is a big bugbear of mine.
There are broader issues though, just going off your story…
Developers sideways-glances because the tester raised a legitimate inconsistency in the experience, is a problem, for both you and the rest of the team and indeed, the wider business. That needs resolving immediately, in my opinion.
Developers moaning about a bug existing, is another problem. To me that’s like a plumber moaning about a leaking tap. Sure bugs are / can be annoying or elusive but they’re kinda’ the dealio in this line of work. Bugs are always going to happen, and hey look you found one that hopefully can be fixed and not get into production! You are literally helping the developer produce better quality code.
The difficulty of how to implement something properly is irrelevant, it doesn’t change the issue existing or not.
My concerns by the end of your thread was that the space may not be safe for the developer to admit they could not implement what was asked. I’d be asking why that was, and supporting resolving that. There is huge value in motivating the team to focus on one thing that’ll help move tickets across the kanban - no one should feel its all ‘on them’ or that they can’t do the job - its a team success.
Of course I’m not naive, you will always get difficult people - So when I find a bug that I know not everyone will agree is important, I put it to a scenario - like worst case. Sort of like; “If we knowingly leave this in, we could potentially let customers do [insert damning thing here]” - Sometimes it works, but you don’t win every time.
It’ll be up to you to decide to die on that hill or not.
Thank you @whitenoise
I do know one of the Developers did some time ago tell me they feel they are always trying to prove themselves. There may be something else going on in that part of the team that I’m not privy to as you mentioned.
All the advice you guys have been giving is great.
I guess being a lone QA has these drawbacks where you need to find online communities just to have the “Am I crazy or what is going on?” conversation you normally have with colleagues.
Also the Impostor Syndrome doesn’t help, but I guess that’s really an epidemic in most development related fields.
It sounds to me like a valid bug.
I like having bugs in the system (unless the dev is fixing it immediately). I get why some people would rather just not enter something and would totally support this if it was immediately fixed as part of the user story but otherwise I’d always rather have something in the system. It doesn’t matter how petty and small it is, record it. The team shouldn’t feel obliged to fix every defect.
My first big reason for entering bugs is that if you don’t enter the trivial niggles or visual issues then where’s the visibility on this aspect of quality? I’ve been involved in a project where I was told to hold back on entering bugs unless they are major as it was known to be “rough around the edges”. The problem there was that people couldn’t really get a good answer how rough.
Secondly in software we have the idea of DRY, don’t repeat yourself. Well part of having a bug report and if necessary the reason why its a won’t fix is that you don’t go spending time investigating it all over again when someone else stumbles on it. In this case, DRY applies to the same. Save your colleagues (or even yourself) time down the line by recording your findings.
Finally there was a design flaw in our software that I asked about. The response was “yeah, that’s known but it was a compromise made at the time due to deadlines.” Fair does. It happens. A year later I found myself hitting a consequence that was in my view a bug. As I couldn’t find a bug, I entered one whilst fully expecting it to be a won’t fix. A few days later I was pulled into urgent meetings to discuss the issue. It wasn’t known about by everyone…
Whilst it is important to not be “precious” about our bugs and it can be good to stand our ground, it is equally fair that a bug isn’t fixed because it is complicated to fix for a “niggle” (hence why you entered it as a low). After all quality is more than bugs/defects. If a team spent a month perfecting a button so it was beautiful and radiant across all browsers/devices, but never got around to having it actually do anything then the customer would view the feature as lower quality than one that had a visual defect when pressed but solved their problem. A bit of a silly example, I know, but you get the idea.
This comes back to my point about entering bugs. If someone decides that the time required to fix it would be better spent elsewhere then as testers/QA we should appreciate that. However by entering then closing that bug as won’t fix, we’re making a conscious decision that is recorded, rather than a verbal exchange.
You said you entered this as a “low” (though you don’t specify whether this is priority or severity), but the effort you’re putting in asking about it here, researching a fix, etc, sounds like it’s really a “high” priority issue in your mind?
It really sounds like you’ve let this become the “precious” bug that @oxygenaddict is alluding to, rather than contributing your input, and then letting the team decide what the steps are going to be for that bug during grooming or however your team prioritizes work.
It is the Way of the Tester to find and report bugs and other things that may impact the user experience. What the rest of the business does about it is their problem. The thing is, you have recorded it so that if it goes bad, you can say “I reported that six months ago.”
That’s not intended to be an act of covering your back; rather, it’s laying down evidence that will help fix things when either a) it goes bad, or b) someone who matters makes a fuss about it.
At some point, it may be reported that “this thing is happening” and people will say “we don’t know why that’s happening” and you will be able to think “that’s like that bug they declined to fix” and the bug report everyone has ignored up to now will suddenly give valuable insight and a clue towards fixing the bigger issue.