Karen Nicole Johnson

I started work on a new project and need to address search testing with a wide assortment of languages. And geez, this is a puzzle I’ve worked with before so I thought I would share some thoughts around the topic of search testing with multiple languages.

At the start, I look into how many languages and what languages I’ll be working with. Based on past (and current) experiences, I have certain reactions – from a testing perspective – to some languages.

Latin-based languages fall into one group. I used to think of English, Spanish and French as “different” languages but now I see these languages are rather similar from a test perspective. The same is true for any languages that use the Latin-based character set.

While Swedish, Slovenian, Romanian and other languages seem to me to represent languages with a heavy use of diacriticals. Yeah, I know the word diacriticals has a daunting sound to it but it’s the term to describe all those little character marks that some languages seem to use with more frequency. If you’re gone to test with different languages, it’s worthwhile to read up a bit on diacritic marks to understand what they are.

I’m highlighting diacriticals in the same way I think of certain characters in Latin-based languages – like names and words that use an apostrophe or an ampersand – two characters that still encounter issues frequently. It’s amazing how often ampersands and apostrophes are not handled well by software. Case in point, importing names and emails with apostrophes in Gmail from CSV files. If these examples seem far-fetched – consider the last name O’Brien and a company name like Smith & Bros.

Then I think about Right to Left languages like Hebrew and Arabic. And even after testing years (yes, years) of exposure to testing with right to left languages, I get disoriented having scrollbars appear on the left side of a screen as my eye is so trained to expect scrollbars on the right. Both entering characters and having the characters appear in the opposite direction on the screen as I type takes a mental adjustment. I adjust, and make UI checkpoints like scrollbars, bulleted listed and text alignment on search results.

Still there are more languages. There is another set of languages that I think of as more “symbolic” than character-based. This interpretation may be my own or widely-shared, I don’t know. But I think of Chinese, Singhalese and Tamil this way – there is no remnant of a Latin character. Instead these languages are more symbolic looking; in the case of Singhalese and Tamil, the languages seem lyrical and flowing while Chinese appears as singularly posed symbols, each with a story and meaning of its own.

From a database perspective, it would be more accurate to discuss the use of Unicode chars and using UTF8 vs UTF16. But I test with a mix of technical and logical insights as well as and instinctual reactions based on experiences.

So when it was time to choose a handful of languages to test with, my reaction was to choose:

1. one or more Latin-based languages
2. one or more languages with a heavy use of diacriticals
3. a RTL language

4. a language that is more symbolic than character-based

A common problem in testing with these languages is the lack of keyboard or a means of entering characters from different languages. Cut and paste can work if you’re careful.

As for where I get text from in all these languages – these three sources seem to have kept me supplied well.

1. content from the application I’m testing which is both handy and means that I’m using words are used within the application and likely to be words found in search results
2. user manuals -when I buy something like a new external drive, it often comes with a user manual in a mix of languages – I keep the manuals and use chunks of text
3. Wikipedia. The overview of a language generally includes a few phrases I can use and points out diacritics and other insights on a particular language.

It would be great to hear how other people address this type of testing.

I met a person working as a test contractor on a project recently who said to me: “There are no requirement documents so therefore I cannot write test scripts. And this means, I cannot test.”

I’ve heard this before from other test contractors. I don’t understand the logic being applied.

I tilted my head and was speechless. I thought I should keep listening to see if I could better understand. But I didn’t. In this case, it seemed the tester believed the only way to approach testing was to read and review requirements, write test scripts, and then execute test scripts. Since this one approach was not an option in the environment at that time, the tester felt dead-ended with his work.

Meanwhile I had my own immediate roadblocks to attend to. So here’s what my problem was, how I solved it and then I’ll loop back to the test contractor’s problem.

