specyfika pracy projektowanie, wykonywanie i utrzymywanie testów podejście i metodyka realizacji zadań.

Transkrypt

1 Testowanie określane jest jako proces sprawdzania oprogramowania w celu zweryfikowania, czy spełnia ono określone wymagania. Jest to również działanie zmierzające do wykrywania błędów. Zgodnie z tą definicją, testowanie ma na celu wspomóc udoskonalanie produktu informatycznego. Co jednak dzieje się w przypadku, gdy sam proces testowania jest daleki od doskonałości i występują w nim błędy? Jak przekłada się to na jakość pracy i wyniki testów? W praktyce okazuje się, że bardzo łatwo jest popełnić błędy podczas organizacji lub samego wykonywania testów. Niektóre z owych błędów pojawiają się tak często, są powtarzane tak wiele razy przez różnych ludzi, że można określić je mianem klasycznych. Błędy popełniane przez testerów najczęściej wiążą się z następującymi kwestiami: rola i cel testowania komu ma służyć testowanie i jak je wykonywać, jakie cele stawiać przed testami; planowanie testowania organizacja pracy zespołu testowego, wybór technik, metod i podstaw (test basis); kwestie personalne kto powinien, a kto nie, testować oprogramowanie? Cechy osobowości, umiejętności i predyspozycje osób wykonujących prace związane z QA; specyfika pracy projektowanie, wykonywanie i utrzymywanie testów podejście i metodyka realizacji zadań. Niniejszy artykuł przedstawia subiektywną listę 10 najczęściej popełnianych przez testerów błędów, prowadzących do spadku efektywności procesu testowego, otrzymywania nieprawdziwych lub mylących rezultatów testów oraz pojawiania się sytuacji konfliktowych i niepewności w projekcie. Podejmując się organizacji i planowania procesu testowego, należy odpowiedzieć w pierwszej kolejności na pytanie jaka ma być rola i cel naszego procesu? Komu testowanie ma służyć i jak je wykonywać? W wielu firmach informatycznych pokutuje błędne przekonanie, że do testowania nadaje się każdy nie jest wszak niczym szczególnie trudnym sprawdzenie, czy oprogramowanie działa w taki sposób, jak to opisuje dokumentacja (specyfikacja). Tymczasem jest wręcz odwrotnie nie każdy ma predyspozycje do tego, aby być dobrym testerem. Dobry tester zaś to taki, który nie tylko potrafi zweryfikować poprawność oprogramowania z projektem, ale i znaleźć błędy wynikające z niewłaściwej specyfikacji (np. niespójnych wymagań) czy wręcz braku specyfikacji (brak opisu fragmentu systemu). Dobry tester powinien być mądrzejszy zarówno od programisty jako, że ma znaleźć błędy przeoczone podczas implementacji systemu jak i od analityka biznesowego (projektanta) żeby, gdzie trzeba udowodnić, że analityk pomylił się dokumentując wymagania i projektując aplikację. Często popełnianym błędem jest wykonywanie testów w sposób powierzchowny i niedo- 1

