by Michael S. Kaplan, published on 2007/08/14 16:23 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2007/08/14/4389076.aspx
It was an old George Carlin routine, it went something like this:
And the pharmacist is always stoned, ever notice that?
Check his eyes, he's experimenting with something out there.
How come he can never fill a prescription right away?
He's always saying "Come back in an hour, I can't even read the fucking thing."
Today I was on the phone with a program manager from another group who had a problem.
They had some functionality that overlapped with international and the test team said "we have no time to test this" and then when pressed they admitted "we lack the expertise to test these languages."
I swear it was like I was back listening to that George Carlin routine, with testers padding their estimate to test a feature with an unspoken "learn what the hell the feature is."
But here is where we get into the real problem, the one that keeps testing of features from an international standpoint from being very complete. The fact is that you do not have to fully understand every language as well as a native speaker in that language in order to test the functionality.
I should repeat that.
You do not have to fully understand every language as well as a native speaker in that language in order to test the functionality.
First of all there is the functional testing -- this is something any tester knows how to do.
Give them a spec that reasonably describes the feature and nothing else and a good tester can do some black box testing based on it. Some pretty good black box testing, too.
Give them a design document, or access to the source, or some conversations with the developer and that same good tester can now do some basic, pretty decent white box testing.
This is true whether they are testing a keyboard (keystroke combination X leads to data Y bring output) or a sort (letter X comes before letter Y in that language) or encodings (Unicode character X maps to byte Y on that code page) or whatever.
And what is more, unless you are on the team that OWNS that keyboard or sort or code page, you don't have to test any of that -- all you have to do is test that your product gets the same results as the underlying functionality.
Leave it to the people who can answer the question about whether the data is right to the people who actually have that information, and especially to the testers who own the answer to that question.
Those people are the "informants", the ones who have that knowledge.
Now one could argue that my original metaphor is flawed since the pharmacist (whether stoned or not) does own the responsibility dispense the right medicine.
But I would tend to disagree, since if the prescription truly can't be read, the most common thing for the pharmacy to do is to call the doctor's office -- the "informants" in this case.
Testing is a job that is hard enough without suggesting that in order to test international functionality one has to learn a bunch of languages and scripts. Because even though that may be interesting or useful, no one can learn all of then, an luckily for testers it is not required....
Summary: FUNCTIONAL testing of a feature is not the same as VALIDATION of linguistic accuracy or customer expectations. Testers shouldn't fall into the trap where they assume because they can't do everything that they can't do anything. On the whole they are much better than that!
This post brought to you by ຂ (U+0e82, a.k.a. LAO LETTER KHO SUNG)