I was submitting a proposal for a paper for STC 2009 conference. After completing all fields – about 20 of them , I accidently hit clear button (by practice – “OK” or “submit” button appears first in such forms) and all that I entered is “gone” – worst there is no way to recover.
Is this a bug?
Another catch – for the date field – no format is specified, neither there is a calendar control. How do I find out the required format? Try one and get to know about the format.
Is this a bug?
If you were a tester who would strictly go by “test cases” generated out of “specifications” – you are likely to miss such bugs – remember there is something called “Requirement based testing”. Alternatively, you might argue that these are not bugs or bugs of low severity. Who has the final authority to say which is a bug and which one should be fixed and when?
Shrini
11 comments:
As always this is decided by the person at the top,he first decided whether this is a bug then whether to fix it or not.As a tester I am the first customer of the product and this is certainly a usability issue.
Bugs? Yes, but not functional bugs. They're usability bugs. The calendar one can be fixed by adding a format example to the text. The other one (I've encountered bugs like it on other forms) does need to be fixed by ensuring that Windows conventions are followed.
Sorry, Chris, you don't get to decide unless you're the project owner. Suggestions are welcome, to a point.
Note that usability issues are a problem, but if they make the product harder or slower to test, they're testability problems too. That's important, because anything that slows down testing gives each bug just a little more time to hide.
And note that one of the worst testability problems is having lots of problems to report. That slows down testing enormously.
---Michael B.
Both these are bugs and certainly high priority ones that needs to be tracked to closure. However I'd check if these were part of the requirements or GUI specifications before logging the defect. If these were part of requirements/GUI specs then it needs to be assigned to the developer. In case its not part of requirements/GUI specs, i'd assigned the defect to the GUI designer/requirements analyst to include this in the requirements/GUI specs.
I don't necessarily care whether the project owner classifies them as bugs or not. I get to report behaviour that is non-standard or problems with usability.
And, of course, in some establishments the tester or test manager is the person who decides. In another establishment I worked in, the development manager decided.
I suppose the answer is "it depends."
Usability bug i'd say. We too have to follow Req based testing but we always add exploratory and usability on top of it. Here is just some more notes on Usability: http://geek4eva.logicx.co.nz/blog/2009/09/05/usability-testing/
Yes, these are bugs but not functional rather usuabiity issues and related to UX (user expereince).
As far as the decision is concerned to fix, its the job of product owner to decide its priority.
Nice post.
These are bugs which causes user inconvenience.It is not a good idea to depend only on test cases to find bugs. Exploratory testing should be added to your test schedules!
There is an interesting article in the Register about what they call a "glitch" in Google Maps, where businesses are aggregated together although they are separate businesses.
The last paragraph says it all: "This isn't actually a bug by Google's definition. But from a business owner's perspective, it's absolutely horrendous" according to one business owner.
Isn't actually a bug?? Really?? Truly??
I go with Michael... Project owner is the boss and he is the one who pays for whatever we discuss. So it ain't a bug as per the requirement if it is so. These are value additions that can be discussed with the client/ project owner and can be added as a requirement separately.
For Srini, " Who has the final authority to say which is a bug and which one should be fixed and when?"
Obviously it is the Project owner. Smart act of a test engineer lies to the limit of providing value additions and not identifying bugs in the product which is strictly adhered to the specified requirements.
I believe a tester's role starts in identifying the glitch right from the requirement phase. So this can be easily identified when specifying a detailed requirement or design on the application.
As per me, it is the user. At the same time, a tester can always highlight such usuability features to the users thru exploratory testing. In the given eg, we can also compare with other screens(for same functionality to match) and take decisions.
Post a Comment