2 kładny. Jest to szczególnie widoczne w przypadku testów opartych na specyfikacji funkcjonalnej lub innej dokumentacji wymagań. Niekiedy testerzy wychodzą z założenia, iż sprawdzą tylko to, co jest wyraźnie udokumentowane, bez wgłębiania się w szczegóły i wyszukiwania luk czy niespójności w opisie. Jeśli dokumentacja nie precyzuje wszystkich możliwych ścieżek przebiegu procesu, sprawdzą tylko te, które opisano przykładowo, jeśli specyfikacja nie obejmuje walidacji danych wejściowych, a dotyczy tylko scenariuszy pozytywnych, tester sprawdzi tylko te pozytywne. Nie przetestuje wprowadzania danych niewłaściwego formatu, błędnych z punktu widzenia biznesowego (np. wykonywanie transferów pieniężnych na kwotę większą niż dostępna na koncie testowym), nie sprawdzi zależności między polami. Dobry tester to taki, który działa: metodycznie i systematycznie; dyplomatycznie ale i stanowczo w razie potrzeby, aby udowodnić swoje racje; z dużą dozą ostrożności i sceptycyzmu, szczególnie w przypadku wszelkiego typu założeń, i chce widzieć konkretne dowody działania danej funkcji. Tester powinien też: mieć szczególny zmysł obserwacji i zauważania szczegółów; charakteryzować się znakomitymi umiejętnościami werbalnymi i komunikacyjnymi a to w celu informowania innych członków zespołu projektowego o znalezionych problemach i wyjaśniania istoty problemu w sposób jasny i jednoznaczny. Nawet najbardziej dokładny i spostrzegawczy tester z dogłębną znajomością testowanej aplikacji nie zdziała wiele, jeśli nie będzie w stanie przekazać swoich spostrzeżeń i uwag; wyczuwać sytuacje, czy funkcje aplikacji, które mogą nie być zrozumiałe dla innych (tj. programistów) i gdzie wręcz należy spodziewać się błędów; tester może też przewidywać pojawianie się problemów, opierając się na swoim dotychczasowym doświadczeniu; być ciekawy (-ski) i eksperymentować próbować rozmaitych kombinacji działań i scenariuszy, aby zobaczyć co się stanie. Osoba, której głównym dążeniem jest jedynie szybkie wykonywanie powierzonych jej zadań od do, nie nadaje się na testera ponieważ zrealizuje w 100% swoją pracę, ale nie pomoże aktywnie ulepszyć aplikacji. Dość często zdarza się, że dokumentacja projektowa, stanowiąca podstawę do testowania, nie jest najlepszej jakości. Funkcjonalność nie jest opisana wystarczająco dokładnie, nie obejmuje wszystkich możliwych przebiegów procesu, specyfikacja nie uwzględnia opisów danych lub wyjątków. Jak w takiej sytuacji zaplanować i realizować testy? Uboga dokumentacja analityczna (specyfikacja) nie pomaga w wystarczającym zrozumieniu działania aplikacji. Tester przygotowujący się do pracy często musi domyślać się, jak aplikacja ma działać i interpretuje funkcjonalność według własnego rozumienia. Czasami zdarza się też tak, że tester nie potrafi wczuć się w rolę użytkownika systemu i nie wyobraża sobie celu działania aplikacji. Nie potrafi odtworzyć scenariuszy użytkowania systemu, ponieważ nie rozumie, po co ów system istnieje. W takich przypadkach nie da się przecenić doświadczenia i wiedzy w danym obszarze przykładowo, testerzy posiadający szeroką wiedzę z zakresu finansów czy bankowości, mają doskonałe wyniki pod względem efektywności testowania i wykrywania krytycznych błędów w systemach produkowanych dla tych właśnie branż. Programiści pytani o najbardziej irytujące zwroty w raportach błędów często wymieniają następujące: dokumentacja sugeruje; wydaje się, że; prawdopodobnie; przypuszczalnie. Takie sformułowania skutecznie odstraszają programistów od rozpoczynania prac nad danym błędem. Dlaczego? Ponieważ wskazują, że sam tester nie jest pewien, czy opisuje błąd, a w takim wypadku nie warto się owym zgłoszeniem zajmować. 2

3 Dość często praktykowanym zwyczajem jest odkładanie zgłaszania błędów na później. Niektórzy testerzy organizują sobie pracę w taki sposób, że realizują w całości pewien etap testów, notują znalezione przypadki, a dopiero po zakończeniu cyklu raportują wyniki w systemie śledzenia błędów. Przykładem niech będzie następująca organizacja testów (rysunek 1). Jak widać na schemacie, zgłaszanie błędów rozpoczyna się dopiero po czwartym dniu realizacji testów. W tym czasie cały zespół deweloperski jest bezczynny natomiast piątego dnia zaczynają napływać zgłoszenia błędów od wszystkich testerów. Na naprawę owych błędów programiści mają 4 dni wliczając w to analizę i reprodukcję problemu, implementację i przetestowanie poprawki oraz zatwierdzenie kodu w przygotowaniu do nowej wersji systemu. Nie pozostaje więc zbyt dużo czasu na efektywne zaplanowanie prac i przydział zadań deweloperom. W przypadku otrzymania dużej liczby zgłoszeń błędów, pojawia się ryzyko niedotrzymania terminu i opóźnienia przygotowania następnej, poprawionej, wersji systemu. Organizacja testów w ten sposób nie jest ani efektywna, ani praktyczna w pierwszym tygodniu programiści są bezczynni, w drugim testerzy. Gdyby testerzy zgłaszali problem bezpośrednio po ich znalezieniu, umożliwiliby programistom natychmiastowe podjęcie prac naprawczych i tym samym oszczędzenie czasu. Dodatkowo programiści mogliby w każdej chwili poprosić testerów o zaprezentowanie sposobu reprodukcji błędu ponieważ ci ostatni byliby akurat w trakcie weryfikacji systemu. Z praktyki wiem, że odkładanie zgłaszania błędów jest samo w sobie jednym z największych błędów. Z jednej strony, przez połowę czasu część zespołu projektowego jest niemal bezczynna, z drugiej ani programiści, ani testerzy nie współpracują ze sobą, ponieważ ich cykle pracy mijają się w czasie. Podczas gdy zespół testerów pracował, programiści wykonywali swoje zadania np. rozbudowywanie funkcjonalności czy implementację nowych modułów nie interesując się kondycją aplikacji poddanej testom. Natomiast po ukończeniu testowania role się odwróciły zespół QA zakończył prace związane z wykonywaniem przypadków testowych i podjął inne, dotyczące głównie aktualizacji i dodawania scenariuszy dla następnego cyklu testów. W tym czasie nie mogli, ani nie wykazywali chęci powracania do sprawdzonej już wersji systemu celem ponownej reprodukcji błędu, o którą prosił zdezorientowany programista. To jeden z najbardziej irytujących nawyków testerów. Błędy, które w rzeczywistości nie są błędami, z reguły dotyczą: braku wiedzy testera odnośnie funkcjonalności; 3