I was contracted to execute performance testing of an application. I didn’t have access to the application I was testing – by which I mean I didn’t have the needed permissions to access the application. I did not have VPN permissions so up to that point; I had not seen the application or knew much about the app. I had no previous experience with the application. In fact, I didn’t know what the application looked like or how to navigate around the application, the type of data the application worked with. So I was feeling a bit stuck to be certain. But I did have access to the physical environment, other people on the project and to a SharePoint site although the SharePoint site had so many documents on it that I was overwhelmed with no sense of where to begin.

But I’ve been in those shoes before – meaning I’m at the start of a body of work but all I can see is a dead end not a beginning.

I was so frustrated at one particular point that I sat myself down and kept asking myself one question over and over in an internal (admittedly loaded with mix of frustration and somewhat sarcastic internal voice) brainstorming style. My question: What can I do? Note the word can is in italics as I felt painfully aware of what I could not do.

I’d prompt myself, well … what can I do? I pulled out a pen and notebook and decided to write a list. A list of possible next steps that I could pursue on my own would certainly make me feel better. And maybe unlock my problem somehow. Here are some of the items I wrote:

• I can talk to person X, the lead project expert on the application and see if she can give me an overview of the application.
• I can listen to the other contractors – not the testers but the developers and designers and learn what project concerns they have (including concerns that don’t make it project status reports).
• I can call the Help Desk again and appeal to them to escalate my request for access.
• I can begin writing a test plan because even without access to the application, I know what I want to test and what I plan to do once I can get started. I can update the plan later as I learn. And writing always helps me clarify my thinking. And with this client, written material will end up being needed so sketching out a draft now might be useful.
• I can pretend for a moment that I have access to the application. What is it (one item or a list of activities) that I so badly wish I could do?
• I can talk to the project manager to hear what expectations she might have of me. (And see how it matches or does not match to the person who brought me onto the project.)
• I can talk to the other testers and see if I can hear their thoughts on testing, the application, performance concerns, anything – who knows where that might lead me.

I shut my laptop off. I walked around. I talked to people. I started learning whatever I could. I felt better. The physical movement helped. Not feeling trapped at a desk focusing on what I could not do helped.

I did as much as I could that day and then I left. I had another project for another client to work and I told myself maybe tomorrow would look better.

It was days before my access was granted and I was finally able to login and see the application I was scheduled to test. When I finally logged into the application after so much aggravation getting to the starting point, I froze for a few minutes – now what? But instead of feeling stuck, I thought about what the project expert had taught me about the app. I pulled out my notes from our session together. I found my way around the application. I started to become unstuck.

So now let’s wander back over to the test contractor’s problem. He believes that having no requirement docs means he cannot create test scripts and therefore cannot test.

In the language of my teenage daughter: Really? (Really is a favorite word of hers and as a result (sadly) is deeply injected into my language as well. Note that the tone of the word “really” is the essential ingredient.) You really cannot do anything to proceed because you don’t have a document. Really?

To-do lists are common. We all slave away at battling to-do’s versus the amount of hours in a day – nothing new there. But a can-do list is empowering. It reminds me to seek another path, find another way. It doesn’t fix roadblocks that need to be resolved but building a can-do list (versus a to-do list) helps strengthen me when I feel down or defeated or stalled out – really.

I don’t need a document to learn an application. I can investigate in ways I identified, and there are other options for learning as well – blogs and forums can help with the reality of an application over a requirements doc any day. As a tester, I should have enough curiosity to get learning and start my work with more than one approach – I may have a favorite approach or a familiar approach to my work but I should be able to see beyond one approach. Next time you think you are stuck ask yourself: really?

Here are two articles I published this month on testing.

“Improve Your Testing and Your Testers with Paired Testing”
Ideas and stories on paired testing
InformIT, April 2010

“Insights from Running UAT Sessions”
Four insights you can gain from user acceptance test (UAT) sessions.
SearchSoftwareQuality, April 2010

And a recent article of mine on regression testing was translated into Russian “A Heuristic for Regression Testing.”

You can find a full list of articles I’ve published on the publications page of my website.

