The definition of a bug is the product is not working according to design. use case is not working accordingly.

Bug vs. Feature Request. It’s a painful and arbitrary decision, because most of the time, it’s both. There’s no difference between a bug and a feature request from the user’s perspective. If you want to do something with an application (or website) and you can’t do it because that feature isn’t implemented — how is that any different than not being able to do something due to an error message?

vendor gets those strings but they missed a string, who’s responsiblity is it.

When you get a lot of bug fix requests from the client, how do you address it?

Anatomy of a bug
issue definition; if it is in only one language usually it is considered ia bug
priority and severity
status
configuration
localization specifics

When you get a lot of bug fix requests from the client, how do you address it?

from Kien Vu to Everyone:
Most translation vendors that i have worked with generally have the fonts and whatnot.
from Bob to Everyone:
Megan’s example could happen with any type of file incompatibility: XML, HTML, RTF, etc.
from Michael Maas to Everyone:
Absolutely.
from Bob to Everyone:
It shows that you have to be careful about assumptions!
from megan finaly to Everyone:
yes. you are right. I had no idea the printer would do that to my file and make changes in it.
from Bob to Everyone:
Yeah, some of those cases are hard to predict.
from Mark Cruth to Everyone:
yes, you have to put everything in the contract. I worked on an outsourced project that was burned by not specifying the software that should have been used
from Bob to Everyone:
I had similar problems in filmmaking where there were all sorts of different (and incompatible) formats.
from Bob to Everyone:
This sounds like the requirement for 9-track tape ๐Ÿ™‚
from Mark Cruth to Everyone:
LOL
from Kien Vu to Everyone:
We had issues with that as well. We went with an overseas translation vendor since they were cheap. Unfortunately, they didnt put translations into memory, desktop publishing fees were enormous, etc
from Bob to Everyone:
Would this sort of error show up in a pseudo loc test?
from Bob to Everyone:
So wouldn’t content tool selection be part of your internationalization review?


The tools you use for localization, make sure you have the same tools, software. Font is a major issue. Someone will has to bear the cost of it.
Siemens font is customized and weighs 25MB! Think about loading that onto a mobile device or deliver within web content. And think about all the other languages that have to be represented in that font; cyrillic, japanese, etc.

Priority vs severity of a bug
Severity
1: sys crash or data loss, major legal problem, geopolitical issue
2: major funcitonality loss
3: minor issues, cosmetic problems

Priority
1: fix as soon as possible
2: fix soon
3: fix if time permits

Status of bug
Active: bug still needs to be looked at or worked on
Resolved: bug has been investigated and worked on; a decision has been made to either correct it or postpone it
Closed: the resolution of the bug has been verified by the person who ORIGINALLY opened the bug

Resolution
Fixed; corrected
Not reproduceable; could not reproduce
External; this is a dependency on an external partner and does not affect any code or component inside your product
Postponed; bug is postponed
Won’t fix; bug that is minor and will probably disappear by the next version
By Design
Duplicate

Reasons not to fix; cost, priority, risk of breaking the software or introducing more bugs

<what about the person who put together the spec and signed off on the contract doesn’t know so well about the internationalization process and the kind of bugs you would find, and the bug list becomes a battlefield. >

Types of bugs we care about
Globalization; this is code problem with the core sw
Localizability; what is my ability to translate this? Is it easy enough to do with my existing process? embedding HTML 5 in the the .dll file…it won’t load the HTML5. sofware works fine, but cant efficiently localize. screen saver file name, if you put a code like the fish name, then it can be done. it adds work for the team.
Localization; Linguistic and Functional. For functional testers; they will use Eng app on one side and another language on the right and do the same test on the localized file. Linguistic testing need to be a native.

Type of Bugs
Localization (L10n) bugs; are usually language specific. translation strings issue. (Microsoft calls it Globalization) and in one language
Internalization (i18n) bugs