4 braku wiedzy technicznej; niewłaściwego zarządzania zmianami. Czasami tester nie zrozumie do końca logiki aplikacji, nie orientuje się zbyt dobrze w regułach biznesowych lub nie ma wystarczającego doświadczenia i każdą swoją wątpliwość zgłasza jako błąd. Jeśli na przykład tester nie zna reguł obowiązujących w bankowości i procedur instytucji, której oprogramowanie testuje, może traktować jako błąd sytuacje całkowicie poprawne z punktu widzenia biznesu. Innego rodzaju problemem jest zgłaszanie zmian jako błędów. Źródła takiej sytuacji są dwa: zgłaszanie zmian na życzenie klienta; zgłaszanie zmian jako inicjatywa własna testera - w celu udoskonalenia aplikacji lub poprawienia niedoskonałej dokumentacji analitycznej. Czasami kierownictwo projektu godzi się na praktykę zgłaszania zmian w systemie śledzenia błędów pod odpowiednią kategorią (CR). Z reguły nie jest to jednak właściwa metoda ponieważ po pierwsze psuje statystyki błędów i może dawać złudzenie, że jest ich o wiele więcej, niż w rzeczywistości; po drugie zaś, każda zmiana powinna być zgłaszana jako Change Request i poddana procesowi zarządzania zmianami. Zarządzanie zmianami umożliwia analizę wpływu zmiany na dotychczasowy system, pozwala zaplanować wdrożenie zasoby, terminy, koszty w optymalny sposób. Ponadto należy pamiętać, że każda zmiana systemu wymaga akceptacji kierownictwa projektu i biznesu jako że ingeruje w zaakceptowany już projekt oprogramowania. Nie wystarcza więc fakt, iż np.klient, czy też jakikolwiek inny członek projektu, zgłosi prośbę o zmianę. Konieczna jest również analiza, akceptacja i zaplanowanie wdrożenia i weryfikacji zmiany a najlepiej dokonać tego formalną ścieżką procedury zgłaszania zmian. Zgłaszanie zmian jako zwykłych błędów jest jedną z praktyk najbardziej irytującą programistów z tej prostej przyczyny, iż implementacja zrealizowana przez nich jest zgodna z dokumentacją systemu, jakiekolwiek więc zmiany i poprawki do dokumentacji powinny być komunikowane analitykom twórcom dokumentacji. Zdarza się, iż tester interpretuje specyfikację systemu według własnego rozumienia i zgłasza błędy tam, gdzie ich nie ma. Sytuacja taka ma miejsce szczególnie w przypadku, gdy dokumentacja jest na tyle niedokładna i niejednoznaczna, że dopuszcza wiele możliwości rozwiązań. Przykład dokumentacja opisuje możliwość dodawania, edycji i usuwania rekordu z tabeli. Niektórych rekordów (np. aktywnych kont użytkownika) nie można usuwać. Dokumentacja nie mówi jednak nic o tym, że dla takich rekordów nie powinna być dostępna opcja usuwa- 4

