Przebranżowienie na testera

Rozdział 12 Testowanie dokumentacji
W TYM RODZIALE Rodzaje dokumentacji oprogramowania Znaczenie testowania dokumentacji Pod jakim kątem testować dokumentację Rzeczywistość testowania dokumentacji
W rozdziale 2-im „Proces wytwarzania oprogramowania” zostało powiedziane, że w skład produktu informatycznego wchodzi – oprócz oprogramowania – wielel innych składników. Ich znaczna część – to dukumentacja.
W dawnych dobrych czasach, dokumentacja składała się co najwyżej z pliku „czytaj.to” na dyskietce razem z oprogramowaniem, albo z jednostronicowej instrukcji włożonej do pudełka z programem. Dzisiaj jest tego znacznie, znacznie więcej – często dokumentacja wymaga więcej pracy i wysiłku niż samo oprogramowanie.
Tester oprogramowania nie musi – wbrew nazwie – ograniczać się do testowania tylko oprogramowania. Odpowiedzialność testera powinna dotyczyć wszystkiego, co wchodzi w skład produktu informatycznego, a więc również kontroli poprawności dokumentacji.
W tym rozdziale zapoznamy się z metodami testowania dokumentacji i z tym, jak włączyć je w całość procesu testowania. Najważniejsze punkty rozdziału to: 104.Różne rodzaje dokumentacji 105.Znaczenie testowania dokumentacji 106.Pod jakim kątem testować dokumentację Rodzaje dokumentacji oprogramowania
Gdyby dokumentacja oprogramowania składała się tylko i wyłącznie z pliku „czytaj.to”, nie byłoby wielkich kłopotów z testowaniem. Wystarczyłoby sprawdzić, czy plik zawiera wszystkie potrzebne dane, czy dane są poprawne technicznie i – na dodatek – możnaby wykonać kontrolę pisowni i przeciwwirusową dyskietki. Ale czasy dokumentcji składającej się tylko z pliku „czytaj.to” dawno minęły.
Dzisiaj dokumentacja oprogramowania stanowi zwykle znaczną część produktu. Czasem można wręcz mieć wrażenie, że produkt to sama dokumentacja z dodaną odrobiną oprogramowania.
Oto lista pozycji które należy zaliczyć do dokumentacji. Nie każdy rodzaj oprogramowania będzie miał wszystkie pozycje z listy, ale i takie mogą się trafić. 107.Tekst i grafika na opakowaniu. Wchodzi w to pudełko, etykiety, obwoluta, plastikowe koperty i tak dalej. Ta dokumentacja często zawiera fragmenty interfejsu oprogramowania, listy funkcji, wymagania systemowe, dane na temat praw autorskich. 108.Materiały reklamowe i marketingowe. To są te papierki które każdy zwykle szybko wyrzuca, ale są to mimo wszystko istotne narzędzia wpierające sprzedaż dodatkowego oprogramowania, umów serwisowych itd. Ta informacja musi być poprawna, aby klienci traktowali ją poważnie. 109.Gwarancja/rejestracja. Ma to zwykle formę formularza, który klient wypełnia i wysyla do producenta aby zarejestrować oprogramowanie. Bywa również częścią oprogramowania, którą klient wypełnia wprost przy komputerze albo nawet potwierdza interakcyjnie. 110.EULA. Wymawia się to „jula” i oznacza End User License Agreement (Umowa Licencyjna dla Użytkowanika Końcowego). Jest to dokument o mocy prawnej, w którym klient zobowiązuje się – między innymi – nie kopiować oprogramowania ani nie pociągnać producenta do odpowiedzialności karnej za szkody spowodowane przez ewentualne awarie oprogramowania. EULA drukuje się niekiedy na kopercie zwierającej nośnik programu – dyskietkę albo CD. Może też pojawić się na ekranie w trakcie procesu instalacji. Przykład EULA znajduje się na rysunku 12.1.
Rysunek 12.1 „EULA” jest częścią dokumentacji oprogramowania i wyjaśnia prawne warunki posługiwania się programem.
111.Etykiety i nalepki. Mogą znajdować się na nośniku informacji (dyskietka, CD), na pudełku, na drukach. Mogą to być też nalepki z numerem seryjnym, albo nalepki których rozdarcie oznacza przyjęcie warunków licencji. Na rysunku 12.2 znajduje się przykład etykiety na dyskietkę i informacja, którą musi się skontrolować. 112.Instrukcje instalacji i ustawień programu. Czasem ta informacja znajduje się na nośniku programu, ale bywa też dołączona jako osobny arkusz, lub – dla skompliwanego oprogramowania – jako cały podręcznik. 113.Podręcznik użytkownika. Użyteczność i elastyczność interakcyjnych podręczników spowodowała, że podręczniki drukowane spotyka się dziś o wiele rzadziej niż niegdyś. Większość programów zawiera obecnie niewielki drukowany podręcznik zawierający podstawowe wiadomości, a wszelkie informacje szczegółowe znajdują się w podręczniku interakcyjnym. Podręczniki interakcyjne rozprowadza się albo razem z oprogramowaniem na tym samym nośniku informacji, albo przez Internet, albo za pomocą obu metod. 114.Pomoc interakcyjna. Pomoc interakcyjna często stanowi jedność z podręcznikiem interakcyjnym, a czasem wręcz go zastępuje. Pomoc intercyjna ma zwykle indeks i daje się przeszukiwać, co wybitnie ułatwia znajdowanie potrzebnej infomacji. Wiele systemów pomocy interakcyjnej pozwala nawet dokonywać poszukiwań przy pomocy pytań fomułowanych w języku naturalnym. Użytkownik może na przykład napisać „Pokaż mi jak skopiować tekst z jedneg programu do drugiego” i otrzymać właściwą odpowiedź.

