Following Jerry Weinberg and James Bach, I understand that bugs exist between product, user and environment.
It means that behavior that is considered a bug in one product isnât necessarily a bug in another product. One example could be Microsoft Excel incorrect treatment of 1900 as leap year - Microsoft explained that they needed to be compatible with Lotus 1-2-3, dominating spreadsheet at the time.
It means that behavior considered to be a bug by one person might not be a bug by another person. See social media discussions about pretty much any change in popular products for examples .
It means that behavior considered to be a bug in one situation might not be a bug in another situation. I generally donât mind recharging my phone every day, but it is a problem when I am hiking - away from power source, where phone might be needed in case of emergency.
But then, there are some problems that are âobviousâ and âuniversalâ, i.e. they are always bug and donât need explanation that they should be changed. One example might be application crashing. Another example might be application showing just plain background, with no controls. Yet another example might be form with no submit button or autosave feature - where data cannot be transferred anywhere.
Can you help me challenge Weinberg and Bach claim that all bugs are relative? What are some other examples of âobviousâ bugs?
Arenât all bugs as relative as one project/company is able or willing to fix it?
Does it matter whether it is a bug or not, it matters more whether it is important or relevant to fix it?
A calculation error may be really important in one situation, but not another. Budget. Contracts. Politics. Legalities. All have a play in the decisions.
And sure, a bug in one scenario, may not be a bug in another. Or maybe itâs just much lower on the priority/severity scale kinda bug.
I think anything that stops a user doing the task they need to be doing is an âautomatic bugâ. Like you say - a crash. Or a button not working. Or severe slowness/performance inadequacy.
Iâm not sure I want to challenge Jerry Weinberg or James Bach, but more clarification or links to references may be helpful to clarify my own thoughts.
Iâd say that the importance of a bug is relative - misspelling the product name on the splash screen/front page is always a bug, but whether itâs considered an important bug is a different matter.
At that, Iâve dealt with web applications that simply fail to start unless IE is used - which was a major pain when my primary system ran Linux. The organization did not regard that as a bug because they developed for IE only.
Unfortunately, I canât challenge Weinberg and Bach, simply because in my experience no matter what users say it wonât be a bug (and probably wonât be fixed) until the product creators agree that itâs a bug. Even then, it may or may not be fixed depending on whether or not itâs worth the time to the organization to fix it.
Iâm also curious about what Weinberg and Bach said.
Once the product is in the field, there are additional considerations. There are risks, some of which can lead to significant costs. Here Iâm thinking of systems for transportation, healthcare, banking, and their infrastructure. The need to fix such bugs may be obvious. You can still argue that they are relative when you rank them by cost. But when dealing with safety, brand reputation, or even bankruptcy, fixing the bug is part of the remedy.
You said âUnfortunately, I canât challenge Weinberg and Bach, simply because in my experience no matter what users say it wonât be a bug (and probably wonât be fixed) until the product creators agree that itâs a bug.â
Well, that fits their analysis as far as the definition of relativity between âproduct, user and environmentâ as long as you realise that there may be more than one environment. A business decision not to fix a particular bug is taken within the business environment, where different rules may apply. Iâve seen an online presentation with an appallingly egregious typo which appeared above a picture of the CEO and a voiceover from him. It was so bad, I got into a major argument with the Technology Director because (having bought this app in from a third party) he said that it âwasnât my jobâ to test third-party apps. Fixing that bug had low priority in their business environment. (Our employment relationship lasted perhaps another six months.) In a previous role though, not fixing that bug would have gotten me sacked. That level of bugfix had a far higher priority in that business environment!
Testing is context dependent so you have functional bugs and user acceptance bugs. Smth that isnât a bug for the dev can be a bug for a user and vice versa. Smth that is a bug for the user wonât be a bug for the dev.
If the user perceives smth as a bug then it is up to dev team to decide if they want to fix it or not.
The severity and priority will very much differ depending on time and costs(in terms of money that you have to put into fixing vs the impact on the user which can also cost you in the long run).
Risks should always be assessed individually I am afraid and there is no golden rule. I think that we as testers should do whatever we can to present issues to devs with all the info we could gather (repro rate and severity) and its up to them to decide : )
Arenât all bugs as relative as one project/company is able or willing to fix it?
Does it matter whether it is a bug or not, it matters more whether it is important or relevant to fix it?
These are very good questions and I appreciate you asking them. I didnât follow relativity path to the end and did not consider option that we should question the very existence and usefulness of âbugâ category itself. I think it deserves some deeper thought.
But then, Iâm not fully convinced that abandoning âbugâ is a way forward. I can see a value of differentiating between âthis is not a bugâ and âthis is a bug, but we do not have resources to fix it at this timeâ. If nothing else, we might want to find and review reports from the second category to see if maybe we can tackle them now. The first category can also be used as appendix/clarification of other requirement documents or to teach new team members about some mistakes that we did in the past.
Smth that isnât a bug for the dev can be a bug for a user and vice versa. Smth that is a bug for the user wonât be a bug for the dev.
Yes, but I am specifically looking for cases when something is a bug for user and dev (and tester, and product manager, and designer, and support person and whoever else you might have in the team), especially regardless of the particular product and context. Something that, when seen, can only be responded with âthis isnât rightâ.
unclickable buttons/functionalities (anything really that causes a blocker or blocks out the functionality of an application.
any 100% crash with easy steps to reproduce
Those are from the top of my head. No dev can argue those arenât bugs and would have to fix cause if they wonât, their reputation and usability and user experience will be damaged.
As previously mentioned, anything that prevents a someone using the product from doing a task they should be able to do.
This means that bugs are relative, as different users of the product will have different ways of interacting with it, different levels of proficiencies in using it and so they will be using the most basic functionality all the way up to the most advanced functionality. Therefore a certain user may or may not discover a problem.
.