16

Testarea software-ului internaţional

Am câtiva prieteni care sunt ingineri specializaţi pe testarea de software care ar fi surprinşi de alegerea mea de a plasa acest capitol la sfârsit, întrebându-se de ce am ales sa vorbesc numai in cele din urma despre cei care testeaza. Exista doua motive foarte bune pentru aceastã alegere:

• Este evident cã testarea se face de obicei dupa ce produsul este creat si nu înainte, ceea ce justificã plasarea acestui capitol la sfârşit.
• Munca persoanei care testeaza se suprapune atat de mult cu informaţia conţinutã în aceastã carte încãt daca un aş fi separat-o ar fi existat un milion de referinţe de forma “notã: a se testa” pe parcursul întregii caţti.

Aşadar, acest capitol va funcţiona ca partea cea mai importantã pe care o persoanã care testeaza dar care nu a întâmpinat niciodata probleme iL8N nu ar dori sã o treacã cu vederea. Dacã dumnavoastra sunteţi un productor, ar trebui sã citiţi cele ce urmeazã, în caz cã testerii dumneavoastrã se hotãrãsc sã cumpere aceastã carte şi doriţi sã reduceţi erorile de computer.

Cel mai bun punct de început este hotãrârea a ceea ce trebuie testat.

Planificarea materialului de testare

Primul meu punct nu este foarte convingãtor pentru ca testarea nu trebuie sã aştepte pânã când produsul este terminat ; testarea începe din momentul în care testerul recapituleazã specificãri şi face estimãri despre durata testãrii produsului descris. Acesta este un factor important în determinarea caracteristicelor care trebuie eliminate si considerate pentru versiuni mai târzii când existã mai mult timp la dispoziţie. Aceasta secţiune analizeazã chestiunile de care trebuie sa se ţinã mereu cont.

Existã numeroase configuraţii care pot fi folosite pentru teste, iar eu am încercat sã le rezum in Tabelul 16.1.

Tabelul 16.1. Imprejurãrile de testare care trebuie luate în considerare

Categorie	Sistem de operare	Setãri	Hardware
1	NT/Win2K	Set de setãri regionale la alte localizãri	U.S./oricare
2	NT/Win2K	Categoria 1 plus tastatura localã instalatã	U.S./oricare
3	Win2K	Categoria 2 plus schimbarea limbii de operare	U.S./oricare
4	Toate	Sistem de operare complet localizat (in Win2K, schimbaţi limba via MUI)	U.S./oricare
5	Toate	Sistem de operare complet localizat	Localizare specifica

Bineînţeles, testarea cu categoria 5 din tabelul 16.1 va gãsi cel mai mare numar de erori legate de iL8N, dar de multe ori nu este practic sã se intaleze versiuni în multiple limbi ale sistemului de operare pentru a realiza acest lucru. Sunt trei puncte care trebuie luate in considerare:

• Testarea in Windows 2000 este metoda cea mai inteligenta si eficace financiar pentru a testa comportarea altor aplicaţii deoarece puteţi schimba opţiunile regionale si limba de funcţionare a sistemului cu uşurinţã. Deasemenea, puteţi extinde abilitatea de a compara limbi cu serviciile terminale ale lui Windows 2000.
• Pe mãsura ce treceţi prin cele patru opţiuni din tabelul 16.1, cantitatea de munca depusã pentru a testa produsul va creşte in mod semnificativ (cam de 10 ori mai mult cãnd veţi ajunge la categoria 5).
• Numãrul de erori pe care nu l-aţi fi gãsit cu una din configuraţiile anterioare din tabel va descreşte in mod semnificativ (in general, mai putin de 1% din defectele care ar putea exista vor fi gasite sub categoria 5).

Cu aceste menţiuni în minte, acum voi analiza fiecare categorie în parte. Decizia de acoperire a categoriilor nu aparţine mereu de tester în mod direct. Cantitatea de munca ce urmeaza sã fie depusã de cãtre tester pentru acoperirea produsului este vitalã, aşa cã informaţia trebuie consideratã cu multã atenţie si balansatã in legaturã cu alţi factori cum ar fi cerinţele pieţei.