Nazwa programu
Języki Dane na temat dyskietki
Rodzaje platform dla oprogramowania
Numer identyfikacyjny programu
Instrukcje dla instalacji
Prawa autorskie
Wersja programu
Instrukcje instalacyjne znajdują się w Dokumentacji „Jak zacząć”
Rysunek 12.2 Na etykiecie dyskietki znajduje się dużo informacji, która musi zostać skontrolowana przez testera. 115.Seminaria, programy asystujące, kursy interakcyjne. W tych narzędzich często znajduje się zarówno kod programu jak i pisemna dokumentacja. Często stanowią mieszankę treści tekstowych oraz oprogramowania, zintegrowaną z systemem pomocy interakcyjnej. Użytkownik może zadać pytanie, a program prowadzi go przez wsztkie kroki potrzebne do wykonania zadania. Pomocnik Microsoftu, zwany czasem jako „facet-spinacz” (rysunek 12.3) jest przykładem takiego systemu. 116.Próbki, przykłady, wzory. Przykładem może być program do przetwarzania tekstu, zawierający formularze albo próbki dokumentów, które użytkowanik może wypełnić i szybko uzyskać w ten sposób dokumentcję o profesjonalnym układzie. Kompilatory mogą zawierać fragmenty kodu ilustrujące, jak posługiwać się danym aspektem języka. 117.Komunikaty o błędach. Kilkakrotnie były już w tej książce omawiane jako przykład tematu często zaniedbywanego. Zaliczyć można je również do dokumentacji.

