Ron patton software testing, strona 5

Rozdział 11 Test łatwości korzystania
W TYM ROZDZIALE Testowanie interfejsu użytkownika Na czym polega dobry interfejs użytkownika? Testowanie pod kątem inwalidów: testowanie dostępności
Programy pisze się po to, żeby ktoś ich używał. To przecież oczywiste – ale zapomina się o tym w pośpiechu projektowania, wytwarzania i testowania skomplikowanego produktu. Tyle czasu i energii poświęca się technicznej stronie kodowania, że zespół projektowy zapomina o najważniejszej racji bytu oprogramowania – że ktoś będzie je w końcu używał. Nieważne, czy oprogramowanie jest wbudowane w kuchenkę mikrofalową, centralę telefoniczną czy jest częścią Intenetowej aplikacji do handlu akcjami. W końcu bity i bajty wydobywaja się na powierzchnię, gdzie żywy człowiek będzie się nimi posługiwał. Trafność, funkcjonalność i skuteczność współpracy człowieka z programem określają łącznie użyteczność programu.
Może obiło się komuś o uszy pojęcie ergonomii, nauki o projektowaniu i wzornictwie rzeczy do codziennego użytku tak, żeby były łatwe w użyciu i funkcjonalne. Celem ergonomii jest osiągnięcie użyteczności.
Nie, nie uda się przekazać treści czteroletnich studiów w dziedzinie ergonomii na piętnastu mniej więcej stronach tego rozdziału – i nie potrzeba. Przypomnijmy sobie z rozdziału 1-ego, czym jest błąd: oprogramowanie które trudno jest zrozumieć, trudno się nim posługiwać, które jest powolne, albo które w oczach użytkownika końcowego po prostu nie jest odpowiednie. To nasz list żelazny uprawniający do do testowania użyteczności.
Tester jest zwykle pierwszym użytkownikiem programu – należy mieć nadzieję, że jeszcze w trakcie projektu wytwórczego, kiedy jest możność dokonywania napraw. Tester zapoznaje się ze specyfikacjami i identyfikuje, kim będzie końcowy użytkownik1. Jeśli tester ma trudności z posługiwaniem się programem, można się spodziewać, że będzie je miał też użytkownik.
Istnieje tak wiele różnych rodzajów oprogramowania, że nie sposób szczegółowo wyłożyć zagadnienń użyteczności dla każdego z nich. Użyteczność programu kierującego automatycznym blokowaniem działania reaktora atomowego jest czymś innym, niż użyteczność systemu poczty głosowej. W tym rozdziale zapoznamy się z podstawowymi zasadami – przy czym punkt ciężkości wywodów znajdzie się na typowym oprogramownaiu dla komputera osobistego. Te same zasady można później zastosować do każdego rodzaju oprogramowania.
1 Miejmy nadzieję, że zostało to zrobione już w trakcie konstruowania specyfikacji wymagań, a nie dopiero przez testerów… (przyp. tłumacza).
Główne punkty tego rozdziału: 57.Co wchodzi w skład testowania użyteczności 58.Na co zwracać uwagę testując interfejs użytkownika 59.Specjalne cechy użyteczności potrzebne osobom niepełnosprawnym. Testowanie interfejsu użytkownika
Środki, za pomocą których użytkownik komunikuje się z programem noszą nazwę Interfejsu Użytkownika, albo UI (ang. User Interface). Każde oprogramowanie ma jakiś interfejs użytkownika. Puryści mogą się spierać, że to nieprawda, że programy takie jak te, które w samochodzie kontrolują skład mieszanki paliwowej nie mają interfejsu użytkownika. Rzeczywiście, nie mają konwencjonalnego interfejsu, ale dodatkowa siła, z jaką musi się naciskać na pedał gazu, i wyraźnie słyszalne trzaski w rurze wydechowej są rodzajem interfejsu użytkownika…
Interfejsy programów, do jakich jesteśmy przyzwyczajeni, zmieniły się wraż z upływem czasu. Pierwsze komputery miały elektryczne przełączniki i żarówki. Papierwowa taśma, karty dziurkowane i dalekopisy spotykało się najczęściej w latach 60-ych i 70-ych. Następnie pojawiły się monitory i proste edytory liniowe. Obecnie używa się komputerów z graficznym interfejsem użytkownika (GUI).
Chociaż wymienione interfejsy bardzo różniły się od siebie, w sensie technicznym zapewniały to samo: sposoby żeby wprowadzić do komputera dane wejściowe i otrzymać z powrotem dane wyjściowe. Na czym polega dobry interfejs użytkownika?
Wiele firm komputerowych poświęca znaczne środki na badanie jak najlepiej zaprojektować interfejs użytkownika dla swego programu. Takie badania wykonuje się w laboratoriach użyteczności, w których pracują specjaliści od ergonomii. Laboratoria wyposażone są w jednostronne lustra i kamery wideo do zapisywania, jak dokładnie ludzie posługuja się oprogramowaniem. Wszystko co osoby badane robią – które klawisze naciskają, jak posługują się myszą, jakie popełniają błędy i co ich zbija z tropu – analizuje się, aby móc zaproponować poprawki w UI.
Można zadać sobie pytanie, co tester może właściwie zdziałać z tym szczegółowym i niemal naukowym opisem. Zanim oprogramowanie zostanie napisze, powinno już mieć doskonałe UI. Ale skoro tak, czemu na tak wielu magnetowidach błyska godzina 12:00?
Po pierwsze, mało który zespół projektuje swoje interfejsy w aż tak naukowy sposób1. Większość interfejsów po prostu konstruowana jest w chwli natchnieniea przez programistę, które może dobrze umieć świetnie kodować, ale nie jest zwykle ekspertem od ergonomii. Cęsto poświęca się projektowanie interfejsu na rzecz pośpiechu czy pokonywania trudności technicznych. Jedną z przyczyn może być – jak dowiedzieliśmy się w rozdziale 10-ym – że oprogramowanie nie zostało starannie ulokalnione. W każdym razie, tester musi wziąć na siębie odpowiedzialność za testowanie użyteczności produktu, którego częścią jest interfejs użytkownika2.
Tester może sądzić, że brakuje mu kompetencji do testowania interfejsu użytkownika, ale to nieprawda. Nie oczekuje się, że tester ma interfejs zaprojektować. Wystarczy, by wszedł w skórę użytkownika i znalazł problemy z interfejsem.
Ze względu na subiektywny charakter błędów interfejsu, częste są nieporozumienia między testerami i konstruktorami interfejsu użytkownika. Twórca interfejsu często traktuje go jak dzieło sztuki i tester mówiący, że coś jest nie w porządku obraża „artystę”. Użyteczność to drażliwy teren. W rozdziale 18-ym „Raportowanie tego, co się znalazło”, opisane są sposoby, jak przkazać to, co ma się do powiedzenia na temat błędu tak, by nikogo nie urazić.
Oto lista siędmiu cech, które powinien spełniać dobry iterfejs użytkownika. Nieistotne czy chodzi o interfejs cyfrowego zegarka na rękę czy interfejs systemu operacyjnego Macintosha, te zasady obowiązują w równym stopniu. 60.Zgodny ze standardami i regulami 61.Intuicyjny 62.Spójny 63.Elastyczny 64.Wygodny 65.Poprawny 66.Użyteczny
1 W tekst wkrada się tutaj – przewijajace się przez resztę wywodów – utożsamianie interakcji z interfejsem. Jest to często spotykane nieporozumienie. Nawet elegancko wykonany i zgodny z zasadami ergonomii interfejs użytkownika nie zapewni wysokiej użyteczności programowi, który nie ma przemyślanego projektu całości interakcji z użytkownikiem. Ciekawe dane na ten temat można znaleźć na www.cooper.com (przyp. tłumacza).
2 Trudno w pełni zgodzić się z tym poglądem – tester mający kompensować braki w formułowaniu specyfikacji wymagań, w fazie konstrukcji… to niewykonalne zadanie (przyp. tłumacza).
Czytając książki na temat wzornictwa interfejsu, można zetknąć się również z innymi cechami dodawanymi do tej listy. Większość jedna daje się sprowadzić do lub wywieść z powyższych siedmiu cech.  Na przykład, nie zostało tu wymienione „łatwy do nauczenia się”, ale jeśli coś jest intuicyjne i spójne, zapewne będzie też łatwe do nauczenia się. Tester, które skoncentruje się na zadaniu, by interfejs użytkownika spełniał powyższą listę cech, przyczyni się do powstania naprawdę dobrego interfejsu. Każda z cech omówiona jest szczegółowo poniżej.
Zgodny ze standardami i regułami
Najważniejszę cechą dobrego interfejsu użytkownika jest to, by spełniał wymagania istniejących standardów i reguł – albo miał bardzo dobre powody tam, gdzie ich nie spełnia. Dla oprogramowania pracującego na istniejących platformach, takich jak Macinstosh czy Windows, standardy są ustalone. Standardy Apple zdefiniowane są w książce Macintosh Human Interface Guidelines, opublikowanej przez Addison-Wesley, a standardy Microsoftu w książce Micorsoft Windows User Experience, wydanej przez Micorsoft Press.
Obie książki wyjaśniają w najdrobniejszych szczegółach, jak oprogramowanie pracujące na tych platformach powinno wyglądać i działać z punktu widzenia końcowego użytkownika. Wszystko jest określone – kiedy używać pole wyboru zamiast przycisku opcji (kiedy obydwa stany wynikające z wyboru są  jednoznacznie przeciwstawne), kiedy należy stosować komunikaty informacyjne, ostrzeżenia oraz komunikaty o krytycznej awarii, pokazane na rysunku 11.1.
Rysunek 11.1 W Widnowsach stosuje się trzy różne poziomy komunikatów. Standardy interfejsku użytkownika dla Windows określają, kiedy należy używać którego rodzaju.
Testując oprogramowanie mające pracować na określonej platformie, należy traktować standardy i reguły dla tej platformy jako dodatek do własnej specyfikacji produktu. Na ich podstawie można sporządzić zadania testowe tak samo, jak na podstawie własnej specyfikacji produktu.
Te standardy zostały sformułowane – miejmy nadzieję – przez specjalistów w dziedzinie użyteczność produktów. Są podsumowaniem zgromadzonych doświadczeń na temat tego, jak projektować systemy o wysokiej użyteczności, łatwe w obsłudze dla użytkowników. Jeśli oprogramowanie ściśle przestrzega tych zasad, większość innych cech dobrego interfejsu użytkownika osiągnie się samo przez się. Nie wszystko jednak zadziała, kiedy albo zespół projektowy uległ pokusię radosnej twórczości, albo reguły nie do końca pasowały do specyfiki danego oprogramowania. Wówczas należy zagadnieniom użyteczności poświęcić szczególną uwagę.
Może się też zdarzyć, że dana platforma nie ma własnego standardu1, a może właśnie testowane oprogramowanie samo stanowi taką platformę. W tej sytuacji zespół projektowy sam będzie ustalał standardy użyteczności dla oprogramowania. Nie mogąc posługiwać się gotowymi standardami, trzeba tym uważniej stosować się do pozostałych (sześciu) cech wymaganych dla dobrego interfejsu.
Intuicyjny
W 1975 roku firma MITS (Micro Instrumentation Telemetry System) wypuściła jeden z pierwszych komputerów osobistych. Jego interfejs użytkownika (rysunek 11.2) sładał się wyłącznie z przełącznikow i światełek – niezbyt intuicyjnych w użyciu.
Rysunek 11.2 Altair 8800 firmy MITS i jego niezbyt intuicyjny interfejs użytkownika (fotografia zamieszczona za zgodę Amerykańskiego Muzeum Komputerów, www.computer-museum.org).
Alatir był zaprojektowany dla informatyków-hobbystów, ludzi skłonnych do wielkiej wyrozumiałości wobec niedostatków interfejsu. Obecnie użytkownicy wymagają o wiele więcej. Wszyscy – staruszkowie, dzieci i doktorzy nauk ścisłych – używają komputerów na co dzień. Komputery mające najbardziej intuicyjny interfejs to te, z których istnienia nawet nie zdajemy sobie sprawy.
1 Typowe dla systemów wbudowanych i innych posługujących się niestandardową platfomą i sprzętem (przyp. tłumacza).
Testując interfejs użytkownika, intuicyjność można ocenić usiłując odpowiedzieć na następujące pytania: 67.Czy interfejs użytkownika jest elegencki, nie przeszkadza, nie sprawia kłopotów? Interfejs nie może utrudniać zrobienia tego, co się chce. Potrzebne funkcje oraz oczekiwana informacja powinny być oczywiste i znajdować się tam, gdzie się ich oczekuje. 68.Czy interfejs jest dobrze zorganizowany i rozplanowany? Czy łatwo jest przemieszczać się z jednej funkcji do drugiej? Czy jest zawsze jasne, jaki jest kolejny krok? Czy w każdym momencie można wycofać się z rozpoczętej czynności? Czy wprowadzane dane są potwierdzane? Czy menu i okna nie są zbudowane na zbyt wielu poziomach? 69.Czy jest nadmiar funkcjonalności? Czy program jako całość albo jakaś jego część usiłuje robić zbyt wiele? Czy zbyt wiele możliwości utrudnia i nadmiernie komplikuje pracę? Czy jest się przeciążonym nadmiarem informacji? 70.Czy gdy wszystko inne zawiodło, system pomocy rzeczywiście jest pomocny?
Spójny
Spójność wewnętrzna programu i jego spójność z innymi programami mają kluczowe znaczenie. Użytkownicy wyrabiają sobie nawyki i oczekują, że kiedy jakaś funkcja działa w pewien sposób w jednym programie, będzie też działać tak samo w innym programie. Rysunek 11.3 pokazuje przykład dwóch aplikacji Windows, które powinny być zrobione zgodnie ze standardem, ale nie są spójne. W Notatniku, funkcję Szukaj znajduje się przez menu Poszukiwanie albo za pomocą naciśniecia klawisza F3. W bardzo podobnym programie WordPad, dostęp do tej funckji odbywa się przez menu Edytuj albo za pomocą klawiszy Ctrl-F.
Rysunek 11.3 Notatnik i WordPad w Windows są niespójne pod względem sposobu przywoływania funkcji Szukaj.
Tego rodzaju niespójności frustrują użytkowników, kiedy przenoszą się z jednego do drugiego programu. Jeszcze gorzej, jeśli niespójność pojawia się wewnątrz jednego programu. Jeśli istnieje standard dla tego rodzaju oprogramowania na danej platformie, należy się nim posługiwać. Jeśli standardu nie ma, trzeba zwrócić szczególną uwagę na to, by podobne czynności były wykonywane podobnie. Dokonując przeglądu nowego produktu warto zwrócić uwagę na następujące elementy: 71.Skróty i wybory z menu. W systemie poczty głosowej, zero, a nie inne numery, łączy prawie zawsze z operatorem. W Windows, naciśnięciue F1 zawsze przywołuje pomoc. 72.Terminologia i nazewnictwo. Czy jednolite nazwy używane są w całym oprogramowaniu? Czy spójne jest nazewnictwo funkcji? Na przykład, czy Szukaj zawsze nazywa się Szukaj, czy też czasem naywa się Znajdowanie? 73.Publiczność. Czy oprogramowanie przez cały czas zwraca się do tego samego rodzaju publiczności? Program z kolorowym interfejsem, służący do robienia śmieszynych pocztówek, mie powinien ogłaszać komunikatów o błędach skomplikowanym technologicznym bełkotem. 74.Położenie i odpowiedniki przycisków na klawiaturze. Czy ktokolwiek zauważył, że przyciski OK i Anuluj w oknie dialogowym zawsze umieszcza się tak, że OK jest zawsze na górze albo na lewo, zaś Anuluj na dole albo na prawo? Z tego samego powodu, jako odpowiedników na klawiaturze używa się zwykle Esc jako anuluj i Enter jako OK. Spójność jest ważna1.
Elastyczny
Użytkownicy lubią mieć możność wyboru – bez przesady, ale dość by mogli wybierać co chcą zrobić i w jaki sposób. Kalkulator w Windows (rysunek 11.4) ma dwa tryby: standardowy i naukowy. Użytkownicy sami wybierają, którego chcą używać.
1 Niedostateczne wyczucie amerykańskiego poczucia humoru nie pozwala stwierdzić, czy to autentyczna pomyłka, czy zamierzony sarkazm autora (przyp. tłumacza).