Categoria 1: Setãrile regionale

Cele mai importante defecte care vor fi gãsite aici sunt relaţionate de chestiunile de bazã ale lui iL8N din partea intâi a carţii: Poate data sã fie introdusã corect şi este data introdusã, manevratã şi produsã corect? Aceste lucruri sunt aplicablie problemelor cu valori de datã/ timp, valorilor numerice, si monezilor? Ce se întamplã când setarea unui calendar se schimbã?

Aceastã testare trebuie centralizatã pe panoul de control. De multe ori, cea mai bunã metodã de a testa o aplicaţie este prin a avea limbi bizare pentru setãrile regionale – poate chiar şi formatãri de tipul customize uneori. Când va referiţi la erori, descrieţi clar setarile folosite pentru cã pot fi foarte greu de ţinut minte dacã setãrile sunt schimbate des. Nu existã nimic mai frustrant pentru un tester decât a gãsi o problemã şi a nu fi în stare sã o gãseascã din nou mai târziu!

Pe lânga testarea generalã a anumitor setãri, este important sã vã concentraţi asupra unor configuraţii pe care utilizatorii le vor avea. Sã nu credeţi cã testarea generalã este o pierdere de timp. Cel mai bun loc pentru a gãsi erori unde nici producãtorii nici testerii nu s-au gândit. Deasemenea, vã va da mai multa încredere când noi pieţi vor fi luate în considerare.

Categoria 2: Localizarea inputurilor şi pãstrarea datei

Toate erorile din categoria 1 pot fi gãsite; pe deasupra, veţi cãuta erori legate de inputul caracterelor native si pãstrarea lor. In general, cantitatea de muncã pentru categoria 2 este asemãnãtoare cu categoria 1, aşa cã este bine sã luaţi în considerare o acoperire mai mare pentru acelaşi cost în termeni de planificare.

Bine înteles, scenariile se multiplicã când acoperiţi mai mult, aşa cã trebuie sã vã asiguraţi cã aveţi persoane care testeazã care sunt pregãtite sa schimbe setãrile mereu – în moduri mai puţin cursive decât în categoria 1.

Categoria 3: Limba sistemului de operare

Toate defectele din categoriile 1 si 2 pot fi detectate, şi un nou şir de erori este posibil cãnd cautaţi erori legate de caractere native pe alte pagini de cod si când vã uitaţi la modul în care aceste aplicaţii sub testare se comportã în aceste locuri.

Are sens sã planificaţi testarea unor familii specifice de limbi, cum ar fi urmãtoarele (Fiecare obiect în aceasta lista include tipurile de erori gãsite în alte familii).

• Cel puţin o limbã pe aceeaşi pagina de cod necesitã o diferitã cantitate de spaţiu ocupatã de text – germana sau olandeza sunt un exemplu bun dacã incepeţi din Statele Unite. SUA este un exemplu bun dacã sunteţi în germanã sau olandezã şi vreţi sã fiţi siguri ca dialogurile sunt acceptabile când mai puţin spaţiu este folosit.
• Cel puţin o limbã pe altã paginã de cod – greaca, rusa si turca sunt exemple bune dacã începeţi din SUA sau Europa de Vest.
• Cel puţin o limbã asiaticã – chineza, japoneza, si koreana sunt exemple bune, unde japoneza este alegerea cea mai obişnuitã.
• Cel puţin o limbã bidirecţionalã – araba si ebraica sunt exemple bune, cu toate cã araba va gasi mai multe erori, datorita naturii iregulare a caracterelor ebraice cu puţine reguli de contur care afecteazã caracterele limbii.
• Cel puţin o limbã de scris complex – tailandeza si vietnameza sunt exemple bune pentru ca au ceva din forma scrisului complex sau întreruperea liniilor în care este bine sã se testeze comportarea aplicaţiei.
• Cel puţin un unicod – o singurã limba – hindi este un exemplu bun.

