Rozdział 15

Rozdział 15  Polowanie na błędy i testowanie beta
W TYM ROZDZIALE Nie wszystko da się zauważyć Jak podzielić się testowaniem Testowanie beta Jak zlecić testowanie innej firmie
W rozdziale 14-ym „Automatyzacja i narzędzia do testowania” dowiedzieliśy się, jak technologia w postaci narzędzi pozwala uczynić testowanie skuteczniejszym. Zastosowanie programów do testowania programów jest świetną metodą przyśpieszenia pracy i sposbem na znajdowanie błędów, które trudno byłoby znaleźć inaczej.
Innym sposobem uczynienia pracy testera skuteczniejeszą jest wykorzystanie innych ludzi. Gdyby udało się znaleźć więcej osób - niekoniecznie zawodowych testerów - do testowania, można by znajdować błędy przeoczone przez testerów w projekcie.
Najważniejsze punkty tego rozdziału: 47.Czemu ważne jest wykorzystanie wielu osób do testowania 48.Jak znaleźć ludzi 49.Co to jest testowanie beta i jaką rolę mają w nim testerzy 50.Jak skutecznie zlecić testowanie innej firmie Nie wszystko da się zauważyć
Na rysunku 15.1 znajdują się dwa niemal identyczne obrazki, przedstawiające tę samą scenę. Teraz wyjmujemy timer do jajek, nastawiamy go na minutę i szukamy różnic między obrazkami. Zapisujemy znalezione różnice i kolejność, w jakiej je znajdowaliśmy.
Rysunek 15.1 Ile różnic między obrazkami zdąży się znaleźć w ciągu minuty. Ilustracja za zgodą www.cartoonworks.com.
Teraz dajmy to samo zadanie kilku kolegom i porównajmy uzyskane listy. Okazuje się, że każdy ma trochę inne wyniki. Ile różnic się znalazło, które i w jakiej kolejności -  będzie różne dla różnych osób. Jeśli teraz połączyć te listy i odrzucić duplikaty, otrzyma się pełniejszą listę różnic - ale nawet wtedy nie ma pewności, czy znalezione zostały wszystkie.
Tak samo rzecz się ma z testowaniem oprogramowania. Pracuje się pod presją harmonogramu, znajduje błędy w dostępnym nam czasie, ale jeśli pozwolić poszukać też komuś innemu, znajdzie on przypuszczalnie jeszcze inne błędy. Może to zniechęcać. Można sobie pomyśleć: jak można było - mimo całej ciężkiej pracy - przeoczyć taki oczywisty błąd? Jest to jednak całkiem normalne i jest na to kilka sposobów. 51.Wykorzystanie drugiej pary oczu zapobiega paradoksowi pestycydów. Jak widać na przykładzie eksperymentu z rysunkiem 15.1, ludzie zauważają różne rzeczy. Błędy które z jakiegoś powodu przeoczy jedna osoba, z łatwościa może zuważyć ktoś inny. 52.Tak samo jak różni ludzie zauważają różne rzeczy, rozmaicie też zabierają się za wykonanie tej samej pracy. Tester dokonał starannej analizy specyfikacji i wybrał zadania testowe, ale zawsze ktoś inny może wziąć pod uwagę coś, co mu nie przyszło do głowy - nacisnąć inny klawisz, kliknąc myszą szybciej, uruchomić funkcję w inny sposób. Mamy tu ponownie do czynienia z paradoksem pestycydów. 53.Mając kogoś do pomocy, łatwiej uporać się z nudą. Testowanie tego saego raz po razie, używanie ciągle tych samych funkcji programu szybko staje się monotonne. Nuda powoduje rozproszenie uwagi i można wtedy przeoczyć najbardziej oczywiste błędy. 54.Patrzeć jak ktoś inny zabiera się za rozwiązanie zadania jest świetnym sposobem nauczenia się nowych technik testowania, które potem można dodać do swego repertuaru sposobów.
Łatwo ulec pokusie i chcieć zachować wyłączność oraz całą odpowiedzialność za „swój” kawałek testowanego oprograowania, ale lepiej tego unikać. Pozwalając innym sobie pomóc, mżna wiele zyskać. Jak podzielić się testowaniem
O ile nie pracuje się w bardzo małym projekcie, zapewne kilka osób będzie zajmować się testowaniem. Jest wiele sposobów na to, by więcej niż jedna osoba szukała błędów w tej samej części programu.
Testerzy mogą - na kilka godzin albo na kilka dni - zaienić się swoimi zadaniami. „Ja wykonam twoje testy, a ty wykonaj moje”. Obie strony zyskają dzięki temu dodatkowe, niezależne spojrzenie na testowany produkt lub jego część. Każdy może się też nauczyć nowych sposobów - i dzieki temu wymyslic później nowe zadania testowe. Warto przynajniej znaleźć kogoś, żeby przyjrzał się wybranym przez siebie klasom równoważności i zadaniom testowym. Na podstawie swego doświadczenia ktoś inny może zaproponować dodatkowe obszary do przetestowania.
Zabawnym sposobem podzielenia się pracą przy testowaniu jest „tłuczenie błędów”. Polega to na tym, że na jakiś czas - zwykle na kilka godzin - zawiesza się zwykłe zadania i wszyscy razem biorą udział w „tłuczeniu błędów”. Wybiera się jeden fragment czy aspekt oprogramowania i wszyscy koncentrują się na nim. Wybrać można na przykład obszar, gdzie było szczególnie wiele błędów, żeby sprawdzić czy nic tam więcej się już nie kryje. Albo można wybrać fragment podejrzanie bezbłędny - taki zmasowany atak pozwoli ustalić, czy błędy ukryły się przed zwykłymi testami, czy też ma się do czynienia z rzeczywiście dobrze napisanym fragmentem kodu. Objekt „tłuczenia błędów” można wybierać na podstawie rozmaitych kryteriów, ale wspólnym celem jest zawsze to, by wiele różnych osób jednocześnie szukało błędów w na ty samym terenie.
Sprzyierzeńcem w polowaniu na błędy jest dział wsparcia klientów - ludzie, którzy mają kontakt z klientami potrzebującyi pomocy albo instrukcji. Ci ludzie są bardzo czuli na punkcie błędów i moga naprawdę wiele pomóc przy testowaniu. Warto dowiedzieć się, kto będzie odpowiadał za pomoc klientom i poprosić te osoby o wzięcie udziału w testowaniu. Będą potrafili znaleźć zdumiewające błędy.
Bodaj najczęściej dział obsługi klienta spotyka się z problemami z zakresu użyteczności. Wiele pytań przychodzi od osób, które po prostu usiłują zrozumieć, jak posłużyć się oprogramowanie. Dlatego warto spróbować włączyć osoby z działu obsługi w testowanie jak najwcześniej, żeby wcześnie mogli pomóc znaleźć i naprawić właśnie błędy użyteczności. Testowanie beta
Opisane dotąd metody podzielenia się testowaniem mają charakter wewnętrzny - to znaczy osoby, które nam pomagają, należą do tego samego zespołu testującego albo do tego samego projektu. Inną powszechnie stosowaną metodą walidacji i weryfikacji oprogramowania przy pomocy innych osób jest tak zwane testowanie beta.
Testowanie beta polega na tym, że oprogramowanie jest testowane przez wybranych klientów (lub potencjalnych klientów) w rzeczywistym, operacyjnym środowisku. Testowanie beta zwykle stosuje się pod koniec projektu i właściwie powinno być wyłącznie walidacją tego, że oprogramowanie jest już zupełnie gotowe do dostarczenia klientom.
Cele testowania beta mogą być rozmaite: począwszy od tego, żeby spowodować pojawienie się w fachowej prasie wczesnych artykułów na temat tego oprogramowania, poprzez walidację interfejsu użytkownika, aż po ostatni atak w poszukiwaniu błędów. Tester powinien umieć zakomunikować osobom kierującym testami beta, jaki jest - z jego punktu widzenia - ich cel.
Następujące rzeczy warto wziąć pod uwagę planując testowanie beta: 55.Kim są osoby wykonujące testowanie beta? Jest to ważne w kontekście przyjętego celu testowania. Na przykład producent może być zainteresowany znalezieniem pozostałych jeszcze problemów z użytecznością, ale testerami beta okazują się być doświadczeni programiści, bardziej zainteresowani działaniem na niskim poziomie, nie zaś użytecznością. Jeśli tesowanie beta ma przynieść spodziewane korzyści, trzeba z góry określić, kto powinien je wykonywać. 56.Skąd będzie wiadomo, czy wykonawcy testów beta rzeczywiście używali rorgramu? Jeśli 1000 osób miało program do dyspozycji przez miesiąc i nie raportowało żadnych problemów, czy to znaczy że nie było żadnych błędów, czy też że błędy znajdowano ale nikt nie potrudził się napisaniem raportu, czy też że raporty zostały zagubione na poczcie? Często się zdarza, że osoby mające wykonać testowaniue beta przystępują do tego dopiero po pewnym czasie, a ponadto wykonują je tylko w ograniczonym zakresie. Trzeba dopatrzeć, by mieć nad ty wszystkim kontrolę. 57.Testowanie beta często jest dobrym sposobem znajdowania błędów konfiguracji i kompatybilności. Jak dowiedzieliśy się w rozdziałach 8-ym „Testowanie konfiguracji” i w 9-ym „Testowanie kompatybilności”, trudno jest zidentyfikować i przetestować reprezentatywną próbę możliwych układów sprzętu i programów. Jeśli uczestnicy testów beta zostali trafnie wybrani z grupy potencjalnych klientów, powinni znaleźć wiele problemów dotyczących właśnie konfiguracji i kompatybilności.
58.Testowanie beta może też dać interesujące wyniki w zakresie testowania użyteczności, jeśli właściwie wybrało się jego uczestników - odpowiednią mieszanke osób o różnym poziomie doświadczenia. Widząc oprogramowanie po raz pierwszy, będą mogli bez trudu zauważyć wszelkie mylące czy trudne do zastosowania funkcje. 59.Oprócz konfiguracji, kompatybilności i użyteczności, testowanie beta jest zdumiewająco nieefektywne w znajdowaniu błędów. Uczestnicy często nie mają dość czasu na używanie programu, tak że znajdują tylko najbardziej oczywiste, powierzchowne problemy - przypuszczalnie i tak są już one znane wytwórcy. Poza tym, ponieważ testowanie beta zwykle odbywa się pod koniec cyklu wytwarzania, nie ma zbyt wiele czasu na naprawianie znajdowanych błędów.
Jednym z największych zagrożeń w projekcie wytwarzania oprogramowania jest próba potraktowania testowania beta jako namiastki prawdziwcyh testów. Nie wolno tego robić!  Jeśli to miałoby zadziałać, czemu nie zrobić tego samego również z projektowaniem i implementacją oprogramowania? 60.Program testowania beta zajmuje dużo czasu. Często początkujący testerzy otrzymują właśnie za zadanie pomaganie klintom w ich problemach, odpowiadanie na ich pytania i potwierdzanie znalezionych przez nich błędów. Wykonując takie zadanie, trzeba też współpracować z resztą zespołu testującego, aby zrozumieć, dlaczego błędy nie zostały znalezione wczesniej i zaplanować poprawienie zadań testowych tak, żeby ich nie móc ponownie przeoczyć w przyszłości. To wszystko łatwo wypełnia cały czas pracy, tak że nie zostaje go już na testowanie samemu.
Planując program testowania beta, należy zaplanować go zawczasu, najlepiej jeszcze w czasie ustalania harmonogramu projektu. Trzeba zadbać o to, by cele testowania beta pokrywały się z potrzebami zespołu testującego i współpracować ścisle z kierownikiem tego programu tak, by głos testerów był brany pod uwagę.
Testowanie beta może być dobry sposobem uzyskania niezależnych wyników testów, ale aby mógł on być skuteczny, trzeba nim opowiednio pokierować - można niemal powiedzieć, że trzeba go odpowiednio… przetestować.
Jak zlecić testowanie innej firmie
Często spotykaną praktyką w wielu firmach jest zlecenie wykonania części testowania przedsiębiorstwom specjalizującym się w różnych aspektach testowania. Chociaż może to się wydawać bardziej skoplikowane i niewygodne niż zlecenie wykonania tej samej pracy testerom we własnym zespole projektowym, jest to zwykle skuteczny sposób podzielenia się odpowiedzialnością za testowanie - jeśli zrobić to z głową.
Zwykle dobrze jest zlecić innnej firmie test konfiguracji i kompatybilności. Ten rodzaj testów wymaga dużego laboratorium z wieloma rozmaitymi platformami sprzętowymi i z różnymi rodzajami oprogramowania, wraz z kilkuosobowym personelem zarządzającym tym wszystkim. Większość małych firm nie może sobie pozwolić na koszty utrzymania takich laboratoriów. Jest sensownym wariantem przekazać takie zadanie firmom specjalizującym się w tego typu testowaniu.
Testowanie ulokalnienia też dobrze nadaje się, by zlecić jego wykonanie komuś innemu. O ile zespół testerów nie jest naprawdę wielki, trudno oczekiwać by mieć do dyspozycji pracowników znających wszelkie języki, w których program ma działać. Może się opłacać mieć w zespole kilku testerów znających obce języki, aby zidentyfikować podstawowe problemy, ale najpewniej lepiej jest powierzyć całość testów przedsiębiorstwu mającemu odpowiednie kompetencje. Takie firmy dysponują zwykle psrsonelem zarówno znającym języki, jak i znającym się na testowaniu.
Początkujący tester zapewne nie będzie musiał podejmować decyzji w sprawie tego, jakie rodzaje testów można powierzyć innej firmie, ale może musieć współpracować z taką firmą, jeśli testuje ona oprogramowanie, za które jest się odpowiedzialnym. Wówczas powodzenie lub niepowodzenie pracy firmy wykonującej testy może zależeć od współpracy z tym właśnie testerem. Oto lista spraw, które trzeba uwzględnić, aby współpraca przebiagała jak najlepiej: 61.Jakie dokładnie zadania zostały powierzone tej firmie? Kto je definiuje? Kto je weryfikuje i zatwierdza? 62.Jaki jest harmonogram ich pracy? Kto go ustala? Jakie będą skutki ewentualnych opóźnień? 63.Jakie dostawy ma otrzymywać firma wykonująca testy? Przykłady to specyfikacja, kolejne dostawy nowych wersji i zadania testowe. 64.Jakie mają być dostawy z firmy testującej do producenta oprogramowania? Co najmniej musi to być lista znalezionych błędów.
65.Jakie będą sposoby porozumiewania się z firmą? Telefon, poczta komputerowa, Internet, wspólna baza danych, codzienna wizyta? Osoby wyznaczone jako odpowiedzialne za współpracę i kontakt z obu stron. 66.Skąd będzie wiadomo czy testująca firma wywiązuje się ze swoich zobowiązań? Skąd firma ma wiedzieć czy spełnia oczekiwania zleceniodawcy?
To wszystko nie jest wprawdzie ścisłą matematyką, ale często te banalne sprawy są zapomniane w pośpiechu, aby jak najszybncie przekazać testowanie wybranej firmie. Postawa, aby jak najszybciej „pozbyć się” programu i zwalić jego testowanie na kogoś innego, to recepta na klęskę. Pod warunkiem jednak właściwego planowania całego przedsięwzięcia, przekazanie części testów innej firmie może być skutecznym sposobem na wykonanie specjalistycznych testów, na których wykonanie samemu nie ma się odpowiednich środków. Podsumowanie
Wnioski jakie należy wynieśc z tego i z poprzedniego rozdziału są takie, że wszelkie środki są dobre, żeby stać się lepszym testerem. W jednej sytuacji trzeba posłużyć się technologią, w innej postarać się o pomoc innych ludzi, jeszcze inna wymaga brutalnej siły - testowania ręcznego. Każda sytuacja jest inna i przy każdej można sie czegoś nowego nauczyć. Trzeba eksperymentować, próbować różnych podejść, obserwować jak robią inni - i cały czas mieć na uwadze skutecznośc testowania i prawdopodobieństwo znajdowania błędów.
Ten rozdział zamyka część książki poświęconą sposobom wykonywania testowania. To była dobra zabawa. Poznaliśmy proces wytwarzania oprogramowania, podstawowe techniki testowania, jak je stosować, jak je wspomagać. W części V-ej "Praca z dokumentacją" zobaczymy, jak to wszystko czego nauczyliśmy się dotąd połączyć w całość: jak zaplanować i zorganizować testowanie, jak zapisywać i śledzić znajdowane błędy, i jak mieć pewność, że zostaną odpowiednio naprawione. 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.Opisz paradoks pestycydów i w jaki sposób zaangażowanie nowych osób w testowanie może mu zapobiec. 2.Jakie są możliwe korzyści programu testowania beta? 3.Z czym należy zachować ostrożność planując testowanie beta? 4.Jeśli pracuje się w małym przedsiębiorstwie robiącym oprogramowanie, czy warto przekazać test konfiguracji innej fimie?