Rysunek 11.4 Kalkulator w Windows jest elastyczny, bo może działać w dwóch różnych trybach.
Oczywiście, elestyczność powoduje rosnącą złożoność. W powyższym przykładzie z Kalkulatorem testowanie byłoby znacznie prostsze, gdyby program mógł działać tylko w jednym trybie. Skutki elastyczności odczuwane są najbardziej dotkliwie w zakresie tego, co opisuje rozdział 5-y „Testowanie z klapkami na oczach” na teamt testowania przejśc stanów. 75.Skoki między stanami. Elastyczne oprogramowanie ma więcej opcji i więcej sposobów osiągnięcia tego samego wyniku. Skutkiem tego są dodatkowe ścieżki między różnymi stanami. Diagram przejść stanów staje się znacznie bardziej złożony. Więcej czasu zajmie wybór, które ścieżki trzeba będzie przetestować. 76.Omijanie stanów. Ta możliwość jest najbardziej widoczna, kiedy oprogramowanie ma tryb „dużej mocy”,  gdzie doświadczony użytkownik może iminąć kilka kolejnych etapów i przeskoczyć na skróty wprost do celu. System poczty głosowej, pozwalający bezpośrednio wprowadzić  numer wewnętrzny rozmówcy jest tego przykładem. Testując oprogramowanie mające takie możliwości należy sprawdzić, czy wszystkie zmienne otrzymały właściwe wartości mimo omijania stanów pośrednich.
77.Dane wejścia i wyjścia. Użytkownicy chcą móc posługiwać się różnymi sposobami wprowadzania danych do programu i oglądać je w różnych formach. Na przykład aby wprowadzić tekst do WordPad, można go napisać, wkleić, załadować z plików o różnych formatach, wkleić jako objekt albo przyciągnąc przy pomocy myszy z innego programu. Arkusz kalkulacyjny Microsoft Excel pozwala na oglądanie danych w formie 14 różnych standardowych i 20 robionych na zamówienie wykresów. Mało kto nawet wie, że jest aż tyle rożnych możliwości. Przetestowanie wszelkich możliwych sposobów wprowadzania danych do programu oraz oglądania wyników może bardzo szybko powiększyć niezbędzny w tym celu wysiłek poza dozwoloną granicę i zmusić nas do bezwzględności przy tworzeniu klas równoważności.
Wygodny
Oprogramowanie musi używać się wygodnie. Nie powinno przeszkadzać użytkownikowi w wykonaniu pracy. Wygoda oprogramowania to bardzo nieprecyzyjna zmienna. Naukowcy poświęcali całe kariery usiłując znaleźć formułę, jak uczynić oprogramowanie wygodnym. To pojęcie jest trudno skwantyfikować, ale warto poszukiwać następujących wskaźników: 78.Stosowność. Oprogramowanie musi wyglądać stosownie do tego co i dla kogo robi. Aplikacja fiansowa raczej nie powinna przesadzać z krzykliwymi kolorami i efektami dźwiękowymi. Z drugiej strony, kosmiczna gra komputerowa wymaga naginania reguł. Ogólnie mówiąc, oprogramowanie nie może być zbyt spartańskie, ale nie może być też przsadnie ozdobne. 79.Obsługa błędów. Program musi ostrzegać użytkowników przed przystąpieniem do krytycznych działań i dać możliwość odtworzenia danych ewentualnie straconych w wyniku awarii.
80.Wydajność. Szybkość nie jest zawsze najlepsza. Niejeden program migocze komunikatami o awarii tak szybko, że człowiek nie nadąża ich przeczytać. Z kolei do powolnych operacji, trzba przynajmiej dać użytkownikowi zmieniającą się informację o tym, ile czasu operacja będzie jeszcze trwała, że aktywność trwa i program się nie zawiesił. Pasek statusu, jak na rysunku 11.5, to popularny sposób przekazywania tych informacji.
Rysunek 11.5 Pasek stanu pokazuje, ile pracy już ukończono i ile jeszcze pozostało. 
Poprawny
Kwestia wygody jest, trzeba przyznać, niejednoznaczna i można ją różnie interpretować. Z poprawnością nie ma takich kłopotów. Testując poprawność, testuje się, czy interfejs użytkowanika wykonuje to, co powinien. Rysunek 11.6 jest przykładem niepoprawango interfejsu.
Rysunek 11.6 Ten program ma zupełnie bezużyteczny przycisk Przerwij.
Rysunek przedstawaia okno z komunikatem popularnego programu do skanowania pod Windowsami. Okno to pojawia się, kiedy skanowanie się rozpoczęło i ma umożliwić przerwanie skanowania w trakcie. Niestety, nie działa. Kursor ma kształt klepsydry, co oznacza (według standardów Windows), że oprogramowanie jest zajęte i nie przyjmuje żadnych danych z wejścia. Po co więc umieszczać tam przycisk Przerwij? Można wielokrotnie klikać w ten przycisk podczas całego skanowania, które trwa do kilku minut, i nic się nie zmienia. Skanowanie posuwa się dalej bez przerwy aż do końca.
Tego rodzaju brak poprawności rzuca się w oczy i zostanie przypuszczalnie wykryty podczas zwykłego testowania zgodności ze specyfikacją produktu. Warto jednak zwrócić szczególną uwagę na jeszcze kilka zagadnień: 81.Błędy w materiałach do marketingu. Czy brakuje jakich funkcji, czy pojwawiły się może funkcje o innym działaniu niż opisane w materiałach reklamowych? Nie porównuje się tutaj oprogramownaia ze specyfikacją, lecz z informacjami reklamowymi. Zwykle się różnią. 82.Język i pisownia. Programiści wiedzą tylko, jak się pisze słowa-klucze języka programownia i często konstruują bardzo ciekawe komunikaty. Poniższy przykład znajuje się na popularnej witrynie Internetowej – do dziś, należy mieć nadzieję, został już usunięty. Jeśli jest jakaś rozbieżność z poniższą informacją, prosimy bezzwłocznie się z nami skontaktować, by zapenić punktualną dostawę zamówionych arytkułów. 83.Błędne nośniki. Przez nośniki rozumie się tutaj wspierające program ikony, rysunki, dźwięki i fragmenty wideo wchodzące w skład interfejsu. Ikony powiny mieć stałą wielkość i zestaw kolorów. Dźwięki powinny być wszystkie zapisywane w tym samym formacie i z tą samą częstotliwością dokonywać pomiaru próbek. Poprawne ustawienia powinny być wyświatlane. 84.WYSIWYG1 (dostaje się to, co się widzi). Trzeba się upewnić, że podawana przez interfejs informacja jest prawdziwa. Kiedy się kliknie przycisk Zapisz, czy zapisany dokument jest dokładnie taki, jak widoczny na ekranie? Kiedy załadować go z powrotem, czy jest identyczny jak oryginał?
Użyteczny
Ważną cecha dobrego interfejsu jest użyteczność. Nie chodzi o to, czy całe oprogramowanie jest użyteczne, tylko czy dana cecha lub funkcja jest użyteczna. Funkcje niepotrzebne – nieważne w jakiego rodzaju programie – są złe dla użytkowanika, a dla testera oznaczają niepotrzebną, dodatkową pracę.
1 WYSIWYG – What You See Is What You Get (przyp. tłumacza).
Waro sobie zadać pytanie, czy dana funkcja do czegoś się przydaje – czy w trakcie przglądu specyfikacji, czy w czasie planowania, czy w czasię wykonywania testów. Czy pomaga użytkownikom? Jeśli funkcja wydaje się zbędna, warto zbadać, czemu znalazła się w programie. Mogą istnieć nieznane testrowi powody, albo funkcja rzeczywiście jest zupełnie zbędna. Testowanie pod kątem inwalidów: testowanie dostępności
Ważną częścią testowania użyteczności jest testowanie dostępności, czyli testowania pod kątem inwalidów. Badania przprowadzone w latach 1994-1995 przez amerykański urząd statystyczny (U.S. Census Bureau) ujawniły, że 54 miliony mieszkańców USA miało w jakiś sposób ograniczoną sprawność. Tabela 11.1 pokazuje rozkład niesprawności w rożnych grupach wiekowych.
Tabela 11.1 Ludzie niepełnosprawni