Bineinteles cã nu este necesar sã alegeţi toate aceste categorii. Spre exemplu, numai dacã vreţi sã investiţi mult timp în partea a doua a acestei cãrţi si în suportul aplicaţiilor multinaţionale, trebuie sã dedicaţi tot atât de mult timp limbilor unicod (puteţi asuma cã nu vor funcţiona pur şi simplu).

Categoria 4: Sisteme de operare cu localizare falsã.

Aceastã categorie poate gãsi toate erorile din categoriile 1, 2 si 3 (cu toate cã acoperirea categoriei 3 depinde de alegerea limbii). In general, noile erori pe care le veţi gãsi vor fi legate de componente (care includ dialoguri comune sau componente localizate cum ar fi Internet Explorer sau Microsoft Office) oferite de sistemul de operare, care pot varia cu fiecare limbã.

Interfata de utilizare multilingvã Windows 2000 (MUI) si pachetele lingvistice din Office 2000 sunt metodele ideale, si chiar unice, de a tasta aceastã categorie; oricum, merita sã considerati dacã aveti dependinte puternice de aceste componente in AUT.

Categoria 5: Sistem de operare cu localizare corectã

Aceastã categorie este ultimul nivel de testare care gãseşte erori în toate celelalte categorii (câte erori din categoria 2 sunt gasite depinde de alegerea unei limbi). Resursele necesare pentru a testa acest scenariu sunt de multe ori pera mari pentru a fi considerate în mod realistic, chiar dacã aveţi un produs destul de mare si planificaţi sã automatizaţi testarea lui.

O subscriere MSDN Universal sau Professional este necesarã aici pentru cã vã poate aduce versiuni localizate ale sistemelor de operare. Petrecerea timpului în a învaţa cum funcţioneazã setãrile automate este o idee bunã pentru limbile pe care nu le cunoaşteţi pentru cã nu va trebui sã petreceţi atât de mult timp facându-vã griji despre mesajele de eroare pe care nu le întelegeţi în timpul setãrii (lucru pe care îl ştiu din proprie experienţã).

Alegerea unei categorii din tabelul 16.1

Alegerea unei categorii poate fi complexã, şi rare ori veţi gãsi o problemã mai complexã care are nevoie de o analizã din punct de vedere financiar si beneficial. In general, cel mai bun echilibru este oferit de categoria 2 cu anumite verificãri în categoria 3. Pe mãsurã ce deveniţi mai familiarizaţi cu producãtorii şi testerii din organizaţia dumneavoastrã, nu veţi deveni numai mai sofisticat în testarea produsului, ci şi cei care dezvoltã produsul vor înţelege mai bine problemele si vor produce mai puţine erori i18N.

Instalarea aplicaţiei în curs de testare

Cu toate cã acest pas pare arid, vã pot asigura cã nu este aşa. Este important sã se instaleze pe un sistem de operare localizat şi sã se rezolve chestiuni cum ar fi faptul cã direcoarele comune (cum ar fi fişele de programe) au nume localizate. Acest lucru poate reda douã tipuri de probleme:

• Programul nu este instalat în locul corespunzãtor.
• Programul are probleme cu instalarea în locuri care includ caractere native în directionare.

Acestea sunt tipurile de probleme pe care le veţi testa cu fiecare instalare.

Pentru modul dumneavoastrã de testare când setaţi aplicaţii care folosesc server SQL, serverul de testare trebuie sã fie senzitiv la fiecare caz pentru cã astfel se pot descoperii probleme cum ar fi cele cu I-ul turcesc pe care le discut în capitolul 4, probleme de interfaţa ale utilizatorului, şi în capitolul 12, Jet, Server SQL şi alte baze de date. Alegerea diferitelor servere poate gãsi probleme de asemenea. Setarea corectã a serverului SQL poate evita probleme care ar fi gãsite de consumator. De obicei reinstalarea serverului SQL cu diferite preferinţe este o modalitate bunã de a gãsi erori care altfel ar fi ignorate.

Executarea cazurilor de testare internationalã