5 nia walidacja odbywa się już po próbie wykasowania, za pomocą komunikatu błędu. Tester zakłada, że oczywiste jest zablokowanie możliwości usuwania takich pozycji (czyli np. brak przycisku usuń w tabeli) i zgłasza odpowiedni błąd. Programista odrzuca błąd, gdyż implementacja jest zgodna z wymaganiami nie ma zapisu mówiącego o tym, że dla określonych danych nie powinno być opcji usuwania. Testerzy próbują też ulepszać aplikację i wprowadzać własne poprawki tam, gdzie wydają się im one konieczne. O ile działania takie mają sens i są wysoce wskazane na etapie przeglądu dokumentacji, o tyle mogą wprowadzać niepotrzebne zamieszanie już po akceptacji i podpisaniu specyfikacji. Na etapie implementacji i testowania, każda, najwet najmniejsza zmiana kodu mająca na celu poprawienie wyglądu aplikacji, może mieć negatywny wpływ na stabilność i niezawodność systemu. Należy pamiętać o tym, iż nigdy nie da się wyeliminować ryzyka regresji i pojawienia się nowych błędów. Innego rodzaju kwestią jest interpretacja wyników testów. Zdarzają się sytuacje, w którch tester zgłasza błąd, ponieważ według niego rezultat wykonania procedury testowej powinien różnić się od obecnego. Przykład w przypadku błędu walidacji danych wejściowych system wyświetla komunikaty informujące o rodzaju nieprawidłowości. Komunikaty wyświetlane są w górnej części ekranu aż do momentu, w którym użytkownik systemu poda prawidłowe dane. Tester zgłasza błąd polegający na tym, że nie da się zamknąć wiadomości o błędzie klikając na znak X, będący pierwszym znakiem w każdym komunikacie. W jego opinii, możliwość zamknięcia błędu usprawniłaby działanie aplikacji w znaczący sposób mimo, że działanie takie jest standardowym sposobem walidacji danych w danej technologii i nie może być zmienione. Najbardziej lakoniczny opis błędu, z jakim się spotkałam to: this button doesn't work. Wyrażenie to opisywało wszystko lokalizację błędu, procedurę odtworzenia, etc. Dla zgłaszającego problem był oczywisty, ponieważ widział ów button na ekranie przed oczyma i ewidentnie mógł stwierdzić błędne działanie. Odbierający to zgłoszenie nie był już taki pewien, o co chodzi brakowało opisu modułu i strony w aplikacji, na której miał być umiejscowiony przycisk, nie wyjaśniono, w jaki sposób przycisk funkcjonuje obecnie, a jak powinien zgodnie ze specyfikacją. Proste stwierdzenie nie działa miało wyjaśniać wszystko. Opisywany przypadek jest jednym z najbardziej drastycznych, lecz doskonale wyjaśnia, dlaczego zgłaszanie błędów z odpowiednio dokładnym opisem jest tak istotne. W mojej opinii, brak wystarczającej informacji przy zgłaszaniu błędów jest jednym z najważniejszych problemów występujących w procesie testowania. Nie tylko drastycznie zmniejsza efektywność testowania i wydłuża proces naprawiania błędu, ale i w wyraźny sposób wpływa na pogorszenie atmosfery panującej pomiędzy zespołami testerów a deweloperów. nazwa (tytuł) błędu jest mylący, nie dotyczy problemu bezpośrednio lub wskazuje na wystąpienie problemu w zupełnie innej części aplikacji. Tytuł nie mówi więc, gdzie jest błąd i czego ogólnie dotyczy, a powinien dawać pewien pogląd na istotę sprawy. Niektórzy testerzy praktykują zasadę umieszczania w tytule błędu jedynie nazwy strony lub modułu, w którym znaleziono problem. Tym sposobem w systemie śledzenia błędów może pojawić się kilkadziesiąt zgłoszeń o tej samej nazwie, a każdy będzie dotyczył czego innego. Jest to nie tylko mylące i dezorientuje programistów, ale i innych członków projektu w tym i testerów, którzy będą zmuszeni za każdym razem czytać szczegóły zgłoszenia, aby przypomnieć sobie, o co chodziło w danym przypadku; brak opisu, jak zreprodukować problem. Testerzy nie dostarczają procedury (kroków) użytych do uzyskania błędu, lub opisana procedura nie działa np. nie zawiera danych wejściowych, niezbędnych do reprodukcji problemu (z innymi danymi scenariusz testowy może działać prawidłowo); brak wyjaśnienia, jaki jest problem. Opis 5