This afternoon I was talking with a friend and colleague who asked me about my writing, more specifically about software testing articles I’ve written. He was surprised to learn that I had published six articles in the past couple of months – he hadn’t realized that I wrote so much or so often. I thought most certainly I had listed the articles on my blog as each article had been released but it doesn’t look like it. Here’s a list:

“A Heuristic for Regression Testing”
SearchSoftwareQuality, March 2010

“Women of Influence: A Diverse Group of the World’s Top Women Software Testers Share Career Highlights And Insights Into the Profession, Past, Present and Future”
Software Test & Performance Magazine, January 2010

“Testing SMS Texting Applications”
SearchSoftwareQuality, January 2010

“Manipulating Business Intelligence to solve dense data warehouse testing issues”
Understanding the testing challenges associated with data reconciliation on a Business Intelligence (BI) project. Part I.
SearchSoftwareQuality, January 2010

“Testing data fields in business Intelligence projects”
Testing data reconciliation on a Business Intelligence (BI) project. Part II.
SearchSoftwareQuality, January 2010

“Tips for Better User Acceptance Testing”
InformIT, December 2009

You can find a full list of articles I’ve published on the publications page of my website.

I have an article about working on virtual teams that will be coming out on InformIT soon – probably within the next two weeks. I have another article on user acceptance testing (UAT) to be released by SearchSoftwareQuality soon. So yes, I have actually been quietly writing quite a bit about testing in recent weeks/months.

Someone asked me recently why I don’t participate more in software testing forums. Why I don’t blog more often. Why they don’t find me “around” virtually as often as they used to. Balance was my answer.

My online life was becoming consuming. And it’s easy to get out of balance especially when you live in a climate like Chicago where its winter for eight months (or at least feels like it.)

But I’ve been pushing in my chair and walking away from my desk, focusing on other parts of my life. I’ve been exercising more. Reading novels. Writing short stories. Spending more time with friends. I decided this would be the winter I would learn to cook and wow, what a difference that has made. I’m gearing up for another furniture restoration project, a hobby of mine.

What does balance have to do with software testing? Plenty. Software testing is largely about being observant. If your eyes aren’t fresh, if you’re not rested, if you haven’t exercised or moved in hours (and perhaps days), then how alert or observant can you be?

I understand the long days in software testing. I’ve burned through many and I feel certain I will again.

James has blogged about using time to learn when business is slow. I admire that. I admire it for a couple of reasons: 1) it’s important to keep learning and 2) it’s true that as a consultant and business owner, there are lulls in business. I’ve seen the cycles myself a few times over now that I’ve been independent for a couple of years. I learn a lot in those quieter business stretches. Sometimes I learn a lot about myself.

I have gained a better sense of what my real interests are. When my energies are waxing and waning. I’ve gotten comfortable with my notable cycles of intense focus (whether reading or writing) and times that I feel like I have attention deficit disorder. I’ve identified activities I really don’t like to do but that I used to blame lack of time as the reason. Imagine removing time as your block to find (and admit) that you just never get to some activities (or magazines) because you just don’t enjoy them that much or perhaps not at all. It’s freeing to admit, I’m just not that interested in X (insert activity here) than using lack of time as a shield.

Sometimes when business is slow, I read books in software testing and explore new tools. Sometimes as in recent time while business has been quiet, I haven’t read anything in software testing – and that break – unexpected and unscheduled has been a good one. I find I’m hungry now to test again. I miss it and I think that’s a great thing. It means I’ve had a real break and when I’m back to working more, I’ll be ready. Rested and ready.

I use colors on the activities on my calendar. Client time, time to write, time to exercise, time to attend to activities related to having my own business, time to update my class materials … I have several ongoing categories in my life. Now a fairly quick glance at my calendar reveals days and weeks that are well balanced versus time or days that are heavily focused in one direction – which is perfectly fine as long as days heavily-loaded in one category don’t stack up to too many days in a row. Using a color-coded calendar has helped me more readily observe balance issues (it’s just another form of data visualization but I’m not going there today.)

So I could fine-tune this blog, fuss over it but it’s time to move on. When you balance your time well, there is actually time for everything you care about.