Rysunek 12.3 Pomocnik Micorsoftu jest przykładem bardzo rozbudowanego systemu pomocy i nauczania. Znaczenie testowania dokumentacji
Dla użytkowników wszystkie elementy produktu nie będące oprogramowaniem są po prostu częścią produktu informatycznego. Dla użytkownika jest nieistotne czy dany element został skonstruowany przez programistę, autora tekstów czy też przez grafika. Dla użytkownika istotna jest jakość całego produktu.
Jeśli użytkownik zostanie wprowadzony w błąd przez mylne instrukcje instalacyjne albo przez nieprawidłowe komunikaty o błędach, będzie to dla niego równoznaczne z błędami oprogramowania – które powinny zostać znalezione przez testerów.
Dobra dokumentacja na trzy sposoby wpływa na ogólną jakość produktu: 118.Poprawia użyteczność. Pamiętamy jeszcze z rozdziału 11-ego „Testowanie użyteczności” wszystkie zagadnienia dotyczące użyteczności produktu? Użyteczność zależy w znacznym stopniu od jakości dokumentacji. 119.Podnosi niezawodność. Niezawodność zależy od tego, jak stabilne i spójne jest oprogramowanie. Czy program wykonuje to, czego oczekuje użytkownik, w dodatku we właściwym czasię? Jeśli użytkownik zapoznał się z dokumentcją, posłużył programem i uzyskał nieoczekowane wyniki, mamy do czynienia z niską niezawodnoiścią. Jak dowiemy się w dalszej części tego rozdziału, testowanie oprogramowania przez dokumentacje i dokumentacji przez oprogramowanie jest dobrym sposobem, by znaleźć błędy w jednym i w drugim.
120.Obniża koszty serwisu. Dowiedzieliśmy się w rozdziale 2-im, że błędy znalezione przez użytkownika mogą kosztować 10 do 100 razy więcej w porównaniu z błędami znalezionymi i skorygowanymi wcześniej w procesie wytwarzania produktu. Jedną z przyczyn jest to, że klienci nie mogący spobie poradzić z programem zwracają się do dostwacy o pomoc, której udzielenie jest kosztowne. Dobra dokumentacja może w znacznym stopniu przyczynić się do ograniczenia tych kosztów ułatwiając pracę użytkowników.
Dla testera oprogramowania dokumentacja zasługuje na tę samą uwagę i wysiłek co kod programu. Stanowią one jedną całość dla użytkownika. Pod jakim kątem testować dokumentację
Testowanie dokumentcji odbywa się na dwóch poziomach. Jeśli ona nie jest kodem, jak na przykład drukowany podręcznik użytkownika lub tekst na opakowaniu, testowanie jest statycznym procesem, jak opisany w rozdziałach 4-ym i 6-ym. Można je wówczas traktować jak rodzaj redakcji technicznej lub korekty. Kiedy dokumentacja i kod są ze soba ściśle połączone, jak na przykład w wypadku interakcyjnego podręcznika posługującego się hiperpołączeniami albo w wypadku pomocnego asystentaspinacza, testowanie staje się dynamiczne i stosujemy w nim techniki, które poznaliśmy w rozdziałach 5-ym i 7-ym. Mamy wtedy do czynienia z testowaniem oprogramowania.
Dokumentację najlepiej testować tak samo, jak będzie się nią posługiwał użytkowanik, niezależnie od tego, na ile jest statycznym tekstem, a na ile kodem. Należy ją starannie przeczytać, wykonać każdy z opisanych kroków, sprawdzić każdy rysunek i wypróbować każdy opisany przykład. W ten sposób znajdzie się błędy zarówno w programie, jak i w dokumentacji.
Tabela 12.1 zawiera prostą listę kontrolną do zastosowania przy konstruowaniu zadań testowych do dokumentacji.
Tabela 12.1 Lista kontrolna do testowania dokumentacji