6 błędu często zawiera sekwencję kroków oraz rezultat ich wykonania, bez oczekiwanego rezulatu. Czasem opis błędu przedstawia tylko kroki bez określenia, w którym momencie wystąpił problem, na czym polegał i dlaczego jest to błąd w jaki sposób system powinien się zachować; niewłaściwe i nieracjonalne ustalanie priorytetu błędu. Dla niektórych testerów każdy problem ma najwyższy priorytet niezależnie od tego, czy jest to kwestia błędu w działaniu krytycznej ścieżki, czy literówka w nazwie pola. Prawidłowe określanie priorytetów jest dość istotną kwestią, jako że większość team leaderów zespołów programistycznych planuje implementację poprawek, kierując się właśnie priorytetami błędów (wysokie priorytety rozwiązywane są w pierwszej kolejności). Innego rodzaju problemem związanym z nadawaniem priorytetów jest pomniejszanie wagi problemu czasami testerzy ulegają presji; brak określenia wersji systemu, w której znaleziono błąd. Bez tej informacji zgłoszenie nie powinno być w ogóle przyjmowane, ponieważ nie daje żadnego punktu odniesienia, która z wersji kodu zawiera błąd. Nie wszystkie błędy pochodzą od testerów niektóre zgłaszają sami klienci (użytkownicy systemu). W większości przypadków takie zgłoszenia opisane są nie dość dokładnie, by umożliwić programistom zrozumienie problemu i opracowanie poprawki. Użytkownik nie ma ani odpowiedniego przygotowania testerskiego, ani wiedzy pozwalającej odpisywać problemy tak jak zawodowy tester. Nie powinno się też tego od niego wymagać jednym z obowiązków testerów producenta oprogramowania jest wspieranie rozwiązywania problemów zgłoszonych przez klienta poprzez analizę takich zgłoszeń, reprodukowanie ich w środowisku testowym i dostarczanie programistom dokładnego opisu i procedury odtworzenia błędu. Tester powinien też przyjąć do wiadomości dwa podstawowe fakty związane z otrzymaniem zgłoszenia od klienta: Obszar aplikacji działa nieprawidłowo. Wiadomo, iż błędy mają tendencję do występowania grupami. Jeśli w danym module systemu pojawia się problem, istnieje duże prawdopodobieństwo, że błędów jest więcej. Tester powinien dokładnie sprawdzić moduł, by wykluczyć lub znaleźć pozostałe problemy. Aplikacja nie została wystarczająco przetestowana. Błąd znaleziony dopiero przez klienta to ostatnia rzecz, jakiej może sobie życzyć producent oprogramowania, gdyż jednoznacznie świadczy o niskiej efektywności testów wewnętrznych. Pojawia się pytanie, jakim sposobem testerzy nie znaleźli problemu wcześniej, skoro jest na tyle widoczny, że zauważył go klient? Odpowiedź jest prosta ponieważ testy wykonano nie dość dokładnie. Dobrą praktyką jest przetestowanie poprawki przed udostępnieniem jej na produkcji. Pozwala to zminimalizować ryzyko, że owa poprawka nie zadziała lub wywoła błędy regresji. Ewentualne awarie wywołane zmianą w kodzie mogą być znalezione i naprawione przed wydaniem klientowi nowej wersji systemu. Testowanie zbyt często rozumiane jest jako sprawdzenie, czy produkt informatyczny działa tak, jak powinien działać, a nie czy nie robi czegoś, czego w żadnym wypadku nie powinien. Zbyt często zdarza się podejście polegające na wykonywaniu jedynie testów pozytywnych czyli sprawdzania, czy aplikacja daje oczekiwane wyniki w przypadku wykonywania oczekiwanych i przewidzianych czynności. Tester może wychodzić z założenia, że skoro aplikację zaprojektowano do realizowania pewnych ściśle określonych zadań, należy sprawdzić tylko ścieżki realizujące owe zadania i nic ponadto ponieważ użytkownik będzie używał systemu zgodnie z przeznaczeniem. Tymczasem bardzo często jakakolwiek próba wykonania czynności nieprzewidzianej w specyfikacji wymagań kończy się błędem oprogramowania. Typowe zaniedbania to brak testów dla: niepoprawnych danych wejściowych (brak wymaganych informacji, niewłaściwy format danych np. wartość string w polu numerycznym, zakres danych, dane niepoprawne z punktu widzenia biznesowego, np. podanie kwoty operacji większej niż dostępny limit itp.); przerwań standardowego przebiegu procesu (np. wywołanie awarii w trakcie wykonywania operacji, anulowanie transakcji); operacji na bazie danych np. sprawdzenie, czy zmiana dokonana w jednym rekordzie ma wpływ na inne rekordy; czy dodanie rekordu nie usuwa przypadkiem innego itp.; podobnych lub wzajemnie zależnych operacji wykonywanych równolegle przez operatorów systemu, np. jednoczesne edytowanie tych samych danych przez różne osoby; prób używania urządzeń niekompatybilnych z systemem (np. innych modeli drukarek niż zalecane) lub wywoływania sztucznych awarii podczas używania urządzeń. Innego rodzaju problemem jest brak planu testów podziału testów na mniej i bardziej ważne, ustalenia porządku i priorytetów zadań. Zdarza się, iż testerzy sprawdzają funk- 6

