Dlaczego Twoi testerzy tracą 2 godziny dziennie na pisanie raportów

Jako właściciel software house'u pewnie nie zastanawiasz się nad tym, ile czasu Twoi testerzy spędzają na pisaniu zamiast na testowaniu.

A powinieneś. Bo to jest Twoje wąskie gardło.

Anatomia jednego bug reportu

Tester znajduje błąd. Co robi dalej?

Suma: 10-15 minut. Na jeden bug.

Jak to wygląda w praktyce

Wyobraź sobie: tester Marek testuje formularz rejestracji w aplikacji klienta. Klika "Zarejestruj się", wpisuje dane, formularz zwraca błąd 500. Bug znaleziony.

Teraz zaczyna się raportowanie. Marek otwiera nową kartę. Wchodzi do Jiry. Szuka właściwego projektu na liście (ma dostęp do pięciu). Klika "Utwórz zgłoszenie". Wybiera typ: Bug. Wybiera priorytet: Medium. Pisze tytuł: "Błąd 500 przy rejestracji nowego użytkownika". Przechodzi do opisu.

W opisie musi napisać: co się stało, czego oczekiwał, jakie dane wpisał. Potem kroki reprodukcji — numerowane, krok po kroku: 1. Otwórz stronę /register. 2. Wpisz email test@example.com. 3. Wpisz hasło... i tak dalej. Potem wracana do przeglądarki, robi screenshota, przycina go, wrzuca do Jiry. Dopisuje przeglądarkę: Chrome 121, system: macOS 14.3, rozdzielczość: 1440x900. Sprawdza czy URL jest poprawny. Klika "Zapisz".

12 minut później Marek ma gotowy ticket. Ale teraz musi wrócić do testowania formularza. Gdzie skończył? Jaki scenariusz testował? Jakie dane miał w polach? Musi sobie to wszystko przypomnieć. Kolejne kilka minut zanim wróci do flow.

I tak 8 razy dziennie. Codziennie. Przez cały sprint.

Ile to kosztuje Twój software house?

Policzmy na konkretnych liczbach. Przyjmijmy konserwatywne założenia: 4 testerów, 8 bugów dziennie na testera, 12 minut na raport.

128 godzin miesięcznie. To odpowiednik 0.8 pełnego etatu poświęconego wyłącznie na pisanie raportów. Nie na testowanie, nie na szukanie bugów — na administrację. Przy 100 PLN/h kosztu pracodawcy, to prawie 13 tysięcy złotych miesięcznie.

A to jeszcze nie uwzględnia czasu, który programiści tracą na dopytywanie o niekompletne raporty. Ani bugów, które testerzy odpuścili, bo "nie opłacało się ich opisywać".

Ukryty koszt: Context switching

Ale to nie wszystko. Każde przerwanie testowania to context switch. Według badań Glorii Mark z University of California, Irvine, opisanych w książce "Attention Span" (2023), powrót do pełnej koncentracji po przerwie zajmuje średnio ponad 23 minuty.

Więc Twój tester nie traci 10 minut na raport. Traci 10 minut + czas na powrót do flow.

Przy 10 bugach dziennie — to 2+ godziny straconego czasu. Codziennie. Na jednego testera.

Co słyszysz od testerów?

Brzmi znajomo?

Rozwiązanie: Mów zamiast pisać

Co jeśli tester mógłby powiedzieć co się stało — tak jak opowiada koledze przy kawie — i dostać gotowy, sformatowany ticket w Jirze? Dokładnie tak działa raportowanie głosowe, które skraca cały proces do poniżej minuty.

• Klik na wtyczkę
• Mówi co się stało
• Robi screena
• Klika "wyślij"

Poniżej minuty. Nie 10-15 minut. AI zamienia nagranie w strukturyzowany raport z tytułem, krokami reprodukcji i danymi technicznymi.