Współpraca programistów z testerami oprogramowania

Współpraca programistów z testerami oprogramowania

Testowanie
oprogramowania
Żaneta Wysocka
Współpraca programistów
z testerami oprogramowania
P
roces testowy polega na kompleksowym
sprawdzeniu jakości testowanego systemu, począwszy od zweryfikowania poprawności funkcjonalnej po sprawdzenie stopnia użyteczności i wygody w korzystaniu z aplikacji przez użytkownika. Poważnie potraktowany proces testowy powinien rozpoczynać się już na etapie dewelopmentu i obejmować testy
modułowe, przeprowadzane najczęściej przez samych
programistów, weryfikujących poprawność kodu źródłowego. Na dalszych etapach obejmuje on testy funkcjonalne poszczególnych modułów systemu, testy integracyjne, a także kończące proces testowy testy akceptacyjne, mające na celu całościową ocenę jakości systemu pod kątem poprawności działania i przystępności
interfejsu użytkownika.
Świadomość wagi procesu testowego jako elementu tworzenia projektu informatycznego staje się coraz
bardziej powszechna pośród kierowników projektów
czy dyrektorów działów produkcji w firmach programistycznych. Nie zmienia to jednak faktu, że instytucja informatycznego działu do spraw jakości nie jest jeszcze
w Polsce tak popularna jak w krajach zachodniej Europy, a przede wszystkim nie jest odpowiednio doceniana, co przekłada się bezpośrednio na prestiż i na zarobki pracowników działu testów.
Tymczasem statystyki są bardzo okrutne i mówią, że tylko 10% projektów informatycznych kończy się sukcesem. Pozostałych 90% nie można
uznać za udane z uwagi na grubo przekroczony
termin, braki w funkcjonalności lub dużą ilość błędów, które ujawniły się na produkcji. Równocześnie można zauważyć, że testowanie aplikacji i jego prawidłowy przebieg ma zasadniczy wpływ na
każdy z tych elementów.
Jednym z powodów, dla których własny dział jakości wciąż nie jest regułą w firmach informatycznych,
jest zarzut zwiększania, w wyniku zastosowania testów,
kosztów wykonania systemu informatycznego. Rzeczywiście, przynajmniej w fazie początkowej jego produkcji, taka sytuacja ma miejsce. Jednak w przypadku procesu testowego potwierdzenie zyskuje zasada mówiąca, że im wcześniej błąd w aplikacji zostanie wykryty,
tym niższy będzie koszt jego naprawy. Efektywnie, pomimo kosztów poniesionych w trakcie trwania dewelopmentu, przeprowadzenie testów pozwala na znaczAnalityk ds. Zapewnienia Jakości w firmie Javart Sp. z o.o.
Od kilku lat bierze udział w testach projektów dla firm
z branży telekomunikacyjnej, ubezpieczeniowej oraz
obsługi klienta.
Kontakt z autorką: [email protected]
22
www.sdjournal.org
ne ograniczenie kosztów poniesionych na serwis wadliwego oprogramowania już po jego wdrożeniu w firmie
klienta lub po wypuszczeniu na rynek.
W przypadku decyzji o wprowadzeniu w firmie programistycznej procesu testowego i uznaniu testów za
stały element projektu informatycznego, pojawia się
pytanie, jak powinien on być zorganizowany. Czy przeprowadzenie testów powinno się pozostawić samym
programistom, czy powierzyć je własnemu działowi
QA (ang. Quality Assurance) – jeśli takowy istnieje – lub
wynajętym testerom z firmy zewnętrznej.
Innym pytaniem jest, jak zdefiniować zadania i obowiązki testera w procesie wytwórczym produktu informatycznego. Czy powinna to być osoba, której praca
ma na celu wyłącznie podstawową weryfikację działania funkcjonalności dostępnych w systemie, czy też powinna być również odpowiedzialna za kontakty z użytkownikiem i skrupulatne sprawdzenie zgodności końcowego produktu ze zgłoszonymi przez użytkownika wymaganiami.
Współpraca
„Tester idealny – wykwalifikowany informatyk czy
laik?”. Odpowiednia osoba na stanowisku testera powinna spełniać dwa bardzo nieprzystające do
siebie warunki. Dobry tester powinien być informatykiem, który paradoksalnie jednak potrafi spojrzeć
na oprogramowanie oczami zwykłego użytkownika. Wiedza informatyczna przydaje mu się w sytuacjach, gdy musi ocenić poprawność działania aplikacji (czy błąd spowodowany jest niewłaściwą konfiguracją, czy nieprawidłowościami w kodzie) lub
w celu poprawnego posługiwania się bazą danych
oraz logami. Z drugiej strony paradoksalnie niewiedza informatyczna użytkowników biznesowych prowadzi często do wygenerowania sytuacji, do której doświadczony informatyk by nie doprowadził.
W żargonie programistów funkcjonuje nawet pojęcie, że dobra aplikacja musi być „idiotoodporna”,
czyli gotowa na dziwne zachowanie użytkowników.
Przykładowo chodzi tu o sytuację, gdzie w pole
o nazwie „wiek” użytkownik wpisuje wartość „abcd”.
Tester powinien sprawdzić również i takie cechy
weryfikowanego systemu.
Z uwagi na wspomniany już niższy prestiż i gorsze
zarobki pracowników działu QA większość informatyków zostaje programistami i administratorami, najlepsi
z nich – projektantami, a na stanowiska testerów zatrudniani są ludzie o bardzo różnym wykształceniu.
Wielu z nich rozumie swoje zadanie wyłącznie jako symulowanie pracy z systemem w środowisku docelowym poprzez wczuwanie się w rolę przyszłych użytSoftware Developer’s Journal 9/2006
Tester oprogramowania
kowników i nie zależy im szczególnie na poznawaniu technologicznych aspektów testowanych systemów. Stają się w ten sposób podatni na manipulacje ze strony programistów. Oprócz celowych zabiegów manipulacyjnych, takich jak rozmowa z pracownikiem działu QA z wykorzystaniem technicznej nomenklatury, bardzo często programiści patrzą na testerów „z góry”. Ci
oczywiście to wyczuwają, a atmosfera pracy nie staje się przez
to przyjazna i nie ułatwia współpracy.
Nierzadko tego rodzaju sytuacja przekłada się na unikanie siebie nawzajem, a czasem nawet na nieprzyjemne plotki.
W krytycznych sytuacjach dochodzi do tego, że nieodpowiednio traktowany dział QA zostaje w oczach nie tylko deweloperów,
ale także odbiorców systemu postrzegany jako niekompetentny,
a ich praca jako część procedury, która musi zostać w projekcie
spełniona, ale nie przynosi pozytywnych efektów.
Rozbieżne cele programisty i testera
Na wzrost napięcia pomiędzy obiema stronami wpływa również odmiennie pojmowany cel pracy programisty i testera.
Podstawowym zadaniem programisty jest napisać w wyznaczonym terminie określony moduł, oczywiście najlepiej nie
popełniając w nim żadnego błędu. Pomimo, że każdy zgodzi się z opinią, że „nie popełnia błędów tylko ten, kto nic
nie robi”, od programistów wymaga się jak najlepszego kodu
z jak najmniejszą ilością błędów.
Natomiast najlepszy tester to taki, który dokładnie
sprawdza każdą właściwość aplikacji, znajduje w niej jak
najwięcej błędów i ma zawsze dużo konstruktywnych uwag.
Tester, który nie znajduje podczas testów żadnego błędu,
albo zgłasza ich znikomą ilość, jest postrzegany jako ten,
który pracował niewłaściwie.
Widać zatem, że zadania pracowników działu oprogramowania i działu jakości są w zasadzie sobie przeciwstawne. Sukces
programisty – bezbłędnie napisana aplikacja – najczęściej rzuca
podejrzenie na niewłaściwą pracę testera. Sukces testera – duża
liczba uwag i znalezionych błędów – jest identyfikowany z jednoczesną porażką dewelopera. Duża liczba błędów to najczęściej
dodatkowa praca przy ich poprawianiu, którą nierzadko trzeba
wykonać po godzinach. Nietrudno więc zgadnąć, że oba działy, mimo że potrzebują siebie i są dla swego funkcjonowania niezbędne, nie darzą się szczególną sympatią.
Najbardziej napięte sytuacje występują wtedy, kiedy tester
zgłasza błąd, a deweloper próbuje przeforsować zmniejszenie
jego wagi lub tłumaczyć sytuację jako poprawną, winę przenosząc na niewłaściwą konfigurację, czy na awarię sieci. Trzeba
przy tym zaznaczyć, że pracownik działu jakości nie zna bardzo
często szczegółów technicznych aplikacji i trudno mu odeprzeć
argumenty, które przedstawia wykwalifikowany informatyk. O ile
błąd jest błędem i konieczność poprawienia go wydaje się naturalna, o tyle sugestie i uwagi mówiące, że coś (np. interfejs użytkownika) jest niewygodne lub nieintuicyjne to kwestie bardzo indywidualne, więc sporne. Osoby występujące w obu rolach bronią swoich racji, coraz bardziej popadając w konflikt.
Ostatnie zdanie i tak najczęściej należy do testera i programista ostatecznie musi zgodzić się z jego opinią. Podczas weryfikacji poprawności to tester jest ważniejszy i to on decyduje
o końcowym wyniku raportu z testów. W przypadku negatywnego zakończenia testów, czując się przegranym, programista mo-
Rysunek 1. Źle zorganizowana współpraca testerów z programistami prowadzi często do dużej liczby zgłoszeń błędów i uwag
odrzucanych przez programistów – zduplikowanych lub nie uznanych z innego powodu (zgłoszenia zaznaczone na różowo).
Nadmierna liczba zgłoszeń tego typu szybko prowadzi do zaostrzenia stosunków między obiema stronami. Wszystkie rysunki
przedstawiają przykładowe ekrany w systemie obsługi błędów Mantis
Software Developer’s Journal 9/2006
www.sdjournal.org
23
Testowanie
oprogramowania
że jednak i bardzo często to czyni, w ramach złośliwego rewanżu utrudniać pracę testerom przy następnych testach. To dział
dewelopmentu przygotowuje dokumentacje i instrukcje obsługi,
z których dział testów korzysta. W trakcie, gdy tester zapoznaje
się z nowym systemem, potrzebuje wielu wyjaśnień i konsultacji,
po które zwraca się oczywiście do deweloperów.
Na szczęście wśród programistów świadomość roli testera
w procesie powstawania systemów informatycznych systematycznie rośnie – coraz częściej uświadamiają sobie, że ich nadrzędny cel zawsze jest taki sam – stworzenie produktu jak najwyższej jakości. A to założenie najprawdopodobniej nie zostanie zrealizowane, jeżeli którakolwiek ze stron nie będzie chciała współpracować i postawi na mniej lub bardziej otwarty konflikt
z drugą stroną.
Ograniczenie współpracy
Tu dochodzimy do zasadniczego pytania – jaki jest najbardziej
optymalny z punktu widzenia pracowników i firmy model współpracy programistów i testerów. W dużych firmach organizuje
się całkowicie odrębne działy, nie mające ze sobą bezpośredniej styczności. W ich przypadku taki model wynika poniekąd ze
względów finansowych – firmy te mają do dyspozycji wystarczające środki pieniężne, aby zorganizować dwa odrębne działy –
produkcji i zapewniania jakości oprogramowania.
Kluczowym powodem jest jednak przeświadczenie, że
rezygnacja z bliskiej współpracy programistów z testerami
zapewnia tym drugim pełną niezależność podczas wykony-
wania testów. Oznacza to, że tester nie jest wówczas podatny na wpływ programistów – na zakres i sposób wykonywania testów.
Podstawowym zadaniem testerów w firmie o takiej strukturze
pracy jest wyszukiwanie jak największej liczby błędów i wysyłanie do programistów zgłoszeń o ich wykryciu. Najczęściej przy
takim modelu współpracy nie ma możliwości wspólnego ustalenia, czy dany problem rzeczywiście wynika z błędu popełnionego przez programistę, czy też niewystarczającej wiedzy testera
na temat testowanego produktu.
Przyjęcie w firmie tego modelu współpracy wpływa niejednokrotnie na znaczące pogorszenie stosunków panujących pomiędzy programistami a testerami. Zdarza się wówczas, że programiści obciążani są w trakcie trwania testów
masą problemów, które nie są związane z błędami w kodzie
i zajęcie się nimi nie leży w gestii programistów (lecz np. administratorów istniejącego już systemu, z którym komunikuje się testowana aplikacja).
Ocena pracy testerów
Problem narasta, jeżeli dodatkowo w firmie przyjęty jest system
oceny testerów, zgodnie z którym są oni oceniani na podstawie liczby zgłaszanych programistom błędów lub uwag w określonym czasie (dziennie, tygodniowo itp.). W praktyce ma to taki skutek, że testerzy, chcąc osiągać wysokie wyniki, zobligowani
są do stałego „podnoszenia” statystyki liczby znalezionych błędów. Wbrew pozorom, tego rodzaju postępowanie z reguły nie
Rysunek 2. W przypadku złej współpracy pomiędzy programistami i testerami wiele zgłoszeń nie jest szybko rozwiązywanych,
lecz prowadzona jest bezprzedmiotowa dyskusja, której jedynym widocznym skutkiem jest tylko stopniowe pogorszenie
wzajemnych stosunków
24
www.sdjournal.org
Software Developer’s Journal 9/2006
Tester oprogramowania
przynosi pozytywnych efektów. Testerzy wysyłają programistom
ogromną ilość zgłoszeń, chociaż często na pierwszy rzut oka
jest oczywiste, że nie są one związane z błędami w kodzie źródłowym. Bardzo często dochodzi również do zgłaszania błędów
i uwag już wcześniej zgłoszonych przez innych testerów (Rysunek 1). Jest to problem szczególnie uciążliwy dla deweloperów,
ponieważ mają oni obowiązek odpowiadania na każde zgłoszenie błędu, nawet zduplikowane. W ten sposób konflikt pomiędzy
programistami a testerami narasta. Programiści zarzucają testerom marnowanie ich niewątpliwie cennego czasu na odpowiadanie na wszystkie zgłoszenia błędów, niekiedy faktycznie pozbawione podstaw (Rysunek 2). Z kolei testerzy kierują się przede
wszystkim potrzebą osiągnięcia maksimum zgłoszonych błędów w określonym czasie, co najczęściej wynika z konieczności
sprostania systemowi oceny efektywności ich pracy. Takie podejście powoduje, że na drugi plan odsuwają oni dobre stosunki
z programistami – autorami testowanego systemu. Należy w tym
miejscu zaznaczyć, że nie chodzi tu o podejście polegające na
stawianiu na pierwszym miejscu koleżeńskich stosunków z programistami, lecz o efektywną, korzystną dla obu stron, jak również w rezultacie dla testowanego produktu – współpracę.
W opisywanej sytuacji pojawia się zagrożenie, że tester nie
poświęci wystarczająco dużo czasu na znalezienie poważnych,
ale najczęściej głęboko ukrytych błędów, które mogą zadecydować o późniejszym powodzeniu lub porażce produktu na rynku
lub u bezpośredniego odbiorcy zamówionego rozwiązania. Skupi się za to na znalezieniu błędów mało istotnych z punktu widzenia odbiorcy, chociaż niewątpliwie niejednokrotnie dla użytkownika uciążliwych. A zrobi tak, ponieważ tego rodzaju błędy są najczęściej po prostu łatwe do znalezienia i idealnie „podnoszą statystykę”. Znalezienie błędów krytycznych wymaga z reguły sporego wysiłku, wielu prób i szczegółowego rozpatrywania wszelkich wątpliwości. Zwłaszcza w przypadku tego ostatniego punktu konieczna jest współpraca z programistami, gdyż bez pomocy z ich strony tester tylko w niektórych sytuacjach jest w stanie
sam stwierdzić, czy uzyskany efekt działania jest zgodny z oczekiwanym.
Programista w roli testera
Część firm decyduje się z różnych powodów, głównie finansowych, na inny sposób przeprowadzania testów. Testerem jest
w tym przypadku sam programista – twórca oprogramowania.
Zapewne część programistów mogłaby przyklasnąć temu pomysłowi argumentując to mniej więcej tak: „po co testerzy, sam najlepiej wiem, co mam przetestować w swoim systemie – w końcu
znam go od podstaw.”
Jednak takie podejście z pewnością nie jest w dalszej perspektywie korzystne dla jakości testowanego produktu. Oczywiście programista wie, co koniecznie powinno zostać szczegółowo sprawdzone w jego systemie, ale niekoniecznie musi chcieć
znajdujące się w nim błędy znaleźć. W końcu nie po to intensywnie pracuje przez długi czas przy tworzeniu tego rozwiązania,
żeby je na koniec niszczyć – a tak często programiści definiują
testy – jako destrukcyjne podejście do testowanego produktu.
Ponadto udowadnianie samemu sobie, a także innym –
przełożonym czy innym programistom, że pisząc kod, popełniło się wiele błędów, z pewnością nie jest postrzegane przez wielu programistów jako zjawisko pozytywne. Testy nie mają, rzecz jasna, na celu wytykania autorom popełnionych błędów, lecz wykrycie błędów i usunięcie przez
programistów ich przyczyn w celu poprawienia jakości produktu. Pomimo to, programiści zbyt często traktują wykrycie błędu i konieczność jego poprawienia zbyt personalnie
i z tym większymi oporami biorą pod uwagę możliwość samodzielnego wyszukiwania błędów w swoim kodzie.
Programista prawdopodobnie dość często będzie starał się
tak testować, aby żadnych, albo jak najmniej błędów znaleźć –
innymi słowy, aby udowodnić, że błędów w systemie nie ma i jest
on całkowicie niezawodny. W takim przypadku testy zupełnie mijają się z ich rzeczywistym celem.
Rysunek 3. Dobrze zorganizowana współpraca obu stron umożliwia zgłaszanie tylko faktycznych błędów i ich szybką naprawę,
bez straty czasu na długotrwałe wymiany zdań dotyczące zgłoszeń odrzucanych przez programistów
Software Developer’s Journal 9/2006
www.sdjournal.org
25
Testowanie
oprogramowania
Zresztą nie tylko programistom zdarza się pojmować w ten
sposób sens testowania – również część testerów podchodzi do
testów z tego typu założeniem – udowodnienia, że system działa
prawidłowo, co niejednokrotnie niweczy powodzenie testów. Jednak takie zagrożenie występuje rzadziej wśród testerów niż programistów z prostej przyczyny – tester wie (a przynajmniej powinien wiedzieć), jakie jest jego zadanie w procesie testowania i nie
ma, w przeciwieństwie do programistów, dylematu związanego
z procesem tworzenia produktu, a następnie udowadniania, że
jednak nie jest on niezawodny i zawiera błędy.
Bliska współpraca
Jak dotąd przedstawione zostały dwie drogi wykonywania testów w typowej firmie zajmującej się dostarczaniem rozwiązań
informatycznych. Jednak żadna z nich nie jest optymalna z punktu widzenia menadżera, który chce zaoferować klientom maksymalnie niezawodny i dostosowany do ich potrzeb produkt. W takiej sytuacji pozostaje jeszcze trzecia droga, łącząca dwa wcześniejsze sposoby organizacji testów w firmie – można zdecydować się na bezpośrednią współpracę testerów z programistami.
Nie na zasadzie prostego zgłaszania opisu błędu i odpowiedzi
na to zgłoszenie, lecz kompleksowej współpracy na całym etapie przeprowadzania testów systemu.
Korzyści są obopólne – zarówno dla programistów, jak i testerów, a w efekcie – oczywiście dla użytkowników systemu. Testerzy mają możliwość poznawania systemu bezpośrednio od jego twórców, którzy wiedzą, jak kod źródłowy w założeniu powinien być wykonywany. Mogą na bieżąco omawiać z programistami zaistniałe nieprawidłowości w wykonywanym programie. Mają możliwość, bez ryzyka narażania się na konflikt z programistami, wyjaśniania sytuacji, które mogą, chociaż wcale nie muszą,
być związane z błędami w kodzie (Rysunek 3). Mogą otrzymywać sugestie od programistów, które z elementów testowanego
rozwiązania są szczególnie narażone na występowanie błędów,
zatem powinny zostać przetestowane ze szczególną uwagą. Mają możliwość pokazywania programistom na bieżąco ścieżek postępowania prowadzących do wystąpienia błędu (Rysunek 4).
Może się wtedy szybko okazać, że błąd jest spowodowany nieprawidłowym działaniem testera, a nie błędem aplikacji. Przy odtwarzaniu przez programistę sposobu postępowania wyłącznie
na podstawie opisu sporządzonego przez testera jest większe
prawdopodobieństwo, że wykona on test nieco inaczej lub wprowadzi niejednakowe dane testowe. Taka bezpośrednia współpraca, oprócz niewątpliwych zalet, posiada oczywiście również
pewne wady. Testy powinny być przeprowadzane maksymalnie
niezależnie od sugestii autorów systemu, co kłóci się ze stwierdzeniem zamieszczonym powyżej. Programista z jednej stro-
ny świetnie zna system, ale z drugiej, co jest zupełnie zrozumiałe, nie do końca zależy mu, żeby ktoś wytykał mu błędy oraz starał się skutecznie zepsuć owoc jego pracy, w którego tworzenie
deweloper włożył mnóstwo wysiłku. Dlatego programista może, ale nie musi, pomóc testerowi zlokalizować miejsca w systemie szczególnie podatne na występowanie błędów (a przecież
w każdym systemie takie miejsca występują).
Nastawienie programisty
Oczywiście bardzo dużo zależy w tym przypadku od podejścia
samego programisty do idei współpracy z testerem. Jeżeli programista będzie traktował testera jako „zło konieczne”, to z pewnością nie będzie próbował ułatwiać mu pracy, czyli wyszukiwania i lokalizacji błędów w swoim systemie. Jeżeli jednak zrozumie, że znalezienie przez testera jak największej liczby błędów
leży w interesie ich obu, a w dalszej perspektywie – użytkownika systemu, powinien zmienić swoje podejście do współpracy
z testerem. Wiadomo przecież, że zadowolenie użytkowników
korzystających z tego produktu równa się w rezultacie lepszej
ocenie i wzmocnieniu pozycji firmy na rynku.
Doświadczenie wskazuje na to, że o pozytywne i otwarte podejście programistów do współpracy z testerami łatwiej jest właśnie w firmach, gdzie obowiązuje model bezpośredniej współpracy. Programista, nawet początkowo pracujący z testerami raczej
z przymusu niż osobistej potrzeby wspólnej pracy nad wytworzeniem produktu wysokiej jakości, po pewnym czasie zaczyna dostrzegać zalety tego celowego „psucia” testowanego rozwiązania. Później nawet pracując w firmie o innym modelu współpracy, inaczej odnosi się do zgłoszeń błędów i uwag testerów, a także do nich samych. Co ważne, nie jest z góry nastawiony do testerów niechętnie i z dystansem, czy nawet agresywnie – jako
do osób „niszczących” materialny efekt jego pracy. Ale przede
wszystkim rozumie potrzebę wspólnego działania na rzecz wykonania najlepszego na rynku, pozbawionego błędów produktu.
Kontakty z użytkownikiem
Na początku niniejszego artykułu padło stwierdzenie, że jednym z najważniejszych zadań testera, oprócz efektywnej współpracy z programistami, jest poznanie wymagań przyszłego użytkownika testowanego rozwiązania informatycznego. W tym miejscu warto poświęcić kilka słów na poruszenie tego niezmiernie
istotnego aspektu pracy testera. Potrzeba uczestnictwa testera
w całościowym procesie powstawania produktu wydaje się być
niepodważalna. Świadomy celu swojej pracy tester podchodzi
do testów systemu kompleksowo, uwzględniając zarówno racje
programistów – autorów tego rozwiązania, dotyczące wymagań
i ograniczeń technicznych, jak również potrzeby użytkownika.
Rysunek 4. Zgłoszenie od razu omówione i potwierdzone przez programistę i testera, najczęściej jest szybko rozwiązywane, co
ułatwia wzajemną współpracę i usprawnia przeprowadzanie testów rozwiązania
26
www.sdjournal.org
Software Developer’s Journal 9/2006
Tester oprogramowania
W przypadku potrzeb późniejszego użytkownika programu, zależnie od tego, czy system jest tworzony na konkretne zamówienie klienta, czy też ma być typowym „produktem pudełkowym”,
przeznaczonym dla szerokiego kręgu odbiorców, tester powinien
uwzględniać nieco odmienne oczekiwania tego odbiorcy.
Współpraca testera z klientem
W przypadku rozwiązania tworzonego na zamówienie, tester
jest odpowiedzialny m.in. za uwzględnienie w trakcie testów gotowego produktu wszystkich wymagań użytkownika, jeżeli tylko
możliwe jest sprostanie im pod względem technicznym. Jeśli pojawiają się tego typu trudności, bardzo ważnym zadaniem testera staje się bycie elementem pośredniczącym pomiędzy programistami, którzy zgłaszają trudności w wykonaniu danego wymagania, a użytkownikiem, który chce, aby jego koncepcja została
zrealizowana w całości. Tester powinien w takiej sytuacji z jednej
strony potrafić wypracować z programistami wspólne stanowisko
dotyczące rzeczywistych możliwości realizacji wszystkich wymagań użytkownika. Nie może ono jednak polegać na zbyt daleko
idących ustępstwach wobec programistów. Dotyczy to zwłaszcza kwestii mało istotnych z punktu widzenia dewelopera (chociaż niejednokrotnie łatwych do wykonania od strony technicznej), ale o kluczowym nieraz znaczeniu, albo co najmniej uciążliwych dla przeciętnego użytkownika.
Z drugiej strony tester staje często wobec znacznie trudniejszego zadania przekonania klienta do racji strony przeciwnej, czyli właśnie zespołu programistów tworzących zamówiony
produkt. Dużo tu zależy nie od umiejętności technicznych testera i tzw. „nosa” do wyszukiwania głęboko ukrytych błędów ujawniających się w specyficznych warunkach, lecz od umiejętności
współpracy z klientem i przekonywania do swoich (czytaj: programistów) racji. Oczywiście dotyczy to tylko firm, gdzie przyjęte
jest, że tester współpracuje z klientem na etapie testów akceptacyjnych lub jeszcze dewelopmentu systemu, połączonego z bieżącymi testami aktualnie dodawanych modułów.
Rola testera w tworzeniu gotowego
„rozwiązania pudełkowego”
Jeżeli system ma mieć charakter „produktu pudełkowego”
i być kierowany do dużo szerszego, a zarazem silniej zróżnicowanego kręgu odbiorców, zadanie testera staje się jeszcze bardziej odpowiedzialne i skomplikowane. Musi wówczas starać się przewidzieć bardzo różnorodne oczekiwania użytkowników wobec systemu i sposoby ich postępowania. A te, jak pokazuje praktyka, często są wyjątkowo oryginalne i trudno przewidywalne. W tego rodzaju procesie wytwórczym celem testera staje się nie tylko przeprowadzenie
typowych testów funkcjonalnych czy wydajnościowych, ale
też opartych na własnej intuicji i doświadczeniu wnikliwych
testów użyteczności i przystępności systemu dla przeciętnego użytkownika. Mówiąc innymi słowami, tester powinien
„wejść w skórę” zwykłego użytkownika, który kupuje gotowy produkt i chce, aby był on prosty, logiczny i zrozumiały,
a dodatkowo niezawodny.
Podsumowanie
Tester może w pełni udowodnić znaczenie swojej pracy w procesie wytwórczym oprogramowania wówczas, gdy posiada możliwość bezpośredniej i bieżącej współpracy z programistami,
a także z klientem, jeżeli produkt jest tworzony na zamówienie.
Software Developer’s Journal 9/2006
Nie umożliwia tego w wystarczającym stopniu model współpracy opisany na początku niniejszego artykułu, polegający na
relacji „zgłoszenie – odpowiedź na zgłoszenie” pomiędzy testerami a programistami. Pozwala on co prawda na wykonywanie
przez testera jego podstawowych zadań, czyli zgłaszania informacji o wykrytych błędach oraz własnych sugestii na temat możliwości podwyższenia jakości systemu. Jednocześnie znacząco ogranicza wpływ testera na to, czy zgłoszone błędy rzeczywiście zostaną poprawione, a uwagi uwzględnione – zwłaszcza z realizacją tego drugiego punktu dość często pojawiają się
trudności. Podobnie testy akceptacyjne systemu przeprowadzane przez programistów – jego autorów nie realizują wszystkich
wymagań, jakie powinny spełniać w założeniu kompleksowe
i obiektywne testy.
W tym przypadku należy pamiętać o jeszcze jednej, istotnej sprawie, o której dość często się zapomina. Programista, jako osoba na co dzień obcująca z podobnymi systemami i biegle
znająca zasady ich działania bardzo często nie potrafi wczuć się
w rolę przeciętnego użytkownika i odtworzyć w pełni, na potrzeby własnych testów, jego toku myślenia i sposobu postępowania.
A przecież nie zawsze użytkownik korzystający później z systemu porusza się tak sprawnie w nieznanym mu środowisku, jak
programista, znający ten system „od podszewki”.
Dodatkowo programiście niekoniecznie musi zależeć na znalezieniu błędów w swoim systemie, gdyż może to traktować jako osobistą porażkę i złe świadectwo wystawione jego pracy. Nie
ulega wątpliwości, że testy modułowe wykonywane przez programistów na poszczególnych etapach dewelopmentu są niezbędne, ale testy akceptacyjne, kończące proces wytwórczy
produktu i uwzględniające szerokie potrzeby użytkowników końcowych, powinny być wykonywane przez wykwalifikowanych testerów świadomych wyzwań, jakim powinny sprostać dobrze wykonane testy gotowego systemu. I mowa w tym miejscu nie tylko
o testach sprawdzających podstawowe funkcje programu, ale też
jego użyteczność, łatwość w obsłudze oraz intuicyjność. A ponadto, co nie mniej istotne – weryfikujących, jak system reaguje na nieprawidłowe działania lub dane wejściowe oraz czy poprawne wykonywanie swoich typowych działań przez system nie
wiąże się z występowaniem niepożądanych zjawisk.
Jeżeli tylko w firmie zajmującej się produkcją systemów informatycznych istnieje możliwość przeprowadzania testów akceptacyjnych przez własny lub zewnętrzny zespół testerów,
z pewnością należy z takiej możliwości każdorazowo korzystać.
Dobrze spełniający swoje obowiązki tester wie, na czym powinna polegać owocna współpraca z zespołem programistów, ale
też nigdy nie pominie uwag i potrzeb tego, kto rzeczywiście będzie korzystał w dalszej perspektywie z testowanego rozwiązania. Chodzi tu oczywiście o użytkownika końcowego, niezależnie
od tego, czy będzie to klient indywidualny, zamawiający specyficzny produkt czy szeroki odbiorca, kupujący produkt gotowy.
Najbardziej prawdopodobne jest spełnienie tych postulatów
w przypadku bezpośredniej i kompleksowej współpracy testera
z programistami, jak również z późniejszym użytkownikiem systemu, jeżeli produkt jest tworzony na konkretne zamówienie.
Zawsze jednak należy pamiętać o tym, że zapewnienie jakości systemów informatycznych zależy przede wszystkim od własnego, bezpośredniego zaangażowania w ten proces zarówno
programistów, jak i testerów, gdyż najbardziej istotny jest osobisty wkład osób biorących udział w procesie wytwórczym, niezależnie od przyjętego modelu współpracy. n
www.sdjournal.org
27