Co sprawdzić Co uwzględnić Zagadnienia ogólne Czytelnicy Czy dokumentacja zwraca się do właściwych czytelników, nie do zbyt początkujących, nie do zbyt zaawansowanych? Terminologia Czy terminologia jest stosowna dla czytelników? Czy nazwy używane są konsekwentnie? Jeśli używa się skrótów, czy są one powszechnie zrozumiałe lub zdefiniowane z tekście? Należy upewnić się, czy nie stosuje się omyłkowo wewnętrznej terminologii stosowanej w firmie. Czy dostępny jest poprawny indeks i referencje do terminologii? Treść i zawartość Czy dokumentcja nie zawiera zbędnych tematów? Czy żadnych zagadnień nie brakuje? Warto zwrócić uwagę na opisy funkcji, które być może zostały usunięte z produktu, o czym jednak nie poinformowano autora dokumentacji technicznej. Czy materiał jest opisany dostatecznie szczegółowo? Poprawność Same fakty Czy informacja jest poprawna technicznie? Warto szukać błędów wynikających z posługiwania się przez autorów przestarzałą specyfikacją lub naginania prawdy przez dział marketingu. Spawdza się także spis treści, indeks i referencje do numerów rozdziałów. Sprawdza się adresy hiperpołączeń. Czy prawidłowo podany jest numer telefonu do obsługi technicznej? Najprościej zadzwonić. Krok po kroku Cały tekst należy czytać powoli i starannie, postępować dokładnie według podanych instrukcji. Niczego nie przyjmuje się za oczywiste. Brakującego opisu nie mależy się próbować domyślać – klienci nie będą wiedzieć, czego brakuje. Uzyskane wyniki należy porównać z podanymi w dokumentacji. Rysunki i fragmenty ekranu Sprawdza się poprawność i dokładność rysunków. Czy ilustracja zawiera właściwą treść? Należy sprawdzić, czy fragmenty ekranu nie pochodzą z poprzedniej wersji produktu. Czy podpisy pod rysunkami są poprawne? Próbki  i przykłady Każdą próbkę należy załadować i użyć tak samo, jak zrobi to  użytkowanik. Jeśli to jest kod, należy go skopiować i wypróbować. Nic bardziej żałosnego niż nie działające próbki kodu – a mimo to spotykamy się z nimi bardzo często!