Wiek Procent osób niepełnosprawnych 0-21 10% 22-44 14,9% 45-54 24,5% 55-64 36,3% 65-79 47,3%

80+ 71,5%
Starzenie się społeczeństwa i wchodzenie oprogramowania w coraz to nowe dziedziny życia powoduje, że testowanie dostępności staje się coraz ważniejsze.
Istnieją różne rodzaje inwalidztwa, ale kilka powoduje, że korzystanie z komputerów staje się szczególnie utrudnione. 85.Wady wzroku. Daltonizm, silna krótko- i dalekowzroczność, widzenie tunelowe, widzenie mgliste, katarakty – to przykłady wad wzroku. Ludzie, którzy cierpią na jedną albo kilka z nich, mają szczególne trudności z używaniem oprogramowania. Wyobraźmy sobie, jak trudno jest zobaczyć, gdzie mieści się w danej chwili kursor myszki, albo jak trudno odczytać małe znaki graficzne albo tekst na ekranie. Co będzie, jeśli użytkownik jest w ogóle niewidomy? 86.Wady słuchu. Można być częściowo lub całkiem głuchym, mieć trudności ze słyszeniem pewnych częstotliwości albo z usłyszeniem dźwięku w hałasie. Może to utrudniać albo uniemożliwić słyszenie głosów albo dźwięków towarzyszących animacjom, pomocy dźwiękowej albo ostrzeżeń systemowych. 87.Ograniczenia ruchowe. Choroba albo wypadek może pozbawić osobę – częściwo lub całkowicie – kontroli nad dłonią lub ramieniem. Dla niektórych ludzi prawidłowe posługiwanie się klawiaturą lub myszka jest trudne lub niemożliwe. Na przykład mogą mieć trudności z naciśnięciem naraz więcej niż jednego klawisza, albo z naciskaniem klawisza tylko jeden raz. Niemożliwe może być poruszanie myszą. 88.Ograniczenia poznawcze i językowe. Zaburzenia pisania, mowy i pamięci utrudniają używanie skomplikowanego interfejsu użytkownika. Należy wziąć pod uwage omówione wcześniej zagadnienia i rozważyć ich możliwy wpływ na osoby z tego rodzaju trudnościami.
Takie jest prawo
Na szczęście, wytwarzanie oprogramowania z którego mogą korzystać także osoby niepełnosprawne nie jest tylko dobrym pomyslem, regułą czy nawet standardem – jest (w USA) prawem. W Stanach Zjednoczonych, trzy przepisy odnoszą się do tego zagadnienia:
89.Prawo dotyczące osób niepełnosprawnych wymaga, by w przedsiębiorstwach zatrudniających więcej niż piętnastu pracowników były zainstalowane niezbędne udogodnienie. To prawo zastosowano ostatnio wobec komercyjnych witryn na Internecie, wymagając by stały się bardziej dostępne. 90.Paragraf 508 prawa rehabilitacyjnego jest podobny do przepisu zacytowango powyżej i dotyczy wszelkich organizacji oraz instytucji otrzymujących dotacje od rządu federalnego. 91.Paragraf 255 prawa telekomuniacyjnego wymaga, żeby oprogramowanie  i sprzęt stosowany do przenoszenia informacji przez Internet, sieć albo przez linie telefoniczne, był dostosowany do osób niepełnosprawnych. Jeśli ten wymóg nie jest spełniony, to sprzęt lub oprogramowanie musi być kompatybilne (zob. rozdział 8-y „Testowanie konfiguracji” i rozdział 9-y „Testowanie kompatybilności”) z istniejącymi – w formie sprzętu lub oprogramowania – pomocami dla niepełnosprawnych.
Funkcje dostępności oprogramowania
Oprogramowanie można udostępnić niepełnosprawnym na dwa sposoby. Najprościej wykorzystać pomoc wbudowaną w system operacyjny. Zarówno Windows, Macintosh, Java i IBM OS/2 mają pewne funkcje ułatwiające realizację dostępności. Wystarczy, by program spełniał wymagania systemowe dotyczące sposobu posługiwania się klawiaturą, myszą, kartą dźwiękową i monitorem, aby spełniał podstawowe wymagania dostępności. Rysunek 11.7 pokazuje przykład panelu kontrolnego ustawień dostępności w Windows ‘98.
Rysunek 11.7 Z tego panelu kontrolnego ustawia się funkcje dostępności w Windows.
Jeśli testowane oprogramowanie stosowane jest na innej platformie niż wymienione (albo samo stanowi platformę), musi mieć własne funkcje dostępności wyspecyfikowane, zaprogramowane i przetestowane. Jest to oczywiście trudniejsze niż posłużenie się gotowymi funkcjami obsługi dostępności, ale test dostępności wymagany jest w oby wypadkach, nawet jeśli oprogramowanie wykorzystuje wspomaganie wbudowane w system operacyjny.
Testując użyteczność produktu, trzeba pamiętać o skonstruowaniu zadań testowych także pod kątem dostępności. To zapewni nam czyste sumienie.
Każda z wymienionych platform ma własną specyfikę, ale wszystkie oferują wsparcie dla funkcji ułatwiających posługiwanie się oprogramowaniem przez osoby niepełnosprawne. W Windowsach znajdują się następujące możliwości: 92.Lepkie Klawisze pozwalają, by klawisze Shift, Ctrl i Alt pozostawały aktywne aż do naciśnięcia następnego klawisza. 93.Filtrowanie Klawiszy anuluje skutki przypadkowego wielokrotnego naciśnięcia tego samego klawisza 94.Przełączniki Klawiszy generują sygnał dźwiękowy po naciśnięciu klawiszy CapsLock, ScrollLock i NumLock. 95.Strażnik Dźwięku generuje ostrzeżenie graficzne przy każdym użyciu sygnału dźwiękowego przez system. 96.Pokaz Dźwięków poleca oprogramowaniu wyświetlenie teksu lub grafiki przy każdym generowanym przez nie dźwięku. Wyświetlany tekst lub grafika muszą być osobno zaprogramowane. 97.Wysoki Kontrast ustawia monitor (kolory i czcionki) tak, by ułatwić pracę osobom z wadami wzroku. Przykład znajduje się na rysunku 11.8.
Rysunek 11.8 Pulpit Windows można przestawić na wysoki kontrast, co ułatwia pracę osobom z wadami wzroku.
98.Mysz Klawiszowa umożliwia nawigację przy pomocy klawiszy klawiatury zamiast myszy. 99.Seryjne Klawisze ustawiają port komunikacyjny tak, by odczytywał przyciśnięcia klawiszy z pomocniczego urządzenia. Chociaż z punktu widzenia systemu operacyjnego takie urządzenia powinny funkcjonować tak samo jak standardowa klawiatura, nie zaszkodzi ich dołączyć do klasy równoważności przy testowaniu konfiguracji.
Więcej danych na temat funkcji dostępności wbudowanych w najważniejsze systemy operacyjne można znaleźć w następujących witrynach internetowych: 100.http://www.microsoft.com/enable  101.http:/www.apple.com/education/k 12/disability 102.http://www-3.ibm.com/able  103.http://www.sun.com/tech/access  Podsumowanie
Oprogramowanie może być trudno zrozumieć, niełatwo używać, może być też zbyt wolne albo – w opinii testera – po prostu błędne.
Tester jest pierwszą osobą, która posługuje się produktem w sposób zbliżony do użytkownika, pierwszą osobą która widzi całość złożoną w ostateczny kształt. Jeśli całość sprawia trudności testerowi, klient będzie miał te same kłopoty.
Nade wszystko nie wolno pozwolić, by subiektywność i brak ścisłych reguł stanęły na przeszkodzie testowaniu użyteczności. Nawet specjaliści od projektowanie interfejsu użytkownika – przynajmniej niektórzy – zgodzą się z tym. Testując interfejs użytkownika nowego produktu, można posługiwać się listą z tego rozdziału, zawierającą cechy dobrego interfejsu. Jeśli testowany interfejs nie spełnia tych kryteriów, mamy do czynienia z błędem. Pytania
Pytania mają na celu ułatwienie zrozumienia. W aneksie A „Odpowiedzi na pytania” znajdują się prawidłowe rozwiązania – ale nie należy ściągać! 1.Pawda czy fałsz: każdy rodzaj oprogramowania ma interfejs użytkownika i dlatego musi być przetestowany pod kątem użyteczności. 2.Czy konstrukcja interfejsu użytkowanika jest nauką czy sztuką? 3.Jeśli nie istnieją jednoznaczne kryteria poprawności interfejsu użytkownika, w jaki sposób można go testować?
4.Wymień znane ci przykłady źle zaprojektowanego albo niespójnego interfejsu użytkkowanika. 5.Jakie cztery rodzaje inwalidztwa wpływają na dostępność oprogramowania? 6.Na co należy przede wszystkim zwrócić uwagę przy testowaniu oprogramowania pod kątem dostępności dla niepełnosprawnych?