7 cjonalności po kolei, bez uwzględnienia krytyczności i ważności poszczególnych funkcji. Wyniki takich praktyk to: brak informacji o rzeczywistej kondycji aplikacji które pozwalają ocenić wyniki testów ścieżek krytycznych; wysokie prawdopodobieństwo niedotrzymania terminów i powstawania opóźnień ponieważ taka metoda prowadzenia testów nie pozwala znaleźć błędów w krytycznych funkcjach czy procesach aplikacji na względnie wczesnym etapie. Dokumentacja, czy to specyfikacja funkcjonalna, model danych, dokumentacja przypadków użycia, czy przepływ procesu, jest produktem procesu wytwarzania oprogramowania i w związku z tym powinna podlegać testowaniu (czy też przeglądowi) na podobnych zasadach, jak produkowany system informatyczny. Analitycy biznesowi również popełniają pomyłki, skutkiem czego pisana przez nich dokumentacja może zawierać błędy i luki. Testerzy często zakładają, iż specyfikacja jest jedyną wyrocznią i podstawą procesu testowania i jej zawartość nie podlega dyskusji. Ewentualne niejasności i luki w opisie są pomijane, a testy przeprowadzane według własnego uznania i rozumienia testera. Dobry proces testowy zakłada przegląd i poprawę dokumentacji projektowej. Produkty każdej iteracji analizy biznesowej powinny być poddane kontroli zarówno poprzez samych analityków, jak i zespół QA. Wyniki przeglądu przekazane analitykom często umożliwiają wykrycie i szybką poprawę błędów, które w przeciwnym wypadku mogą skutkować implementacją funkcji niepoprawnych z biznesowego punktu widzenia. Często powtarzaną i prawdziwą opinią jest, iż błąd w wymaganiach (które są reprezentowane przez dokumentację) kosztuje więcej w miarę postępu projektu. Naturalne jest więc stwierdzenie, że im szybciej odkryje się i naprawi takie błędy, tym lepiej i taniej. Przeszkodą we wdrożeniu takiego podejścia jest często nastawienie samych analityków i testerów, którzy zgodnie uważają, że analityk zna wymagania najlepiej (co z reguły jest prawdą) i nigdy się nie myli. Również Project Managerowie wolą wierzyć w zapewnienia analityków o wysokiej jakości dokumentacji, niż w krytyczne uwagi zespołu QA. Nierzadko potrzeba wielu wysiłków, by udowodnić swoje racje i przekonać resztę zespołu projektowego, że tester też może rozumieć wymagania klienta i wspomóc udoskonalanie projektu systemu swoimi uwagami. W projekcie dla instytucji bankowej, w którym pracowałam jako QA team leader, mój zespół doświadczył problemu braku zaufania do naszej wiedzy analitycznej i wyczucia. Przez stosunkowo długi czas wszelkie nasze krytyczne uwagi i prośby o uszczegółowienie czy poprawienie specyfikacji były zbywane stwierdzeniem, iż dokumentacja już została sprawdzona, zaakceptowana i klient nie wnosił żadnych uwag. Nie przyjmowaliśmy takiego wyjaśnienia do wiadomości i praktycznie codziennie atakowaliśmy zespół analityczny dziesiątkami maili z pytaniami i uwagami. Sytuacja odwróciła się po tym, jak zgłosiliśmy błąd dotyczący braku możliwości korzystania z klawiatury numerycznej system nie pozwalał wpisać żadnej cyfry. Programiści odrzucili nasze zgłoszenie, ponieważ w specyfikacji nie było wymagania, aby umożliwiać korzystanie z klawiatury numerycznej. Zgłoszenie to spowodowało istną burzę, ponieważ w ślad za naszym zespołem QA taką samą uwagę z priorytetem krytyczny wniósł klient. Dopiero po tym okazało się, jak wiele uwag i wniosków komunikowanych analitykom przez testerów w początkowych cyklach testowania wewnętrznego jest później zgłaszane przez zespół klienta i zaczęto traktować QA poważnie. Dzięki naszej determinacji, by przekonać resztę zespołu o naszych racjach, udało się wyeliminować wiele potencjalnych problemów i udoskonalić jakość dokumentacji. Korzyści z tego odnieśli również programiści, ponieważ mogli tworzyć kod opierając się o dokładniejszą, bardziej spójną i przejrzystą dokumentację. Audyt dokumentacji nie jest więc zachcianką testerów przynosi wymierne korzyści także pozostałym członkom zespołu projektowego. Nieprawidłowości w zarządzaniu błędami głównie dotyczą: braku zainteresowania zgłoszonym problemem; nieznajomości podstawowego cyklu życia defektu. Pierwszy problem najkrócej obrazuje stwierdzenie: Znalazłem buga, zgłosiłem i reszta mnie nie interesuje. Czekam na poprawkę. To dość często występujące podejście do zarządzania błędami. Tester uważa, że wykonuje swoją pracę realizując zaplanowane scenariusze testowe i raportując ich wyniki. Z analizą odpowiedzi na zgłoszenia czeka do następnego cyklu testów. Tymczasem w bardzo wielu przypadkach otrzymujący błąd do naprawy programista: nie potrafi odtworzyć problemu; nie wie, na czym polega błąd; nie wie, jak go naprawić. Wtedy zdarza się, że odrzuca zgłoszenie z prośbą o dodatkowe informacje lub pomoc. Jeśli tester nie przegląda swoich błędów, nie zauważy tego i nie udzieli informacji niezbędnych do zaplanowania i wdrożenia poprawki. Zorientuje się w kolejnym cyklu te- 7