Examples of International bugs
– text not displayed correctly
– truncated text in dialog boxes or buttons, there was not enough allowance made for text expansion
– system crashes; longer translated strings overrun the buffer. if the translation has more characters than expected.
– translated text isnt grammatically correct or makes no sense; soncatenated strings
– locale (dates, time, currency, etc) info is incorrectly formatted; data may be hard coded. You need to keep an eye on those programmers to make sure they do that. There are often several ways to code things like that and the international versions are sometimes more complicated to use.
– functionality problems; functionality (in hot keys, etc) may rely on some strings being identical
when designing a dialog box, allow for additional space for the languages that use up more space

Over Localization
when non localizable resources are translated and it breaks functionality
Non localizable strings may include;
-folder names (or maybe anchor links)
– registry keys
– Microsoft “Word” shouldn’t be localized

so sometimes you need to pull out those strings (such as the word “jabber”) from the translation file

Sometimes words from one language are not usable in some other languages…. like the word bing
from Divya Addepalli to Everyone:
MS Bing
from Divya Addepalli to Everyone:
meant something like disease or something …. I am not sure
from Divya Addepalli to Everyone:
And there are so many such terms in the Indian languages that we can not use in other indian lanuages
from Michael Maas to Everyone:
Interesting…
from Divya Addepalli to Everyone:
Sometimes becuase of the different dialects in the same language
from Bob to Everyone:
My documents
from Michael Maas to Everyone:
That is a good one.
from Michael Maas to Everyone:
That is prolly why it is a “special” folder with a UID reference.
from Bob to Everyone:
But if you’re documenting it, you’d need to know whether it should be translated in the documentation or not. That would trip me up!
Just another example of how you can’t just “bolt-on” localization at the end ๐Ÿ™‚
If you are referencing it in documentation to the end user, you may be fine with leaving it in English.

Best Practice – prevention!
educate developer about globalization and localizability best practices. so separate out, okay this is a parameter name, the is a reference tag link, so we define those elements so people, translator know what to translate.
test and fix intl bugs before localization begins
encourage pseduo-localized build testing before localization effort starts; take a language and run a pilot project, even if you only have one week to do tests. in the end this will save you a lot of money. you don’t want to have that bug in all languages. you want to find it early on.

Cost of fixing international issues; cost goes up as you get through the different phases, from design, coding, testing, localization. YOU WANT TO DO INTERNATIONLIZATION TESTING
the way you work it out is by looking at the expectations of how much intlization awareness they have. if they have never done it befoer, then you quote more hours for bug fixing.

software testing, bug tracking; http://www.softwaretestingstuff.com/2007/10/mercury-quality-centre.html

Purpose of bug triaging
– understand real project status
– move the sw project towards stabilization
– manage risk
– inform stakeholders

Members of BRC
-QA
– Engineering
– Product mgmt
– Project mgmt
– other stakeholders

Role LPM
– driver
– communication & coordination
– facilitate other roles
– ensure things are done as scheduled

Working with client test team
-get time est for testing, and allow enough time!! TEST, like localization often gets squeezed in at end of project. what is my testing scope? what have i cut out to do. squeezing more tasks in the last part of schedule
– are their tools globalized?
– how best to file localizability and globalization

Working with test vendors
– trends; functional and linguistic testing is often outsourced to china, india or eastern europe
– provide clear hand off, training and schedule to vendors
– detailed checklists/test plans to distinguish test coverage (make sure you are using the same measures)
– provide sample reports, explicit process for logging bugs. be clear. you have to frame exactly how you want the bugs to be reported, especially the description field or the bug report.
– be aware of infrastructure limitations
– keep them in the loop

Types of testing and ownership
– US/client test team generally owns
– intl sufficiency functional testing
– globalization testing
– localizability

– localization testing owns the UI,

Managing bugs
You only know if your project is on track if you a good
You need to categorize the bugs

reference i found; http://netbeans.org/community/issues.html

Advertisements