Stanowisko
Tester i QA
Co odkładacie pierwsze, kiedy wydanie zbliża się szybciej niż testy? Zwykle regresję - i zwykle to właśnie tam siedzi błąd, który wróci w zgłoszeniu od użytkownika.
Rozmowa wstępna
Cztery pytania, od których byśmy zaczęli
Co odkładacie pierwsze przy napiętym terminie wydania?
Odpowiedź opisuje, gdzie w Waszym procesie powstaje dług jakościowy.
Skąd wiecie, że obszar zmieniony w tym wydaniu jest przetestowany?
Jeśli z tego, że tester tak sądzi, to pokrycie jest przekonaniem, a nie faktem.
Ile razy ten sam błąd wraca po poprawce?
Jeśli zdarza się to regularnie, to brakuje testu, który by go zatrzymał - a nie uwagi programisty.
Czego nie robicie, choć wiecie, że trzeba?
Zwykle: nie testujecie przypadków brzegowych i scenariuszy rzadkich. Zawsze z braku czasu, nigdy z braku świadomości.
Zdejmujemy przygotowanie i powtarzanie, zostawiamy projektowanie testów
Przygotowanie danych testowych, wykonywanie regresji, raportowanie wyników i utrzymanie dokumentacji testów dają się odciążyć. To, co i dlaczego ma być przetestowane, projektuje tester.
- Regresja nie konkuruje z nowymi testami. - Jeśli powtarzalne scenariusze wykonują się same, czas testera idzie na to, czego nikt wcześniej nie sprawdzał.
- Dane testowe nie blokują startu. - Przygotowanie zestawu danych do scenariusza przestaje być półdniowym zadaniem przed każdą turą testów.
- Pokrycie jest faktem, nie wrażeniem. - Widać, które obszary zmienione w wydaniu mają testy, a które nie - i to jest podstawa decyzji o wydaniu.
Zakres
Co da się odciążyć w pracy testera
Dziewiętnaście przykładowych zadań. Każde ma punkt zatwierdzenia po stronie człowieka. Poniżej wybrane, a zakres dopasowujemy do Waszego procesu wytwórczego.
Projektowanie testów
- Szkic przypadków testowych na podstawie wymagania (ocena: tester)
- Wskazanie przypadków brzegowych do rozważenia
- Powiązanie przypadku z wymaganiem i obszarem systemu
- Sygnał o wymaganiu bez przypisanego testu
Dane testowe
- Generowanie zestawów danych pod scenariusz
- Dane o różnych wariantach stanu i konfiguracji
- Odtworzenie stanu środowiska przed turą testów
- Anonimizacja danych pochodzących z produkcji
Wykonanie i raportowanie
- Wykonanie scenariuszy powtarzalnych bez udziału testera
- Zapis wyniku z krokami odtworzenia
- Projekt zgłoszenia błędu z kontekstem (treść: tester)
- Zestawienie wyników tury testowej
Testy regresji
- Wskazanie obszarów objętych zmianą w wydaniu
- Zestaw regresji dobrany do zakresu zmiany (decyzja: tester)
- Sygnał o obszarze zmienionym i nieobjętym testem
- Porównanie wyniku z poprzednią turą
Jakość po wydaniu
- Powiązanie zgłoszeń użytkowników z obszarami systemu
- Wskazanie błędów, które powinien był wykryć istniejący test
- Zestawienie błędów wedle obszaru i przyczyny
Dzień pracy
Dzisiaj
- Dane testowe przygotowujecie ręcznie przed każdą turą
- Regresję wykonujecie klikając przez te same scenariusze
- Przy napiętym terminie testujecie to, co zdążycie
- Nie wiecie, czy obszar zmieniony w wydaniu ma w ogóle testy
- Zgłoszenie błędu opisujecie od zera, razem z krokami
- Po wydaniu nie wiecie, który błąd dało się wyłapać wcześniej
Z asystą AI
- Zestaw danych pod scenariusz powstaje bez półdniowego przygotowania
- Scenariusze powtarzalne wykonują się same
- Czas idzie na przypadki, których wcześniej nikt nie sprawdzał
- Obszar zmieniony i nieobjęty testem jest wskazany
- Zgłoszenie błędu ma projekt z krokami odtworzenia
- Błędy po wydaniu są powiązane z lukami w testach
- Pokrycie testami
widać, co jest sprawdzone, a co tylko wygląda na sprawdzone
przypadki są powiązane z wymaganiami i obszarami
- Czas regresji
regresja mieści się przed wydaniem, a nie po nim
scenariusze powtarzalne wykonują się same
- Błędy wykryte po wydaniu
mniej spraw trafiających do użytkowników
czas testera idzie na przypadki nowe
- Powtarzalność testów
ten sam test daje ten sam wynik niezależnie od osoby
dane i stan środowiska są odtwarzalne
Zaczynamy od danych testowych, bo to one najczęściej opóźniają start testów.
- Krok 1
Dane i odtwarzalne środowisko
Zestawy danych pod scenariusze i powtarzalny stan startowy.
- Krok 2
Scenariusze powtarzalne
Wykonywanie regresji bez udziału testera przy każdym przejściu.
- Krok 3
Pokrycie wobec zmian
Wskazanie obszarów zmienionych i nieobjętych testem.
- Krok 4
Jakość po wydaniu
Powiązanie zgłoszeń z obszarami i lukami w testach. Na końcu, bo wymaga danych z produkcji.
Częste pytania
Pytania, które padają na pierwszym spotkaniu
Czy to nie obniży roli testera w zespole?
Zwykle jest odwrotnie, bo tester przestaje być osobą klikającą przez regresję, a staje się osobą projektującą, co w ogóle warto sprawdzić. To jest trudniejsza część tej pracy i bardziej widoczna dla zespołu.
Czy testerzy będą jeszcze potrzebni?
Testy generowane nie znajdują tego, co ważne - i piszemy o tym otwarcie kilka akapitów niżej. Tester jest potrzebny do zaprojektowania, co w ogóle warto sprawdzić, a to jest trudniejsza część tej pracy niż klikanie przez regresję. Kiedy regresja wykonuje się sama, zostaje na nią czas. Zespoły, które przez to przechodzą, zwykle kończą z mocniejszym QA, nie mniejszym.
Czy to podlega AI Act?
Testowanie oprogramowania nie jest zastosowaniem wysokiego ryzyka. Uwagi wymaga tylko używanie danych produkcyjnych jako testowych - tam obowiązują zasady ochrony danych i anonimizacja jest elementem zakresu, a nie dodatkiem.
Zostało pytanie, którego tu nie ma? Umów rozmowę
Następny krok
Ile czasu przed ostatnim wydaniem poszło na przygotowanie danych testowych?
Pokażemy Wam, jak wygląda testowanie, w którym regresja nie konkuruje z nowymi przypadkami, a pokrycie jest widoczne przed decyzją o wydaniu.