8 stowym, uzupełni informacje i będzie czekał do następnego cyklu, aby sprawdzić, czy rozwiązanie problemu go satysfakcjonuje. I straci na tym czas ponieważ zamiast zareagować szybko, pomóc programiście i w zamian dostać poprawiony kod w najbliższej nowej wersji systemu, dostanie poprawkę w drugiej wersji aplikacji. Problem numer 2, czyli nieznajomość podstawowego cyklu życia błędu, również powoduje wiele problemów, a nawet chaos w projekcie. Sposób obsługi błędu musi być zgodny z pewnymi ustalonymi regułami, aby zarządzanie defektami było efektywne i spełniało swoją rolę. W przeciwnym wypadku co najmniej utrudnia pracę programistom i pozostałym testerom (ponieważ prowadzi do wyciągania mylnych wniosków), a w najgorszym wypadku do chaosu organizacyjnego, a nawet konieczności powtarzania całego cyklu testów. Ogólny cykl życia błędu przedstawia rysunek 2. Czasami testerzy ustalają własny porządek pracy i obsługują błędy niezgodnie z ustalonymi regułami: testowanie poprawek w nieodpowiedniej wersji systemu nie zwracają uwagi na to, jaki numer wersji aplikacji ustawił programista naprawiając problem, i w której wersji poprawka jest dostępna; ponowne otwieranie błędów bez określenia przyczyny bez opisu, co działa nieprawidłowo, co jeszcze należy poprawić; ponowne otwieranie zgłoszenia w sytuacji, gdzie błąd dotyczy czego innego np. problem opisany w zgłoszeniu błędu został naprawiony, lecz pojawił się nowy, w innej części funkcjonalności. Takie problemy powinny być raportowane jako osobne zgłoszenia w innym przypadku może dojść do sytuacji, kiedy poprawianie i otwieranie tego samego defektu będzie się ciągnąć w nieskończoność bo każda poprawka spowoduje inny problem, w innych modułach, o innym priorytecie. Śledzenie historii takiego błędu nie będzie miało najmniejszego sensu; zapominanie o weryfikacji poprawek w odpowiedniej wersji aplikacji lub odkładanie sprawdzenia na później, z racji innych, pilniejszych zadań. Skutek programiści i sami testerzy nie wiedzą, czy błędy zostały poprawione, czy zmiany w kodzie nie spowodowały innych problemów itp. Testowanie poprawek powinno być zawsze pierwszą czynnością po wykonaniu testów dymnych. zgłaszanie duplikatów raportowanie problemu bez upewnienia się, czy ktoś inny nie zgłosił już podobnego, lub otwieranie zgłoszenia tego samego problemu w trakcie testów kolejnej wersji aplikacji tj.bez uzyskania poprawki do błędu już zgłoszonego. Wrogość pomiędzy testerami a programistami występuje dość często jest przejawem pewnej rywalizacji oraz faktu, iż nikt nie lubi przyznawać się do pomyłki a zgłaszanie błędów jest nieraz traktowane przez programistę jako atak na jego umiejętności. Zdarza się też, że komunikacja pomiędzy zespołami ogranicza się do wymiany informacji w systemie śledzenia błędów, a obie strony nie są zainteresowane nawiązaniem bardziej bezpośredniego kontaktu. Tymczasem utrzymywanie dobrych relacji może obu stronom przynieść korzyści: lepsza komunikacja zwiększa szanse na szybkie rozwiązywanie problemów i naprawianie błędów zamiast kontaktować się jedynie poprzez zmiany statusu zgłoszenia w systemie śledzenia błędów, obie strony mogą na bieżąco wyjaśniać wątpliwości i uzgadniać pożądane rozwiązanie; programista inaczej podchodzi do problemu, jeśli ma świadomość, że tester nie obwinia go o wadliwą implementację i nie czyni personalnych uwag co do jakości kodu traktuje zgłoszenie jako zwykłe zadanie do wykonania, a nie poddawanie w wątpliwość jego kwalifikacji; możliwość przetestowania poprawki przed jej wdrożeniem w środowisko testowe dobre relacje z programistami często pozwalają na wgląd w poprawiony kod jeszcze przed tym, jak programista zatwierdzi zmiany do SVNa. Tym sposobem tester może sprawdzić rozwiązanie problemu przed oficjalnym wdrożeniem zmiany i upewnić się, czy działa tak, jak powinien. Co równie istotne, może również sprawdzić, czy poprawka nie spowodowała innych błędów; programista może pomóc testerowi w jego pracy zwracając uwagę na potrzebę dokładniejszego przetestowania pewnych obszarów czy scenariuszy, o ile ma podejrzenia co do jakości aplikacji we wskazanych miejscach. Wiele razy doświadczałam sytuacji, w których programiści prosili o sprawdzenie kilku funkcji, które rzeczywiście okazywały się wadliwe. Obie strony miały z tego korzyści tester, ponieważ znalazł błędy, które w przeciwnym wypadku odkryłby zespół klienta; programista ponieważ po naprawieniu usterek i ich weryfikacji mógł mieć pewność co do jakości systemu. Pracując w zespole, jakim jest personel projektu, należy pamiętać o jednym działamy zespołowo mając na względzie wspólny cel i jednym z naszych zadań jest wspieranie pozostałych członków grupy - czy to innych testerów, czy programistów lub analityków. Nie jest możliwe prowadzenie projektu informatycznego w pojedynkę, ani też prowadzenie projektu w sytuacji, gdy część zespołu walczy z drugą grupą. Testowanie nie jest czynnością tak prostą, jak się na pierwszy rzut oka może wydawać. Jednym z głównych celów prac QA jest wynajdywanie błędów i nieprawidłowości, dążenie do doskonalenia systemu informatycznego oraz dokumentacji analitycznej. Jakość testowania obniża się jednak znacząco w przypadku, gdy sam proces realizowany jest w niewłaściwy sposób lub przez osoby o niewystarczających kwalifikacjach i predyspozycjach. Niniejszy artykuł przybliżył klika podstawowych pomyłek, występujących w planowaniu oraz realizacji testowania. Analiza owych nieprawidłowości oraz zapoznanie się z przytoczonymi wskazówkami może pomóc wyeliminować pewne podstawowe błędy zarządzania i organizacji pracy oraz uczynić proces testowy bardziej efektywnym. 8