To pytanie pojawiło się na rozmowie rekrutacyjnej jednego z moich znajomych.

Odpowiedź może się bardzo różnić w zależności od aplikacji i projektu.

Z 7 zasad testowania wiemy, że przetestowanie wszystkiego nie jest możliwe (nie dajcie się zwieść memom 😀 ), chyba, że mamy do czynienia z bardzo prostym systemem lub funkcjonalnością. W praktyce jednak, zamiast podejmować próbę testowania gruntownego, należy odpowiednio ukierunkować wysiłki związane z testowaniem na zastosowanie analizy ryzyka, technik testowania i priorytetyzacji.

Michael Bolton kilka dni temu napisał na Linkedin, że:

As testers, it’s our job to ask “What could possibly go wrong?” and then to perform experiments to show that it can happen. It’s not really our job to show that “it works on my machine”; any programmer worth her salt has already seen the product working.

To od nas – testerów – zależy – czy wymyślimy na wszystkie możliwe kombinacje problemów, z którymi będzie mierzył się końcowy użytkownik, korzystając z aplikacji.

I to właśnie robimy – myślimy o jakości, staramy się zepsuć jak najwięcej, zanim oprogramowanie wyjdzie z naszej strefy komfortu – środowiska deweloperskiego. Testujemy, próbujemy i tworzymy nowe przypadki testowe lub badamy obszary ryzyka.

Co jednak w sytuacji, gdy oprócz złożonego systemu, tester jest też bardzo ograniczony czasem przeznaczonym na testy, a funkcjonalność, która podlega testom jest krytyczna lub niezwykle istotna z perspektywy całego systemu?

1 – Nie masz Zmieniacza Czasu

Niewielu z nas ma Kamień Czasu niczym Dr. Strange. Niewykluczone, że tylko on go miał. W związku z tym, jeśli słyszysz zdanie “ta funkcjonalność jest krytyczna – macie 3 godziny na testy” – to zazwyczaj znaczy, że masz 3 godziny na testy i tego czasu nie da się rozciągnąć.

Policz ile osób jest w Twoim zespole. Podzielcie się. Zaplanujcie pracę i do dzieła!

Tylko Ty – testerze – znasz swój system i Ty możesz ocenić co w danej sytuacji jest najbardziej krytyczne.

2 – SKUP SIĘ

W codziennej pracy rozprasza nas wiele czynników – maile, sprawy nie związane z projektem, prywatne problemy, smartfon. Jeśli znajdujesz się w sytuacji ograniczonego czasu i wysokiego ryzyka – Twoja uwaga musi być skupiona.

Minuta trwa wieczność, jeśli jesteś skoncentrowany na TERAZ.

3 – Priorytety

Określ priorytety obszarów oprogramowania, które mają największy wpływ na użytkowników. Co będziesz testował i dlaczego akurat TO jest ważne z punktu widzenia Twojej aplikacji?

Co się stanie jeśli tego nie przetestujesz?

Jaki będzie wpływ błędów z tego obszaru na użytkownika?

4 – Zaprojektuj zestaw testów sprawdzających funkcjonalność

Oczywiście nie mam na myśli 3-godzinnego planowania – raczej podział zadań w czasie.

5 – Rejestruj wyniki

Zapisuj co robisz – tak jak w testowaniu eksploracyjnym. Notuj pytania, wątpliwości, błędy i ich krytyczność, możliwe nieścisłości z dokumentacją. Rejestruj defekty w narzędziu, którego używa Twój zespół (Jira, Bugzilla, HPALM etc.).

6 – Ustal priorytety usterek na podstawie ich wagi

W sytuacji, gdy czasu na testowanie i naprawę defektów jest niewiele, bardzo istotne jest określenie które ze znalezionych błędów są krytyczne dla działania aplikacji, a które można rozwiązać później.

Warto zacząć od tzw. low hanging fruits, czyli ważnych defektów, których naprawienie jest stosunkowo łatwe, potem przejść do ważnych, ale bardziej skomplikowanych w naprawie i testowaniu.

7 – Dopilnuj, aby usterki o największej wadze zostały naprawione

Przykład:

W jednym z projektów, w których brałam udział, defekt polegający na niewłaściwym odcieniu koloru zielonego na przycisku “Wyślij”, zgłoszony przez zespół testowy jako Enhancement, przez klienta został uznany za Critical, bo od tego elementu zależała pomyślność całego procesu sprzedaży, przez który użytkownik przechodził na stronie.

Warto więc upewniać się jaki jest rzeczywisty priorytet znalezionych błędów i wtedy zdecydować, które powinny być naprawione jako pierwsze.

I najważniejsze – nie zapominajcie o retestach tego, co zgłosiliście.

8 – Zbierz defekty o niższym priorytecie, aby rozwiązać je później.

Wiele razy spotkałam się z sytuacją, że jeśli manager/PO/PM mówi – “Przetestujcie tę krytyczną funkcjonalność w czasie nie dłuższym niż X “- a jest akurat piątek po południu, albo koniec ważnej fazy developementu – to z tyłu głowy zazwyczaj ma “i nie zgłaszajcie żadnych błędów” LUB w wersji alternatywnej “a zgłoszone błędy naprawimy później”.

Nawet syllabus ISTQB przekonuje nas, że przekonanie iż samo znalezienie i naprawienie dużej liczby defektów zapewni pomyślne wdrożenie systemu – jest błędne. Na przykład bardzo dokładne testowanie wszystkich wyspecyfikowanych wymagań i naprawienie wszystkich znalezionych defektów wciąż może nas nie uchronić od zbudowania systemu trudnego w obsłudze, który nie spełni wymagań i oczekiwań użytkowników lub będzie miał gorsze parametry od konkurencyjnych rozwiązań.

Trzeba zaakceptować fakt (wiem, że to trudne, oddychaj), że nie wszystkie defekty zostaną naprawione.

Ba! Niektóre nawet nie zostaną znalezione. Ważne, żeby się nie poddawać i NIE OBWINIAĆ WZAJEMNIE za niepowodzenia.

Komentarz na koniec

Ja rozumiem takie pojęcia jak “kara kontraktowa”, “dobro projektu”, “premia dla managera za dowiezienie projektu na czas”, ale jestem testerem oprogramowania, zazwyczaj dosyć upartym w swoich poglądach dotyczących jakości produktu, więc często zapadam na wybiórczą głuchotę i zgłaszam defekty, nalegam na ich naprawienie i negocjuję czas, którego nie ma.

Zachęcam Was do dbania o jakość oprogramowania, które przechodzi przez Wasze ręce. Być może to nie Wy będziecie się wstydzić, jeśli błędy pojawią się na produkcji.

Być może to końcowy użytkownik będzie klął nad crashującą się aplikacją.

Czy masz doświadczenie w testowaniu pod presją czasu? Podziel się!