Redakcja
Kuba wreszcie został przeniesiony do nowego zespołu projektowego, który pracował nad aplikacją dla strategicznego angielskiego klienta. Znał prawie połowę deweloperów i jednego testera, testował ich system dla innego klienta na początku zeszłego roku. Napięte terminy go nie przerażały, bo zakładał dobrą współpracę w zespole.
Wersja aplikacji, która została przekazana do testów była już ustabilizowana i nie sypała błędami gdziekolwiek by się jej dotknęło. Kuba wspólnie z resztą testerów podzielił się przypadkami testowymi i zabrał się do pracy. Testowanie aplikacji, którą była gra komputerowa dla niektórych mogło się wydawać czystą przyjemnością – nic tylko grać w pracy. W rzeczywistości była to trudna praca, bo testy obejmowały zarówno regresję, jak i testy nowych feature’ów.
Kuba zaczął od weryfikacji drugiego levelu i metodycznie zaczął testować wątek gry, który rozgrywał się na platformie Alpha Centauri. Wykonując siódmy przypadek testowy wykrył błąd około-przypadkowy, który zaklasyfikował jako ważny. Ponieważ nie obejmował tego żaden przypadek testowy, to jak zawsze w takich sytuacjach Kuba przeszukał dokumenty analityczne, żeby upewnić się, że jest to nieprawidłowe działanie aplikacji. Analiza niestety nie okazała się pomocna, dokument nie opisywał tego zachowania aplikacji.
Kuba zatem jak zawsze zagadał przez firmowy komunikator, żeby wyjaśnić zaistniałą sytuację z deweloperem, który tworzył ten moduł gry. Okazało się, że zachowanie aplikacji było niepoprawne i jeden z deweloperów będzie musiał wprowadzić poprawkę. Kuba potwierdził to jeszcze z analitykiem i dał się wyciągnąć na kawę testerom ze starego projektu.
Po powrocie z kawy Kuba na firmowym komunikatorze znalazł wiadomość od dewelopera: „To była prosta piłka, bug już poprawiony :) Podgrałem na środowisko testowe nową wersję z poprawką, powinno już działać”. Kuba szybko zweryfikował wcześniej wykryty błąd i rzeczywiście teraz działało już poprawnie. Tylko teraz Kuba musiał się zastanowić co zrobić, no bo czy warto do bug trackera zgłaszać błąd, który już został poprawiony?
Brzmi znajomo? Nawet jeśli ta sytuacja jest Wam obca, to warto zmierzyć się od czasu do czasu z taką łamigłówką testową. No bo co powinien zrobić Kuba?
Zgłosić błąd, który nie istnieje już na testowanej wersji? Czy może zamiast na pójść na kawę najpierw powinien zgłosić błąd? Albo może najpierw zgłosić błąd, a dopiero później wyjaśniać go z Zespołem Projektowym? No i co ze środowiskiem testowym? Czy każdy dev może sobie wgrywać co chce?
Jak Wy zachowalibyście się na jego miejscu?
Ten case testowy, jak i wiele innych znajdziecie na naszym szkoleniu Dobry Tester. Oczywiście wraz z wielką paczką wiedzy i trenerami-praktykami, którzy testami zajmują się na co dzień.
Zapraszamy już 1-2 czerwca do Warszawy.
