Q. What do you do when you find your product fails to meet the Accessibility standards which the requirements state it must adhere to?
A. Remove the requirement.
Quicker than fixing the bugs ennit?
Yes, this has recently happened.
Subscribe to:
Post Comments (Atom)
3 comments:
sadly I am not shocked or surprised
Sadly, I have seen similar:
Product A is tested by another facility, but integrates with Product B which we test. Product A required additional hardware for the full feature usage. (Additional hardware is additional money for the customer.)
Customers began to call in complaints about the product in a network environment. Since it was on the Product A side of integration, my "job" was to pass these bugs on to them. I was told by the lead tester of Product A that each workstation had to have its own hardware installed in order for the product to work correctly. (Hmmmm, really?)
Project Management changed the User Guide, in a hurry, to reflect this information.
After the third bug report came in, I decided to ask the programmer/developer outright if there was some sort of programmatic limitation. If the hardware could be networked and the software could be networked, why couldn't they communicate correctly? He said they could.
The noise of back-peddling was heard as everyone "found enlightenment". The product was almost 2 years old at this point.
It still amazes me that when we don't know something or can't do something, we prefer to hide it then say it. To me, it is fine for developers and testers alike to say "I don't know". That is the first step to learning something new as long as it comes with the desire to be able to "know" something.
So it seems that everything, including accessibility, is up for discussion about inclusion in a release when the deadline looms. What baffles me slightly here is that I thought there were legal requirements now for accessibility? If you're not bound by legal requirements then it's down to the clients demand for the features. And if the client isn't demanding it then as long as everyone else is happy with the change in requirement it is difficult to argue against the approach of removing the requirement.
I suppose in many ways it adds weight to the task of prioritising requirements up front. At least if you've prioritised them early in the requirements capture phase then it's harder to argue that a requirement should be removed if it is a high priority requirement. At least if you this prioritisation takes place up front then you prioritise in the cold light of day when there are no other influences about like the inconvenience of a deadline that has to be met.
William Echlin
www.SoftwareTesting.net/blog
Post a Comment