Rozdział 10 Testowanie różnych wersji językowych
W TYM ROZDZIALE Aby słowa i rysunki miały sens Kwestie tłumaczenia Kwestie ulokalnienia Zagadnienia konfiguracji i kompatybilności Jak wiele trzeba testować?
Si tu eres fluente en mas de un idioma y competente en provando programas de computadora, tu tienes una habilidad muy decenda en el mercado.
Wenn Się eine zuverläßig Software Prüferin sind, und fließend eine fremdsprache, ausser English, sprechen können, dann können Się gut verdienen.
Przetłumaczone z grubsza z hiszpńskiego i niemiećkiego, powyższe zdania znaczą: Ten kto jest doświadczonym testerem oprogramowania i zna dobrze inny język oprócz angielskiego, może się spodziewać wysokich zarobków1.
Wiele programów wypuszcza się dzisiaj na cały świat, nie tylko na rynek jednego kraju albo tylko w jednym języku. Micorsoft dostarczał Windows 98 z obsługą dla 73 różnych języków, od Afrikaans przez węgierski do wietnamskiego. Większość innych firm produkujących oprogramowanie postępuje podobnie, zdając sobie sprawę, że angielskojęzyczny rynek amerykański to ledwo połowa potencjalnych klientów. Projektowanie i testowanie oprogramowania pod kątem sprzedaży na całym świecie przynosi konkretne zyski.
W tym rozdziale poznamy wymagania wobec testowania programów pisanych dla wileu krajów i języków. Na pierwszy rzut oka wydaje się to nieskomplikowane, ale rzeczywistość jest inna i dowiemy się, dlaczego.
Główne punkty tego rodziału to: 50.Czemu samo tłumaczenie nie wystarcza 51.Jak zmiana języka wpływa na słowa i na cały tekst 52.Czemu piłka nożna i telefon są ważne 53.Zagadnienia konfiguracji i kompatybilności
1 To zdanie, jak i cały rozdział, napisany jest z wyraźnie amerykańskiej perspektywy. W niczym nie zmienia to jego aktualności, choć oczywiśćie polscy producenci oprogramowania rzadziej niż amerykańscy wytwarzają programy przenaczone do użytku wielojęzycznego (przyp. tłumacza).
54.Jak wiele pracy wymaga testowanie pod kątem innego języka Aby słowa i rysunki miały sens
Każdy pewnie kiedyś czytał instrukcję obsługi zabawki albo urządzenia, źle – dosłownie – przetłumaczoną z innego języka. „Przełóż trzpień numer pięć przez zieloną kratkę i dokręć nie luźno żadną nakrętke.” Jasne?
To jest przykład złego tłumaczenia, i tak właśnie oprogramowanie może wyglądać, kiedy nie dość wysiłku włożyło się w przygotowanie wersji innych niż oryginalna. Łatwo jest przetłumaczyć tekst słowo po słowie, ale zachowanie znaczenia wymaga więcej pracy i uwagi.
Dobry tłumacz potrafi to właśnie osiągnąć. Kto mówi płynnie w obu językach, potrafi sporządzić tłumaczenie równie poprawne i zrozumiałe jak oryginał. Niestety, w przemyśle informatycznym samo dobre tłumaczenie nie zawsze wystarcza.
Weźmy jako przykład język hiszpański. To chyba prosta sprawa przetłumaczyć tekst angielski na hiszpański, prawda? Dobrze, ale który hiszpański? Hiszpański z Hiszpanii? A co z hiszpańskim z Kostaryki, z Peru, z Dominikany? Wszędzie tam mówi się po hiszpańsku, ale są to odmiany na tyle różne, że program napisany pod kątem jednego może być źle przyjęty przez inne. Nawet angielski ma podobne kłopoty. Istniej nie tylko angielski amerykański, ale kanadyjski, australijski i brytyjski. W oczach amerykańskiego użytkownika słowa colour albo neighbour wyglądają dziwacznie1.
Trzeba wziąć pod uwagę, oprócz samego języka, również tak zwaną specyfikę regionalną: kraj albo region, z którego pochodzi użytkownik. Proces ten naywa się ulokalnieniem: dostosowywanie oprogramowania do lokalnej specyfiki, dialektu, obyczajów i kultury. Testowanie tak przetworzonego oprogramowania nazywa się testowaniem ulokalnienia. Kwestie tłumaczenia
Chociaż tłumaczenie jest tyko częścią całego procesu ulokalniania, jest szczeglnie ważne z punktu widzenia testowania. Najprostszym problemem jest – jak można przetestować coś posługującego się innym językiem? Cóż, któryś z testerów musi w tym celu mieć choćiaż średnią znajomość tego języka aby móc przemieszczać się w programie, czytać i rozumieć wyświetlane przez program teksty infromacyjne  i pisać komnedy niezbędne do uruchomienia programu. Może jest wobec tego czas najwyższy, aby zapisać się na kurs języka słoweńskiego, o którym się od dawna marzyło?
1 Brytyjska i amerykańska ortografia różnią się w tym miejscu: brytyjskiemu colour i neighbour odpowiada amerykańskie color i neighbor (przyp. tłumacza).
Ważne by choć jedna osoba w zespole testującym znała choć trochę język, który się testuje1. Oczywiście, jeśli program będzie mógł obsługiwać 32 różne języki, może to być trudno osiągnąć. Rozwiązaniem jest przekazanie tego zadania firmie specjalizującej się w testowaniu ulokalnienia. Liczne takie firmy na całym świecie są w stanie podjąć się testowania niemal we wszystkicj językach. Aby znaleźć więcej wiadomości na ten temat, wystarczy przeszukiwać zwrotu „localization testing”2 na Internecie.
Nie musi się wymagać, aby każdy w zespole znał język, na który dokonuje się ulokalniania. Przypuszcalnie wystarczy jedna tylko osoba. Wiele rzeczy można sprawdzić nie znając znaczenia słów. Na pewno pomocna jest pewna znajomość, ale daje się sporo przetestować nie mówiąc płynnie w danym języku.
Rozszerzanie tekstu
Najprostszym przykładem kłopotu z tłumaczeniami jest tak zwane rozszerzanie tekstu. Chociaż język angielski może się czasem wydawać rozwlekły, okazuje się, że tłumacząc angielski na inne języki zwykle potrzeba więcej liter dla wyrażenia tej samej rzeczy. Rysunek 10.1 pokazuje jak wielkość przycisku rośnie, aby zmieścił się na nim tekst dwóch często spotykanych określeń komputerowych. Dobrym oszacowaniem jest spodziewać się do 100-procentowego wzrostu wielkości poszczególnych słów – na przykład na przycisku. Można się spodziewać 50-procentowego wzrostu rozmiarów zdań i krótkich akapitów – typowych zwrotów, jakie znajdują się w oknach dialogowych i w komunikatach o awariach.
Rysunek 10.1 Słowa Minimize (minimalizuj) i Maximize (maksymalizuj) mogą mieć różną wielkość w różnych językach, co może zmusić do przekonstruowania interfejsu użytkownika, aby stworzyć dla nich miejsce.
1 Najlepiej, oczywiście, aby wszyscy znali ten język doskonale. Istotne dla krajów, które więcej oprogramowania importują niż eksportują… (przyp. tłumacza).
2 W wersji brytyjskiej będzie to “localisation”, nie “localization” (przyp. tłumacza).
Z powodu zjawiska rozszerzenia, należy szczególnie staranie przetestować te części programu, które mogą ulec zmianie z powodu rozszerzonego tekstu. Warto zwrócić uwagę na tekst, gdzie słowa nie są przenoszone poprawnie do następnej linijki, skracane lub nieprawidłowo dzielone. Może się to zdarzyć gdziekolwiek – w każdym punkcie ekranu, w oknach, na przyciskach itp. Szuka się też sytuacji, gdzie tekst wprawdzie znalazł miejsce do rozszerzenia się, ale przy okazji usunął z ekranu coś innego.
Może się też zdarzyć, że dłuższy tekst spowoduje poważną awarię programu albo nawet awarię całego systemu. Programista mógł był przydzielić dość wewnętrznej pamięci na komunikaty angielskie, ale nie na dłuższe, przetłumaczone ciągi znaków. Wersja angielska będzie działać poprawnie, ale niemiećka ulegnie awarii, kiedy pojawi się jakiś komunikat. Tester stosujący metody szklanej skrzynki może znaleźć ten błąd nie znając ani słowa po niemiećku.
ASCII, DBCS i Unicode
W rozdziale 5-ym „Testowanie oprogramowania z klapkami na oczach” krótko został omówiony zbiór znaków ASCII. ASCII zawiera tylko 256 znaków – zbyt mało, aby zmieścić wszelkie możliwe znaki we wszystkich językach. Kiedy zaczęto wytwarzać oprogramowanie w wielu różnych językach, pojawiła się potrzeba nowych rozwiązań, aby ominąć to ograniczenie. Metoda popularna w czasach MS DOS-u, ale wciąż jeszcze stosowana, nazywana była techniką stron kodowych. Strona kodowa to jakby zastępcza tabela ASCII, z różnymi kodami dla różnych języków. Program wykonywany w Quebec`u na francuskim PC mógł załadować i używać stronę zawierającą francuskie znaki. Rosyjski używa innej strony kodowej dla znaków cyrylicy i tak dalej.
Takie rozwiązanie działa, choć dość niezdarnie, dla języków mających mniej niż 256 znaków. Jednak japoński, chiński i inne języki mające tysiące znaków stwarzają nowe kłopoty. System zwany DBCS (Double-Byte Character Set – zbiór znaków dwubajtowych) stosowany jest przez niektóre programy. Użycie dwóch zamiast jednego bajtu umożliwia zdefiniowanie do 65356 różnych znaków.
Strony kodowe i DBCS często wystarczają, ale jest z nimi kilka problemów. Najważniejszy to kwestia kompatybilności. Jeśli załadować hebrajski dokument na niemiećki komputer z angielskim programem do przetwarzania tekstu, wynika z tego groch z kapustą. Jeśli nie ma się właściwych stron kodowych ani przekładu z jednych na drugie, znaków nie daje się odtworzyć poprawnie.
Wyjściem z tego całego bałaganu jest standard Unicode.
Unicode przypisuje jedną, niepowtarzalną liczbę każdemu znakowi, niezależnie od plaformy, niezależnie od programu,
niezależnie od języka.
„Co to jest Unicode?” z witryny Konsorcjum Unicode www.unicode.org
Unicode jest międzynarodowym standardem, popieranym przez większe firmy produkujące oprogramowanie, przez producentów sprzętu i przez inne organizacje zajmujące się standaryzacją, dzięki czemu stale się rozpowszechnia. Stosuje go większość popularnych aplikacji. Rysunek 10.2 pokazuje jeden z wielu dostępnych zestawów znaków. Jeśli oczekuje się, że program – choćby w przyszłości – będzie ulokalniony, projekt powiniem natychmiast rozstać się ze „starym, dobrym ASCII” i przestawić na Unicode - i w ten sposób oszczędzić sobie czasu, pracy i awarii.
Rysunek 10.2 Okno dialogowe w programie Windows Word 2000 pokazuje wykorzystanie standardu Unicode.
Gorące klawisze i skróty
Po angielsku, nazwa brzmi Search. Po polsku, Szukaj. Po francusku, Réchercher. Jeśli gorący klawisz wybierający funkcję Szukaj w wersji angielskiej jest Alt-S, to w wersji francuskiej należałoby go zmienić na Alt +R.
W ulokalnionych wersjach oprogramowania trzeba przetestować czy wszystkie gorące klawisze i skróty działają prawidłowo i czy nie są zbyt trudne – na przykład wymagają naciśnięcia trzeciego klawisza. I trzeba pamiętać, by sprawdzić, czy angielskie gorące klawisze zostały poprawnie wyłączone.
Rozszerzone znaki
Często spotykanym problemem w ulokalnionych – i nie tylko – wersjach oprogramowania, jest użycie rozszerzonych znaków. W odniesięniu do starożytnej tabeli ASCII, rozszerzone znaki to te, które są poza zwykłymi literami angielskigo alfabetu A-Z i a-z, na przkład é w José albo ñ w el Niño. Jeśli program jest napisany prawidłowo i posługuje się Unicodem albo jeśli poprawnie zarządza stronami kodowymi lub DBCS, nie powinno być kłopotu, ale tester nigdy niczego nie powiniem zakładać, więc warto sprawdzić.
Błędów naeży przede wszystkim szukać wszędzie tam, gdzie program przyjmuje znaki albo produkuje dane wyjściowe. W tych miejscach trzeba użyć rozszerzonych znaków i sprawdzić, czy funkcjonują równie dobrze jak zwykłe znaki. Okna dialogowe, dialogi do wlogowania się i wszelkie inne pola tekstowe powinny być sprawdzone. Czy da się wysyłać i przyjmować rozszerzone znaki przez modem? Czy można je stosować w nazwach plików lub mieć je w plikach? czy zostaną poprawnie wydrukowane? Co się stanie jeśli je wycinać, kopiować i wklejać między testowanym  programem i innymi aplikacjami?
Najprostszy sposób, żeby nie zapomnieć o przetestowaniu rozszerzonych znaków, to doadać je do używanej klasy równoważności zawierającej wszystkie używane przy testowaniu, zwykłe znaki. Oprócz tych często powodujących awarie znaków na krańcach tabeli ASCII, warto dorzucić Æ, Ø, ß, Ę, Ź…
Obliczenia na znakach
Dodatkowy kłopot z rozszerzonymi znakami powstaje wtedy, kiedy oprogramowanie używa znaków do obliczeń. Dwa przykłady to sortowanie teksów i przekształcanie na małe lub na duże litery.
Czy nasze oprogramowanie potrafi wytwarzać posortowane listy wyrazów? Na przykład w liście dających się wybierać pozycji takich jak nazwy plików lub adresy Internetowe? Jeśli tak, to jak należałoby posortować następującą listę słów?
Kopiëren Reiste Ärmlich Arg Reiskorn résumé Reißaus kopieën reiten Reisschnaps reißen resume
Testując oprogramowanie przeznaczone do sprzedzży na rynki azjatyckie, trzeba sobie zdawać sprawę, że kierunek sortowania opiera się na kolejności ruchów pędzla. Niniejsza lista miałoby przypuszczalnie zupełnie inna kolejność, gdyby była napisana po chińsku. Należy sprawdzić, jakie reguły sortowania obowiązują w języku, który się testuje, i skonstruować testy specjalnie nastawione na kontrolę porządku sortowania.
Drugi rejon, gdzie załamują się obliczenia dokonywane na rozszerzonych znakach, to przekształcanie na małe i na duże litery. Problem bierze się stąd, że „sztuczką”, której wielu programistów uczy się jeszcze w szkole, to dodanie lub odjęcie wartości 32 do wartości ASCII danego znaku, by przekształcić go w małą lub dużą literę. Dodając np. 32 do wartości ASCII A otrzymuje się wartość ASCII a. Niestety, ta reguła nie działa dla rozszerzonych znaków. Stosując tę technikę wobec rozszerzonego zbioru znaków Apple Macintosha, przeksztalciłoby się np. Ñ (ASCII 132) w § (ASCII 164), zamiast w ñ (ASCII 150) – nie to o co chodziło.
Sortowanie i przekształcanie znaków w duże i małe to tylko jeden z wielu przykładów. Warto przyjrzeć się uważnie oprogramowniu, którym się posługujemy, aby zidentyfikowć inne sytuacje, gdzie obliczenia wykonywane były wprost na słowach albo na literach. Może programy kontrolujące pisownię?
Czytanie z lewa na prawo i z prawa na lewo
Trudnym orzechem do zgryzienia jest to, że wiele języków, np. hebrajski i arabski, czytają od prawej do lewej, nie zaś od lewej do prawej. Oznacza to, że cały interfejs użytkownika trzeba przerobić w jego lustrzane odbicie.
Na szczęście, większość systemów operacyjnych zawiera wspomaganie dla tych języków. Bez tego, byłoby to zadanie niemal niewykonalne. Tak czy owak, nie jest to już samo proste tłumaczenie. Wkorzystanie funkcji systemowych do wykonania tego przekształcenia wymaga sporej ilości programownaia. Z punktu widzenia testowania, bezpieczniej będzie potraktować to jako zupełnie nowy produkt, nie tylko jako ulokalnianie.
Teksty w grafice
Kolejne problemy pojawiają się, kiedy teksty używane są w grafice. Na rysunku 10.3 znajduje się kilka przykładów.
Rysunek 10.3 Word 2000 zawiera przykłady trudnego do przytłumaczenia tekstu w formie map bitowych.
Ikony na rysunku 10.3 są standardowe dla wybrania Tłustego druku, Kursywy, Podkreśleń oraz Koloru czcionki. Ponieważ te ikony zawierają litery B, I, U i A, nie znaczą nic dla kogoś z Japonii, kto nie zna angielskiego. Można domyślić się znaczenia na podstawie wyglądu – B jest trochę grubsze, I – pochylone, U – podskreślone, ale oprogramowanie nie powinno być zagadką.
Skutkiem tego, ulokalnienie oprogramowania często oznacza, że trzeba wymienić wszystkie ikony. Kidy ikon jest dużo, ulokalnienie może się stać zbyt kosztowne. Należy szukać tych błędów wcześnie w procesię wytwarzania i nie pozwolić, by prześlizgnęły się aż do końca.
Tekst należy przechowywać z dala od kodu
Ostatnim z zagadnień związanych z problemtyką tłumaczeń to kwestia „szklanoskrzynkowa” – trzymanie tekstów w innym mijescu niż kod. Oznacza to, że wszelkie ciągi znaków, komunikaty o błędach, dosłownie wszytko co powinno być tłumaczone, należy przechowywać w osobnych plikach niezależnych od kodu źródłowego. Nie powinno się nigdy znaleźć linijki kodu jak ta: Print „Hello World” Większość osoób zajmujących się lokalizacją nie jest programistami – i nie potrzebuje. Zmuszanie ich do modyfikowania – w ramach tłumaczenia – kodu źródłowego  jest ryzykowne i mało wydajne. To, co powinno zostać przez nich zmienione, to zwykły plik tekstowy, zwany plikiem zasobów, zawierający wszystkie komunikaty wyświetlane przez oprogramownanie. Kiedy oprogramowanie działa, wskazuje teksty z pliku, nie wiedząc ani nie dbając o ich treść. Komunikat po angielsku czy po holendersku zostana tak samo wyświetlone.
Tak więc jest ważnym zadaniem testerów wykonujących testy metodami szklanej skrzynki, by przeszukali kod źródłowy, żeby znaleźć ukryte wbudowane ciągi znaków, których zapomniano umieścić na  pliku zasobów. Mogłoby to spowodować spore zamieszanie, gdyby ważny komunikat a hiszpańskim programie pojawił się nagle po angielsku.
Innym objawem tego problemu są teksty komunikatów dynamicznie generowane przez kod. Na przykład, kawałki tekstu mogą być połączone w dłuższy komunikat. Kod mógłby na przykład mieć trzy ciągi znaków: 1.„Nacisnąłeś klawisz „ 2.zmienna typu  ciąg znaków zawierająca nazwę wlaśnie nacisniętego klawisza, 3.„ w ostatniej chwili!”.
łączone potem w całość, aby stworzyć komunikat. Jeśli zmienny ciąg znaków będzie miał wartość „zatrzymać reaktor atomowy”, komunikat będzie brzmiał:
Nacisnąłeś klawisz zatrzymać reaktor atomowy w ostatniej chwili!
Trudność polega na tym, że nie wszystkie języki mają tę samą kolejność wyrazów w zdaniu. Chociaż ten tekst złożył się ładnie w całość po polsku, byłby bez sensu gdyby go dosłownie przetłumaczyć na chiński albo nawet niemiećki. Nie wolno pozwolić na ciągi znaków w kodzie i nie wolno, by program automatycznie łączył ciągi znaków w dłuższe komunikaty. Kwestie ulokalnienia
Jak już zostało powiedziane, trodności tłumaczenia to dopiero połowa kłopotu. Teksty daję się zwykle łatwo przetłumaczyć, nawet uwzględniając różne znaki i długości ciągów znaków. Dodatkowe trudności pojawiają się, kiedy chce się całe oprogramowanie dostosować do zagranicznego rynku.
Przypomnienie pojęć z rozdziału 3-ego: precyzja, trafność, niezawodność i jakość.
Oprogramowanie dobrze porzetłumaczone i dobrze przetestowane będzie precyzyjne i niezawodne, ale zapewne nietrafne i nie mające wysokiej jakości. Może wyglądać i działać świetnie, dać się łatwo odczytywać i nigdy nie ulegać awarii, ale dla użytkownika z innego kręgu kulturowego może po prostu wydawać się jakieś nie na miejscu. Dopiero dokonanie ulokalnienia produktu pozwoli na osiągnięcie pełnego dostosowania.
Zawartość
Co można by pomyśleć o nowej encyklopedii wydanej na amerykański rynek, gdyby miała zawartość pokazaną na rysunku 10.4?
Piłka nożna Nasza królowa
Budka telefoniczna
Jeździmy zawsze po lewej stronie
Rysunek 10.4 Te przykłady wyglądałyby dziwnie w encyklopedii na rynek amerykański.
W Stanach Zjednoczonych, piłka nożna to nie to samo co futbol!1 Nie jeździ się po lewej stronie. To, co nie obowiązuje w jednym kraju, obowiązuje w drugim! Testując produkt podlegający ulokalnieniu, trzeba starannie przejrzeć jego zawartość, aby upewnić się, że pasuje do obszaru kulturowego, gdzie ma być stosowany.
1 Football to w USA “futbol amerykański”, a soccer to nasza europejska piłka nożna (przyp. tłumacza).
Dotyczy to również wszystkich innych – oprócz kodu – składników produktu informatycznego (zob. rozdział 2-i „Proces wytwarzania oprogramowania”). Poniższa lista zawiera różne elementy produktu, które należy dokładnie zbadać opd kątem ulokalnienia. To nie jest lista wyczerpująca – składniki zależą od rodzaju produktu. Warto pomyśleć, jakie jeszcze inne składniki mogą sprawiać kłopoty, jeśli wysłać je do innego kraju.
Przykłady dokumentacji Ikony Obrazki Dźwięki Wideo Pliki pomocnicze Mapy z kontrowersyjnymi granicami Materiały marketingowe Opakowanie Połączenia internetowe
Za długi nos
W 1993 roku Microsoft wypuścił dwa produkty dla dzieci, zwane Pomysłowy Pisarz i Wspaniały Artysta1. W tych programach występowała postać imieniem McZee, mająca dzieciom pomagać w posługiwaniu się nimi. Wiele trudu włożono w zaprojektowanie McZee, w wybór jego wyglądu, koloru, manieryzmów, osobowości i tak dalej. Wyszedł z tego dość dziwnie wyglądający facet z wystającymi zębami, ciemnopurpurową skórą i dużym nosem.
Kiedy sporo pracy włożono już w animację postaci McZee, telefon zadzwonił w jednym z zagranicznych biur Microsoftu. Otrzymano tam właśnie wstępną wersję programu i po analizie uznano, że była nie do przyjęcia. Powód: McZee miał za długi nos. W tamtejszej kulturze, ludzie z długimi nosami byli rzadkością i – słusznie czy nie – długi nos kojarzył się z mnoóstwem negatywnych stereotypów. Stwierdzono, że produkt nie będzie się w tej postaci sprzedawał.
Storzenie dwóch różnych postaci McZee, każdej na inny rynek, byłoby zbyt kosztowne, więc wyrzucono całą pracę dotąd włożoną, a McZee rozbił sobie nos o pierwszą poważną przeszkodę.
Wypływa stąd nauka, że to treść oprogramowania – czy będzie nią tekst, grafika, dźwięki czy coś innego – ma kluczowe znaczenie dla ulokalniania. Pod tym właśnie kątem należy analizować zawartość programu, a tester – o ile nie ma doświadczenia z lokalnym kręgiem kulturowym – musi mieć do dyspozycji eksperta, który się na niej dobrze zna.
Formaty danych
1 Creative Writer i Fine Artist (przyp. tłumacza).
Różne kraje stosuja różne formaty zapisywania jednostek waluty, czasu i innych wymiarów. Tak jak i z zawartością, nie chodzi tu o samo tłumaczenie, lecz o ulokalnienie. Amerykański program do składu komputerowego, posługujący się calami, nie wystarczy tylko prztłumaczyć na centymetry. Trzeba dokonać zmian w programie we wzorach obliczeń, siatce współrzędnych i tak dalej.
Tabela 10.1 Formaty danych dla różnych krajów Jednostka Możliwe wartości Miary Metryczne lub angielskie Liczby Przecinek lub kropka dziesięta; sposoby umieszczania znaku ujemnego; użycie znaku # na oznaczenie liczby Waluta Różne symbole i gdzie je się umieszcza Data Klejność dnia, miesiąca, roku; znaki oddzielające; zera na początku; długi i krótki format daty Godzina 12-godzinny lub 24-godzinny, znaki oddzielające Kalendarz Różne kalendarze i dni początkowe (miesiąca, tygodnia itp) Adresowanie Kolejność pozycji; użycie kodu pocztowego Numery telefonów Nawiasy, myślniki lub inne znaki oddzielające części numeru od siebie Formaty papieru Różne formaty papieru i kopert
Na szczęście, większość systemów operacyjnych przeznaczonych do użytku w rożnych krajach zawiera gotowe formaty tych rodzajów danych dostosowane do różnych krajów. Rysunek 10.5 pokazuje przykład z Windows 98. Korzystanie z tego wbudowanego wspomnagania ułatwia programistom ulokalnianie programów, ale nie zastępuje myślenia.
Sposób wyświetlania daty nie wpływa na to, jaki format ma data wewnątrz w programie. Na przykład, data może mieć krótki format ddmm-rr. Nie oznacza to, że wewnętrzna reprezentacja daty jest tylko dwucyfrowa (i zawiea w sobie błąd roku dwutysięcznego). W tym wypadku ustawienie oznacza jedynie, że 2 cyfry są wyświetlane. System operacyjny posługuje się czterema cyframi dziesiętnymi do wykonywania obliczeń, o czym warto dodatkowo pamiętać przy testowaniu.

Rysunek 10.5 W Windows 98, opcje Ustawień Lokalnych pozwalają użytkownikom wybrać sposób wyświetlania liczb, waluty, godzin i dat.
Testując oprogramowanie dostosowane do danego kraju, trzeba dobrze znać jednostki miar, których się w nim używa. Aby właściwie przetestować oprogramowanie, trzeba będzie skonstruować nowe klasy równoważności, dostosowane do nowego rodzaju danych. Zagadnienia konfiguracji i kompatybilności
Kwiestie testowania konfiguracji i kompatybilności, omówione w rozdziałach 8-ym i 9-ym, stosują się w pełni do testowania ulokalnionych wersji oprogramowania. Problemy, które pojawiają się, gdy oprogramowanie współdziała z różnym sprzętem i z innymi programami, mogą nasilić się w nowych kombinacjach. Testowanie tego nie będzie koniecznie trudniejsze, może tylko trochę bardziej pracochłonne. Dodatkowym kłopotem może być dostęp do zagranicznych weresji sprzętu i programów, z którymi testowanie trzeba przeprowadzić.
Międzynarodowe konfiguracje platform
Windows 98 obsługije 73 różne języki i 66 różnych układów klawiatury. Realizuje się to poprzez dialog Właściwości Klawiatury w Panelu Sterującym. Rozwijana lista języków zaczyna się od Afrikaans, a konczy na ukraińskim i zawiera dziewięć różnych wersji angielskigo: amerykańską, australijską, brytyjską, kanadyjską, karaibską, irlandzką, z Jamajki, nowozelandzką i południowoafrykańską. Jest tam też pięć różńych dialektów niemieckich i dwadziścia hiszpańskich.

Rysunek 10.6 Windows 98 obsługuje użycie rożnych układów klawiatury i rożnych języków poprzez okno dialogowe Właściwości Klawiatury.
Rysunek 10.7 pokazuje przykłady trzech różnych układów klawiatury przeznaczonych dla różnych krajów. Zauważmy, że każda klawiatura ma klawisze ze znakami danego języka, ale również znaki angielskie. Jest to ddość powszechne, gdyż angielski jest powszechnie znany w wielu krajach, a taki układ pozwala na używanie zarówno oprogramowania lokalnego jak i angielskigo.
Klawiatury to sprzęt najbardziej zależny od języka, ale zaleznie od tego, co się testuje, inne elementy sprzętu też mogą być zależne. Na przykład drukarki muszą poprawnie drukować wszystkie znaki, które oprogramowanie im wysyła, i umieć sformatować dane wyjściowe do różnych formatów papieru w różnych krajach. Jeśli oprogramowanie używa modemu, mogą pojawić się zagadnienia związane z jakością linii telefonicznych lub z różnicami w protokołach telekomunikacyjnych. Każde urządzenie peryfyeryjne pracujące z testowanym oprogramowaniem trzeba wziąć pod uwagę, planując ewentualne zależności od języka i kraju zastosowania.
Konstruując klasy równoważności, trzeba pamiętać, żeby wziąć pod uwagę różne kombinację oprogramowania i sprzętu, które wchodzą w skład platformy. Dotyczy to zarówno sprzętu, programów obsługi i systemu operacyjnego. Posługiwanie się francuską drukarką na Macintosh‘u, z brytyjskim systemem operacyjnym i niemiecką wersją językową testowanego programu może być jak najbardzij dozwoloną konfiguracją!

Rysunek 10.7 Arabska, francuska i rosyjska klawiatura zawiera znaki specyficzne dla danego języka. Za zezwoleniem Fingertip Software, Inc. (www.fingertip.com).
Kompatybilność danych
Tak samo jak testowanie konfiguracji, również testowanie kompatybilności nabiera nowego sensu, kiedy wziąć pod uwagę potrzeby ulokalniania. Rysunek 10.8 pokazuje, jak bardzo złożone może zrobić się przeniesienie danych z jednej aplikacji do innej. Na przykład, nimiecka aplikacja stosująca metryczne jednostki miary i rozszerzony zbiór znaków, może przenieść dane do innej, francuskiej aplikacji zapisując i następnie łądując z dysku, albo posługując się funkcjami wytnij-wklej. Aplikacja francuska może z kolei wyeksportować dane, które jakaś angielska aplikacja może importować. Program angielski, posługujący się brytyjskimi jednostkami miary i nierozszerzonym zestawem znaków, może to wszystko z powrotem przenieść do niemieckiego programu.
Rysunek 10.8 Testowanie kompatybilności danych różnych ulokalnionych wersji programu może być mocno skomplikowane.
W czasie tego przesyłania danych w kółko, przy przekładaniu jednostek miar i rozszerzonych znaków, jest wiele miejsc, gdzie mogą ukrywać się błędy. Niektóre z nich mogły powstać w wyniku błędnych decyzji konstrukcyjnych. Na przykład, co ma się stać z danymi przenoszonymi z jednego do drugiego programu, jeśli musi zostać przy tym zmieniony format? Czy należy zmianę przeprowadzić automatycznie, czy powinno się zapytać użytkownika? Czy należy wyświetlić komunikat o błędzie, czy też tylko przenieść dane i zmienić jednostki miary?
Zanim można zacząć testować kompatybilność ulokalnionego oprogramowania, trzeba mieć odpowiedzi na powyższe pytania. Kiedy już ma się te odpowiedzi, testuje się tak samo jak dawniej – tyle tylko że w klasach równoważności będzie więcej elementów. Jak wiele trzeba testować?
Ważną decyzją, jaką trzeba podjąć przed przystąpieniem do testowania wersji lokalnych programu, jest ile trzeba będzie testować? Jeśli testowanie oryginalnej wersji amerykańskiej zajęło sześć miesięcy, czy testowanie ulokalnionej wersji francuskiej też powinno zająć sześć miesięcy? Czy może jeszcze dłużej, skoro pojawiły się nowe zagadnienia dotyczące konfiguracji i kompatybilności?1
Tę niełatwą decyzję można uprościć do dwóch podstawowych pytań: 55.Czy od początku planowano dokonanie ulokalnienia oprogramowania? 56.Czy w celu dokonania ulokalnienia trzeba było dokonywać zmian w kodzie programu?
Jeśli dostosowanie programu do różnych wersji lokalnych i językowych było planowane od początku, ryzyko pojawienia się wielu błędów i potrzeba rozbudowanego testowania są znacznie mniejsze. Jeśli jednak program był napisany z początku specjalnie po  angielsku pod kątem rynku amerykańskiego, a decyzję o dostosowaniu do innego języka podjęto dopiero poźniej, będzie chyba najlepiej potraktować to oprogramowanie jak zupełnie nową wersję wymagającą pełnego testowania.
Drugie pytanie dotyvczy tego, jakich zmian trzeba było dokonać w całym produkcie. Jeżeli ulokalnianie polega tylko na zmianach w zawartości grafiki i tekstów – to testowanie można ograniczyć do powierzchownej walidacji. Jeśli jednak – z powodu złej architektury systemu albo innych problemów – kod musiał także ulec zmianie, testowanie musi to wziąć pod uwage i skontrolować zarówno treść jak i działanie funkcji.
1 To samo pytanie pojawia się przy każdym testowaniu konfiguracji, a jeszcze ogólniej – przy każdym testowaniu regresywnym, niezależnie od jego przyczyn (przyp. tłumacza).
Decyzja, jaka jest wymagana ilość testowania ulokalnienia, jest decyzją ryzykowną – jak zresztą całe testowanie. Nabierając doświadczenia w testowaniu, uczymy się, co brać pod uwagę w procesie podejmowania decyzji.
Meteodą niekiedy stosowaną przez zespoły testujące, jest testowanie na ile produkt – mający w przyszłości podegać ulokalnieniu – nadaje się do ulokalnienia. Testuje się już pierwszą wersję produktu, zakładając że ulokalnienia zostanie wykonane poźniej. Testerzy stosujący metody szklanej skrzynki badają kod w poszukiwaniu ciągów znaków, właściwego przetwarzania jednostek miar, rozszerzonych znaków i innych zagadnień widocznych na poziomie kodu źródłowego. Czasem nawet robi się własną, „lipną” ulokalnioną wersję. Testerzy stosujący metody czarnej skrzynki starannie badają specyfikacje i sam produkt pod kątem takich problemów jak teksty w grafice albo kwestie konfiguracji. Można treż użyć „lipnej” wersji w celu przetestowania kompatybilności.
W ten sposób, zanim prawdziwe ulokalnienie zostanie dokonane, kłopoty które pojawiłyby się później zostały już wcześniej usunięte, dzięki czemu uloklanienie przebiega później łatwiej i taniej. Podsumowanie
Ha Ön egy rátermett és képzett softver ismerő, és folyékonyan egy nyelvet aż Angolon kívul, Ön egy nagyon piacképes szakképzett személy.
To jest znane już zdanie cytowane na początku tego rozdziału, tym razem napisane po węgiersku. Jeśli nie umie się go przeczytać, nie ma zmartwienia. Dowiedzieliśmy się przecież, że znajomość języka to tylko jedna z wielu umięjętności potrzebnych, by testować produkt poddany ulokalnieniu. Znaczną część pracy wykonuje się kontrolując, na ile produkt nadaje się do ulokalnienia oraz testując sprawy niezależne od języka.
Znając inne języki oprócz angielskiego, i czytając tę książkę aż do końca, żeby nauczyć się jak najwięcej na temat testowania oprogramowania, będzie się miało – jak to przeczytaliśmy przed chwilą po węgiersku – „zespół bardzo dobrze się sprzedających umiejętności”.
Więcej wiadoamości na teamt programowania ulokalnienia i testowania dla Windowsów można znaleźć w www.microsoft.com/globaldev. Dla Macintosha, wiadomości można znaleźć w książce Guide to Macintosh Software Localization, opublikowanej przez Addison-Wesley. Pytania
Pytania mają na celu ułatwienie zrozumienia. W aneksie A „Odpowiedzi na pytania” znajdują się prawidłowe rozwiązania – ale nie należy ściągać! 1.Jaka jest różnica między tłumaczeniem a ulokalnieniem?
2.Czy musi się znać język, aby móc testować produkt poddany ulokalnieniu? 3.Co to jest rozszerzanie tekstu i jakie błedy powoduje? 4.Podaj kilka dziedzin, w których rozszerzony zbór znaków może spowodować kłopoty. 5.Dlaczego tekstowe ciągi znaków należy trzymać poza kodem? 6.Wymień kilka rodzajów formatów danych, które mogą się różnić w różnych ulokalnionych wersjach programu.