How does typos, misspellings and bad language affect the product?

Hi everyone,

When I test a new software product, I always tend to see typos and cosmetic issues almost immediately. I always have a note book near, to write down such things. Later on I ask the developers what they think of those issues. But almost everytime I meet some kind of resistance, they might say it's not that serious or I don't know that language very good or something like that.

But personally, I think not fixing such issues will make the end user have lowered confidence in the product. And usability could be lowered as well. What do you think of those minor issues, do the affect the perception of the product in any way?

Best regards,
Michael

Views: 217

Reply to This

Replies to This Discussion

They can affect perception of the product - the user can think that if they cant get the spelling right then what else have they got wrong ? Though I've sat through UAT sessions where the users have not noticed some blatant errors - they just want to get the job done

From the programmers side I have some sympathy with the devs - in my programming days 90% of my time would be spend coding up some clever algorithm and then when that was working the UI would get stuck on the top of it and that was all a tester would notice and test

but without these mistakes sites such as QA Hates You would be short of material
Since I've never attended any UAT sessions or similar, I don't know how the customer thinks and acts. But since I quite easily discovers those minor spelling issues I think that there must be others like me. And if I'm paying for a product, I would like it to be as good as possible. Don't know where I'm going with this post... :)
I think that it really depends on the audience :-)

I know that we *try* to be very conscious about grammar and spelling mistakes in the product, and given they are usually very easy to solve we just make sure to fix them on the spot, there's not even an argument about it anymore.

Personally I see these kind of bugs as a low-severity / high-priority issue (and use them as examples when I explain the diff between priority and severity in my classes), and I support fixing them ASAP since you never know what will make the customer flip, something it may be the little things like cut icons or bad English.

My 2 cents.
I couldn't agree more. I also think they should be fixed as soon as possible, since I don't think there might be any good reason for keeping a typo in text.
"But almost everytime I meet some kind of resistance"

What kind of resistance are you meeting here?

Are the developers indicating that these are not actually bugs? Or that they are not important to fix? Or that they are less important to find and fix that other, far more severe bugs?

If you find a typo, write a quick bug report and move on. Let your bug reports speak for themselves. I'm not saying you do this, but in general, try not to get into a power struggle with developers where you insist that every single bug be fixed. Instead, let the team triage the bug list and give priority to fixing the bugs that matter for your business.
Well, the resistance is not defined. It can be everything from a deep sigh when commenting it, to people giving excuses and so on. Even if they accept that there is a typo or similar and a bug is entered, it's often not fixed before release. Instead it's postponed until next release. It couldn't be that hard to fix the issue if you know exactly where it is, could it?

But your suggestion with writing a bug report and move on sounds good to me. Most of the time developers wants me to talk to them before writing a bug report, but sometimes I manages to sneak one in :)
yup, I used to give it the Big Sigh and no, the fixes were really quick to do

Problem is, I was code-centric and a spelling mistake did not seem the end of the world and seemed such a waste of my time fixing trivial stuff like that when I had a brain the size of a planet ( yeh, if I was so **** clever why did I make stupid mistakes ! )

try to put yourself in the devs shoes - you seem to be ignoring 90% of the work they did and picking holes in the UI bits.

If it's a regular mistake then try giving the devs a UI checklist they can work through before making a release ( check spelling, check tab order ) or volunteer to give the UI a once-over before they commit to making the release
Hehe, yeah, I can imagine how it feels. It must be quite tough to hear someone "complain" about their work all the time. Thats why I always try to say something positive as well, like "this new function works in a really good was, user friendly and all, but... the instructions are missing..."

UI checklist was a good suggestion. Maybe I'll try that.
"Most of the time developers wants me to talk to them before writing a bug report"

Really? Why?
So they can decide if it's an issue or not?! Man, sounds quite stupid in writing :) Well, I guess they like to know before getting surprised with an issue-tracker-email. And often, they want me to test a few other things to verify something else, related to the actual issue found. Does this make sense?
(shrug) It might work perfectly well in your shop. It sure doesn't in mine.

In my shop, QA and Dev both have far too much work to do, which doesn't allow for vetting every bug report before submitting it. Very few issues are submitted which turn out not to be bugs. Those few are considered just part of the cost of doing business and are not a big concern.
Ah, I see. We are a quite small company with just one or two developers per project. And the release cycles are quite long (3-5 months up to a year) so there is always time to discuss. But sometimes, I guess the issues shouldn't be discussed at all, since they are so small :)

RSS

Adverts

Ministry of Testing

© 2014   Created by Rosie Sherry.

Badges  |  Report an Issue  |  Terms of Service