Subiectul despre realizarea specificãrilor care enumereazã importante scenarii de testat (de asemenea cunoscute ca o specificarea testãrii , care contine cazuri de testare) este bineînteles în afara obiectivelor acestei cãrti. Cu toate acestea, voi enumera numeroase chestiuni care trebuie tinute minte pe parcursul creãrii cazurilor de testare pentru AUT.

Lucruri care trebuie ţinute minte pentru i18N

Pentru aplicaţiile globalizate, iatã un exemplu de tipuri de probleme de care vreţi sã ţineţi cont.

• Verificaţi fiecare loc unde puteţi introduce data, timpul, moneda, sau numãrul în fiecare loc care acceptã aceste valori in AUT. Asiguraţi-vã cã le puteţi introduce în formatul corect. (Vezi dialogul despre setãri regionale pentru a gãsi aceste lururi la locul potrivit).
• Verificaţi locurile unde AUT face comparaţii, validãri, sau calcule de date, timp, monezi sau numere. Acceptarea valorilor formatate corect nu oferã o garanţie cã aceste calcule despre valori înţeleg formatul.
• Verificaţi fiecare loc unde puteţi introduce caractere native în text. Introduceţi un amestec de caractere englezeşti şi strãine.
• Asiguraţi-vã cã caracterele native sunt afişate corect dupã ce au fost introduse. Dacã caracterele native necesitã un font special (spre exemplu, japonez) care este aplicaţia dvs, cea care instaleazã fontul în maşinã (sau sunteţi sigur cã va fi disponibilã pentru fiecare instalare de Windows)? Dacã caracterele native necesitã un font special pentru afişare, trebuie sã verificaţi fiecare aplicaţie unde textul este afişat în GUI (în mod tipic, fiecare control are o proprietate de font care poate fi setatã individual).
• Introduceţi numãrul maxim de caractere (folosind caractere native) în fiecare dimensiune diferitã de control in GUI. Deoarece caracterele unicod si DBCS ocupã de douã ori mai mult loc, controluri pot apãrea pentru şiruri mici, dar nu au alocat destul spaţiu pentru şiruri mai mari.
• Uitaţi-vã dupã probleme legate de conversiuni proaste de la sistemul unicod la ANSI, care de obicei aratã un semn al întrebãrii în loc de un caracter nativ.
• Cãutaţi probleme de afişare în legãturã cu o proastã alegere de font, care aratã linii verticale sau cutiuţe în loc de litere.
• In general, gunoaiele de text apar din cauza interconversiunilor incorecte din ANSI în unicod, şi trebuie sã fiţi atenţi cu aceastã problemã.
• In mãsura puterilor, este important sã vã asiguraţi cã data care este aleasã în mod corect.
• Dacã aplicaţia are pãstrare îndelungã, este important a se testa dacã caracterele native pot fi introduse, menţinute, reîncãrcate, şi afişate corect în GUI.
• Dacã eroarea apare cu data englezeascã într-un sistem englezesc nu este o problemã iL8N şi nu trebuie etichetatã de acest tip.

Lucruri care trebuie tinute minte pentru L10N

Intr-o aplicaţie localizatã existã un domeniu de cazuri de testare care trebuie deasemenea considerat, cum ar fi:

• Verificaţi fiecare dialog şi loc unde apare un text pentru şiruri englezeşti.
• Verificaţi tasta de accelerare (litera care oferã posibilitatea de a tasta ALT+<LITERA> pentru a accesa controlul respectiv) pentru fiecare unitate de control şi menu din fiecare dialog. (In mod frecvent, în procesul de localizare, mai multe controluri vor fi distribuite fiecãrei litere, care dezafecteazã în mod eficace acceleratorii pentru controlurile duplicate).
• Intr-o limbã de sursã mai compactã, verificaţi fiecare loc unde apare un text pentru a fi sigur cã nu este întrerupt. Spre exemplu, majoritatea cuvintelor ne-englezeşti sunt mult mai lungi decât echivalentele lor în engleza.
• Uitaţi-vã la fiecare mesaj de eroare pentru a vã asigura cã şirurile sunt manevrate în mod corect. Dacã este posibil, gãsiţi un vorbitor nativ care sã citeascã dialogurile ãi sã se asigure cã au sens logic. Multe mesaje de erori apar din cauza mai multor şiruri englezeşti (dintre care fiecare ar putea sã fie tradus incorect în limba respectivã), şi sunt apoi prezentate utilizatorului ca un singur şir (care nu va avea nici un sens în altã limbã). Vorbesc despre aceastã problemã mai detailat în partea III, Localizare.
• Review your application for pictures that substitute for words with a native speaker, if possible. Pictures typically aren’t localized, but might not connote the same thing or be appropriate for the given locale. This is discussed in Part III.