Pisownia i gramatyka
W doskonałym świecie tego typu błędy nigdy nie docieralyby do testerów. Programy do kontroli pisowni i gramatyki są powszechnie dostępne i należy je stosować. Mogło się jednak zdarzyć, że zapomniano skontrolować fragment tekstu lub że specjalistyczny, techniczny termin uniknął kontroli. Rysunki i ilustracje zawierające fragmenty ekranu były przypuszczalnie sprawdzane tylko ręcznie, więc obowiązje wobec nich zasada ograniczonego zaufania.
W końcu, jeśli mamy do czynienia z dokumntacją „napędzaną programem”, należy ją przetestować tak samo, jak całą resztę oprogramowania. Sprawdza się, czy indeks jest kompletny, czy szukanie daje poprawne wyniki, czy hiperpołączenia i miejsca aktywne prowadzą pod właściwe adresy. Warto posłużyć się techniką podziału na klasy równoważności by zadecydować, co się kontroluje. Rzeczywistość testowania dokumentacji
Na koniec rozdziału trzeba zapoznać się z realiami, które powodują, że wytwarzanie i testowanie dokumentacji różni się jednak od wytwarzania oprogramowania. Rozdział 3-ci nosił tytuł „Testowanie oprogramowania w rzeczywistości”. Poniższe zagadnienia możnaby nazwać realiami testowania dokumentacji. 121.Dokumentacja często otrzymuje najmniej uwagi, środków i osób. Wydaje się istnieć specyficzna mentalność, że w produkcie informatycznym przede wszystkim liczy się oprogramowanie, cała reszta jest drugorzędna. W rzeczywistości klienci kupują cały produkt informatyczny i inne rzeczy są równie ważne jak bajty i bity. Ponosząc odpowiedzialność za testowanie jakiejś funkcji w oprogramowaniu, należy dopatrzyć, by w skład testowania wszedł również test dokumentacji. Należy poświęcić mu tyle samo uwagi co oprogramowaniu i jego błędom. 122.Zdarza się, że osoby piszące dokumentację nie są specjalistami w dziedzinie oprogramowania lub jego zakresu programu. Tak samo jak tester nie musi być ekspertem od rachunkowości by móc testować arkusz kalkulacyjny, tak samo autor dokumentacji nie musi znać doskonale funkcji programu by móc pisać dokumentację. Nie można więc zakładać, że autor zdoła wyobyć prawdę ze źle napisanych specyfikacji i ze skomplikowanych, niejasno udokumentowanych funkcji produktu. Warto blisko współpracować z autorami dokumentacji, by upewnić się, że mają dostęp do potrzebnej informacji i że znaja konstrukcje produktu1. Testerzy mogą też poinformowc autorów dokumentacji, jakie funkcje programu są szczególnie trudne do zrozumienia lub do zastosowania, tak by mogli lepiej wyjaśnić je w dokumentacji.
1 W takim razie testerzy powini mieć pensje prezesów zarządów spółek, skoro maja kompensować niedbalstwo i niekompetencję wszystkich innych osób w firmie i w projekcie… (przyp. tłumacza).
123.Produkcja dokumetacji drukowanej zajmuje tygodnie albo nawet miesiące, podczas gdy oprogramowanie można opublikować niemal natychmiast na Internecie albo na CD. Z powodu tej różnicy, dokumentację często trzeba sfinalizować i zamrozić zanim oprogramowanie zostanie wykończone. Jeśli program zmieni się, albo odkryte zostaną błędy w tym krytycznym dla dokumentacji okresie, nie da się już unacześnić dokumentacji. Dlatego wymyśłono pliki „czytaj.to”. Za ich pomocą można poinformować klientów o zmianach wprowadzonych w ostatniej chwili. Jedyną radą jest mieć i stosować dobry model wytwarzania oprogramowania, powstrzymywać wypuszczenie papierowej dokumentacji jak tylko długo można i publikować jak największą część dokumentacji razem z progamem, na nośniku programu lub na Internecie.
Podsumowanie
Miejmy nadzieję, że ten rozdział zdołał przekonać czytelników, że produkt informatyczny składa się nie tylko z pisanego przez programistów kodu. Dokumentcja oprogramowania – we wszystkich postaciach – sporządzana przez autorów, ilustratorów, autorów indeksacji i tak dalej, może być bardziej pracochłonna przy wytwarzaniau i testowaniu niż samo oprogramowanie.
Z punktu widzenia użytkowanika wszystkio to są składniki tego samego produktu. Błąd w pomocy interakcyjnej, która nie jest w stanie wyjaśnić znacznenia jakiegoś podstawowego określenia, nieprawidłowa instrukcja instalacji czy błąd literowy to takie same błędy jak każdy inny błąd w oprogramowaniu. Testując porządnie dokumentację, znajduje się błędy zanim znajdą je użytkownicy.
W następnym rozdziale zapoznamy się z testowaniem czegoś, co niemal w całości jest samą dokumentacją – tekst, grafika i hiperpołączenia wraz z ukrytą pod nimi platformą. Techniki, które poznaliśmy dotąd, da się znakomicie zastosować do testowania witryn WWW. 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.Uruchom program Paint w Windows (zobacz rysunek 12.4) i poszukaj przykładów dokumnetacji którą należałoby przetestować. Co można znaleźć?
Rysunek 12.4 Jakie przykłady dokumentacji można znaleźć w programie Paint w Windows? 2. Indeks pomocy w programie Paint w Windows zawiera ponad 200 haseł począwszy od dodać własne kolory1, skończywszy na zmiana wielkości obrazu. Czy należy sprawdzić, czy każde z haseł indeksu porwadzi do właściwego rozdziału? Jak należałoby postąpić w przypadku 10000 haseł w indeksie? 3. Prawda czy fałsz: testowanie komunikatów o błędach jest częścią testowania dokumentacji. 4. Jakie są trzy podstawowe powody, dla których których test dokumentacji przyczynia się do poprawy ogólnej jakości produktu informatycznego?

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?