Comments (14)
  • Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

1 thartric commented Permalink

Govind, all great examples of situations we find our users in every day and need to be prepared to handle. Thanks for your expertise to help us be well prepared!

2 EiCoJ commented Permalink

This is great tips!
I think we should share I18N related technical information on My dW Wiki.

3 bobleah commented Permalink

Govind... fantastic testing advice here! When I was with Tivoli, we would have a test phase devoted to "destructive" or what we termed "malicious" testing. The development team always cringed... but our test team turned in some of their best work during this phase!

4 Jeffj2 commented Permalink

Govind, Great tips and nice knowing what is being tested "behind the scenes". Thanks for sharing!

5 Govind_Baliga commented Permalink

Glad you all found those tips useful.

@Bob - Our collective team test that's usually scheduled before big releases help us find good amount of issues as part of ad-hoc testing. Always helpful to learn from other team members on the different testing techniques and scenarios we use to discover various kinds of defects.

6 leahket commented Permalink

Govind, these are great tips, and I'm glad we're on the same side of the testing battle ;-)

One thing to keep in mind when you switch languages is that the caveats on the UI may need to change. For example, I have found instances where a 255 character limitation is valid when you are entering single-byte data, but is much less when entering double-byte data.
And something we are running into with the my dW UIs is the caveat that "only alphabetic A-Z, numeric 0-9" are accepted.. and then we find that actually DBCS character data as well as special european character data are allowed. When nls-enable code, its important for teams to test any caveats or error messages to verify they apply across all languages and modify the message as appropriate.

7 Govind_Baliga commented Permalink

@Leah - Appreciate your efforts to discover the differences related to various languages. Please e-mail me the list of issues you have found so far and we'll queue them up in ClearQuest to get them addressed in the next possible release hopefully.

8 SumaChakrabarti commented Permalink

I really liked the first paragraph where you have precisely explained about how one can determine that "software release has started to show improvements" ...

too lazy to type in those again so flicked that portion from your own para :)
Even in my team, we had collected this metrics and found that Ad hoc testing had yielded many defects.. and I guess its because the tester is not restricted to do only what is documented but at free will ...
I liked all of your tips .. great post !

9 shavik commented Permalink

Thanks for the tips!!! Great!!

10 PeterYim commented Permalink

Wow. Good tips Govind! Now I know what you have been testing on my stuff.

11 bobleah commented Permalink

@Peter: now that Govind has tipped you off on how he tests... you can hide your bugs better!

12 annebev commented Permalink

Now I know why you are the best!

13 brenny commented Permalink

This is a great list.

What is the idea behind resolution changes? Are you trying to check for UI behavior and rendering behavior?
The test to double enter the same form is a good one.

14 Govind_Baliga commented Permalink

@brenny - Often times changing the display resolution via the control panel will result in malformed UI. We have also seen similar behaviors in the UI while resizing the browser window. We want to make sure that there are no overlapping text/images when the user changes the settings on their platform. Validating consistent UI behavior is key here.