Lucruri care trebuie ţinute minte pentru scenarii complexe în general

• Când sunteţi în faţa unor limbi care considerã anumite combinaţii de caractere ilegale, uitaţi-vã dupã un cerc mic punctat, care este indicaţia standard a unei litere care se aşteaptã ca altã literã sa o înlocuiascã.
• Dacã nu întelegeţi o limbã, fiţi atent cãnd decideţi dacã limba nu este manevratã corect într-o aplicaţie. In acest caz cineva care cunoaşte limba poate fi de o importanţã curcialã.
• Uitaţi-vã cu atenţie la adãugirea textului ori deasupra ori sub linie.
• Cãnd manevraţi limbi cum ar fi tailandeza, asiguraţi-vã ca aveţi pe cineva care vã poate ajuta sã întelegeţi dacã despãrţirea cuvântului este corespunzãtoare.
• Scrisul arab are o topicã naturalã a propozitiei cum ar fi أرسل كافة الشوائب، والأسئلة، والاقتراحات، والشكاوى، والتعليقاتإلى العنوان: (ceea ce înseamnã “Trimiteţi toate erorile, întrebãrile, reclamaţiile şi comentariile la:” ) Nu v-aţi aştepta la multe întreruperi într-un cuvânt (foarte asemãnãtor cu scrisul cursiv în textul latin), aşa cã fiţi atent la cuvintele care par deaspãrţite în litere sau caractere individuale.
• Asigurati-vã cã cineva care cunoaşte limba poate verifica comportamentul de sortare.
• Dacã sunteţi în Windows 2000 şi vreţi sã verificaţi comportarea adecvatã a tastaturii cu o tastaturã hindi şi control unicod, puteţi tasta v+c+m+d+l+s. Acestea vor deveni cuvãntul नमस्ते, care este cuvântul hindi Namaste, un salut comun. Un test asemãnãtor pentru tamil poate fi realizat prin tastarea b+C+k+d+k+c+d. Acestea vor deveni cuvântul வணக்கம, care este Vanakam, un salut asemãnãtor. Dacã formele aratã diferit, scrisul complex nu funcţioneazã corect.
• Puteţi obţine cuvinte asemãnãtoare în toate limbile care trebuie susţinute pentru consumãtori şi localizatori.

De unde tocmai am venit

Acest capitol discutã numeroase chestiuni care apar în testarea aplicaţiilor internaţionale, chestiuni care trebuie luate aminte cu seamã dacã vã extindeţi la pieţi globale. Este important pentru un tester sã ţinã minte cã el este în multe feluri cea mai importantã persoanã într-o companie care işi extinde piaţa. Testerii sunt cei care ajutã sã se evalueze în mod realist pieţile care trebuie acoperite şi succesul în pieţile globale deipnde în mare mãsurã în abilitatea lor de a se asigura cã producãtorul a fãcut o treaba bunã.

Acesta este un bun sfat cu care sa închei aceastã carte – cu un produs care este aprobat de tester si de care producãtorul este mândru şi care este bine primit de consumatorii din toata lumea! Cu toate cã realitatea nu este aşa mereu, prin a realiza o perspectivã globalã, puteţi garanta cã veţi produce lucruri care vor fi mult mai aproape de ţinta finalã.