Quote:
Originally Posted by Josieb1
I, at least for the next six weeks, test software for a major organisation. I worked through Examples 1-3. IF they had been spotted in testing, and that would only be if the same team or testers tested all three examples, or if the results didn't match the test scripts or documentation (not an automatic given here) then they would no doubt be marked as cosmetic and made a low priority, or even postponed to fix at a later date.
I get that it bugs you but the functionality works, it's just cosmetically they don't match.
NB: I said six weeks as I'm being made redundant. (Yes I'm happy)
|
Testing software is not the same as writing software "or" having some GUI style guides that prevents these things to happen in first place.
These are not just "cosmetical" issues as you say. They can already be a programmatically issue by using deprecated API calls or a mixture of older Toolkit libraries and new toolkit libraries or hardcoded window and GUI elements etc..
The problem starts at the beginning and not later on! If there are no GUI styleguides and no real quality assurances, then these problems inherit from version to version and will never be dealt with or get fixed.
Now you make these things "low priority"... Then the next Kindle firmware pops up and inherits new graphical glitches and issues... you mark them "low priority" again... Now you have the previous low priorities add up with the new low priorities and you end up in a graphical mess.
How many Dialogs and Windows do we have in the Kindle firmware ?
Let's pretend there are around 50 Dialogs and Windows at all.
Each Kindle firmware update isn't a full rewrite! They compile new updated libraries, use a new wayland display server, compile with compiler flags... Between Kindle firmware versions there is time enough to sort these things out. But things can only be sorted out if the problem case is being understood.