Testing

Problemy testera

Kwiecień 1, 2016 2
Podziel się:

W pracy testera oprogramowania często natrafia się na problemy te zawarte w aplikacjach testowanych, w dokumentacjach ale także organizacyjne, które to w końcowym efekcie mogą odbić się negatywnie na jakości testów, dlatego też warto wiedzieć jakie problemy mogą czyhać na testera i jak sobie z nimi radzić.

Duża ilość błędów w testowanej aplikacji – zgłaszanie znalezionych błędów jest esencją pracy Testera, jednak im więcej aplikacja posiada błędów, tym większa szansa, że aplikacja będzie zawierała pewną ilość błędów niewykrytych podczas testowania. Przyczyna zjawiska może być różna:

  • nieprecyzyjne wymagania – duża szansa, że wymagania zostaną błędnie zinterpretowane przez programistę, co powoduje powstanie defektu. Jeśli podczas testowania, zgłoszonych zostanie bardzo dużo błędów, w tym duża ilość błędów w dokumentacji, należy rozważyć ponowne doprecyzowanie wymagań i powtórzenie implementacji.
  • niedoświadczony zespół developerski – duża ilość błędów może znacząco opóźnić proces testowania, co może mieć znaczący wpływ na założone deadline’y w projekcie. Jeśli duża ilość błędów wynika z prostych omyłek, należy rozważyć wprowadzenie tzw. przeglądów koleżeńskich kodu w zespołach developerskich, co ułatwi wyłapanie podstawowych błędów zanim aplikacja trafi do testowania.
  • złożoność aplikacji – na pewnym poziomie złożoności systemu, duża ilość błędów jest po prostu nieunikniona. Ilości te można niwelować poprzez bardzo szczegółowe recenzje wymagań na wczesnym etapie, silne testy jednostkowe itp.

Błędy wymagające wielokrotnej weryfikacji – wielokrotna weryfikacja tego samego błędu może być bardzo czasochłonna i frustrująca. Złą praktyką jest skupienie się na personalnym wytykaniu przyczyn problemu i nadmierna eskalacja. Dobrym rozwiązaniem jest wymuszenie na zespole developerskim wykonywania testów jednostkowych przed oddaniem poprawki do sprawdzenia.


Błędy znalezione na Produkcji – poważne błędy, które umknęły testerom i zostały zaimplementowane na docelowym środowisku biznesowym, mogą poważnie zaufanie do pracy Zespołu Testowego. Każdy błąd produkcyjny powinien być gruntownie przeanalizowany pod kątem przyczyn powstania (czynnik ludzki, braki w pokryciu skryptów testowych itp.) celem zminimalizowania ich wystąpienia w przyszłości. Dodatkowo można zastosować wskaźniki KPI, które obiektywnie pokażą jakość testowania np. stosunek ilości błędów znalezionych podczas SAT do ilości błędów UAT lub produkcyjnych.


Błędy znalezione w ostatniej chwili – błąd znaleziony w końcowej fazie testowania np. tuż przed planowanym wdrożeniem na środowisko produkcyjne może wywołać nieprzyjemny stres u Testera. Należy zachować tutaj zawodową obiektywność i niezależność testerską i nie bać się zgłosić błędu. Najgorszą z możliwych rzeczy jest w tym wypadku próba zamiecenia problemu pod dywan. Wdrożenie błędu na Produkcji może mieć katastrofalne skutki. Należy zgłosić błąd jak najszybciej i wnioskować o szybkie zwołanie tzw. Defect Meetingu, podczas którego dojdzie do oszacowania ryzyka oraz podjęcia decyzji co do dalszego postępowania.


Presja czasu – bardzo często wszelkie opóźnienia projektowe odbywają się kosztem testów. Mało roztropny Project Manager będzie próbował wdrożyć produkt na czas dzięki skróceniu procesu testowania. Nigdy nie należy godzić się pochopnie na próby nacisku i skrócenie testów. W tego typu przypadkach należy ponownie oszacować czasochłonność testów i jeśli Zespół Testowy uzna skrócenie za niemożliwe (np. brak możliwości wzięcia nadgodzin), należy podjąć próbę zmiany zakresu testów w oparciu o analizę ryzyka (obcięcie testów dla mniej ryzykownych obszarów). Każda tego typu decyzja powinna być jasno i bez niedomówień przekazana do Project Managera.


Często zmieniana Specyfikacja Funkcjonalna – brak zdecydowania Biznesu w kwestii wymagań może być bardzo uciążliwe dla Zespołu Testowego. Zmiany w wymaganiach funkcjonalnych powodują konieczność powtórnej analizy napisanych skryptów i czasochłonnego ich poprawiania. Przy częstych zmianach wymagań warte rozważenia jest przejście na tryb iteracyjno-przyrostowy przy wytwarzaniu aplikacji, co zniweluje negatywny wpływ zmian i zwiększy elastyczność całego zespołu.


Duża rotacja członków Zespołu Testowego – przyczyną zaistnienia problemu może być zła atmosfera w zespole, zamrożenie podwyżek, wyczerpująca praca, pojawienie się atrakcyjnych ofert konkurencyjnych itp. Wpływ każdej z tych przyczyn można zminimalizować stosując pewne zabiegi korekcyjne np. wyjścia integracyjne, premie uznaniowe, lepsze planowanie zadań. Oprócz tych czynników, które należy traktować indywidualnie można też wprowadzić pewne czynności, które spowodują, że zespół będzie odporny na tego typu zjawiska np. poprzez stworzenie bazy wiedzy oraz programu wdrożenia nowego pracownika, dzięki czemu nowa osoba bardzo szybko będzie w stanie wdrożyć się do pracy w nowym środowisku.

W artykule zostały przekazane przykładowe problemy jakie mnie i moich znajomych spotykały w pracy testera. A Wy na jakie problemy natrafialiście?

5 / 5
Kategorie: Testing
Michał Markwart
Autor: Michał Markwart
W Sii jestem testerem. Zajmuję się testami aplikacji oraz wszelką dokumentacją z nimi związaną. Szukam rozwiązań które pomogą szybciej, efektywniej i z wyższą jakością wykonywać swoją pracę. Wcześniej pracowałem dla dużej polskiej firmy z branży ubezpieczeniowej, na początku jako tester manualny, z czasem jako Test Leader Produktu.

Imię i nazwisko (wymagane)

Adres email (wymagane)

Temat

Treść wiadomości

komentarze(2)

avatar'
Karol
13 kwietnia 2016 Odpowiedz

Chciałbym zostać testerem i aplikuje na stanowiska z tym związane, myślę że ten post pomoże mi uniknąć pewnych błędów i wybrać odpowiednią pracę.

avatar'
Fabian
15 kwietnia 2016 Odpowiedz

Bardzo interesujący artykuł. Większości wydaje się, że taki tester to ma łatwą i przyjemną robotę. Tymczasem bywa to na prawdę niewdzięczne..

Zostaw komentarz