W zespole testowym najwięcej zamieszania nie robi sam błąd, tylko decyzja, co z nim zrobić teraz, a co może poczekać. To właśnie tutaj pojawia się różnica między severity vs priority: jedno opisuje techniczny wpływ defektu, drugie biznesową pilność naprawy. Jeśli te dwa pojęcia się mieszają, backlog szybko traci sensowną kolejność, a release zaczyna przypominać gaszenie pożaru bez planu.
Najkrócej: jedno mówi o skutku, drugie o kolejności działania
- Severity odpowiada na pytanie, jak mocno błąd psuje produkt technicznie i dla użytkownika.
- Priority mówi, jak szybko zespół powinien się nim zająć w kontekście biznesu, ryzyka i terminu wydania.
- Ten sam defekt może mieć wysoką severity i niską priority albo odwrotnie.
- W triage najlepiej patrzeć na wpływ, zasięg, obejście problemu i konsekwencje dla wydania.
- Najwięcej błędów bierze się z tego, że zespół używa priority jako zamiennika severity.
Co naprawdę opisuje severity, a co priority
Severity to ocena technicznego wpływu defektu na system, funkcję albo doświadczenie użytkownika. Pytanie brzmi: jak bardzo ten błąd psuje produkt? Jeśli aplikacja nie pozwala się zalogować, gubi dane albo blokuje płatność, severity jest wysoka niezależnie od tego, kto zauważył problem i kiedy.
Priority działa inaczej. Odpowiada na pytanie: jak szybko trzeba to naprawić? Tutaj liczy się nie tylko sama wada, ale też kontekst biznesowy, termin wydania, liczba użytkowników, ryzyko prawne, kampania marketingowa czy obietnica złożona klientowi. W praktyce to właśnie priority porządkuje kolejność pracy zespołu.
Ja zwykle rozbijam rozmowę na dwa osobne pytania: „co ten defekt robi z produktem?” i „co zrobi z naszym planem, jeśli zostanie otwarty jeszcze dziś?”. Dzięki temu łatwiej odróżnić problem technicznie ciężki od problemu pilnego. Gdy te definicje są już jasne, warto zobaczyć, jak przekładają się na konkretne sytuacje.
Jak rozpoznać różnicę w praktyce
Najprościej widać to w zestawieniu kilku kryteriów. W dobrym procesie testowym severity i priority nie są jednym polem z inną nazwą, tylko dwoma różnymi wymiarami decyzji.
| Kryterium | Severity | Priority |
|---|---|---|
| Na czym się skupia | Na technicznym wpływie błędu na produkt | Na pilności naprawy i kolejności działania |
| Główne pytanie | Jak duże szkody powoduje defekt? | Jak szybko trzeba go usunąć? |
| Typowa perspektywa | QA, developer, czasem architekt lub security | Product owner, release manager, support, biznes |
| Co może ją zmieniać | Zakres błędu, utrata danych, blokada kluczowej funkcji | Termin wydania, liczba klientów, SLA, ryzyko reputacyjne |
| Najczęstszy błąd | Utożsamianie z presją biznesową | Mylenie pilności z techniczną „ciężkością” błędu |
W tym miejscu łatwo o pomyłkę: wysoka severity nie oznacza automatycznie najwyższej priority. Jeśli błąd jest poważny, ale występuje tylko w rzadkim scenariuszu i ma sensowny workaround, zespół może odłożyć go na później. Z kolei drobny wizualny problem może dostać wysoki priorytet, jeśli psuje kluczową stronę kampanii lub ekran, na którym właśnie trwa sprzedaż. I właśnie te scenariusze najlepiej pokazują sens całego rozróżnienia.
Cztery typowe kombinacje i co z nich wynika
W praktyce najwięcej porządku daje spojrzenie na cztery najczęstsze układy. To dobry materiał do triage, czyli krótkiego wspólnego ustalania, co blokuje pracę najbardziej i co trzeba rozwiązać w pierwszej kolejności.
| Kombinacja | Przykład | Co to oznacza w decyzji zespołu |
|---|---|---|
| Wysoka severity i wysoka priority | Płatność wywala się po kliknięciu „kup teraz”, a błąd dotyczy głównego procesu sprzedaży | Naprawa powinna wejść natychmiast, bo problem uderza i w produkt, i w biznes |
| Wysoka severity i niska priority | Awaria pojawia się tylko w mało używanym starym środowisku lub w rzadkim, technicznym scenariuszu | Błąd jest poważny, ale może poczekać, jeśli nie blokuje większości użytkowników ani wydania |
| Niska severity i wysoka priority | Źle wyrównany przycisk na stronie kampanii albo literówka w kluczowym komunikacie przed premierą | Technicznie problem jest mały, ale biznesowo trzeba go poprawić szybko, bo wpływa na odbiór produktu |
| Niska severity i niska priority | Drobna niespójność stylu w mniej używanym panelu administracyjnym | To dobry kandydat do niższego backlogu lub poprawki przy okazji innych zmian |
Takie przykłady są ważne, bo zdejmują emocje z rozmowy. Zamiast spierać się o to, czy „to jest krytyczne”, zespół zaczyna pytać, ilu użytkowników ucierpi, czy da się obejść problem i czy błąd naprawdę blokuje cel biznesowy. To prowadzi naturalnie do pytania, kto powinien te oceny nadawać i kiedy wolno je zmienić.
Kto powinien ustalać ocenę i kiedy ją zmieniać
W dojrzałym zespole severity zwykle zaczyna się od strony testowej lub technicznej, a priority jest ustalana wspólnie z osobami odpowiedzialnymi za produkt, wydanie i wsparcie klienta. To nie jest przypadek. QA widzi, jak błąd działa w systemie. Biznes widzi, co ten błąd zrobi z planem, klientem i przychodem.
Najlepszy model pracy wygląda zwykle tak:
- Tester opisuje defekt możliwie konkretnie, z krokami odtworzenia, zakresem i dowodami.
- Zespół ocenia severity na podstawie wpływu technicznego, ryzyka utraty danych, blokady funkcji i zakresu problemu.
- Podczas triage ustalana jest priority, czyli miejsce defektu w kolejce napraw.
- Product owner, release manager lub lider techniczny decyduje, czy błąd trafia do bieżącego wydania, czy do późniejszego sprintu.
- Priorytet jest przeglądany ponownie, jeśli zmienia się kontekst, na przykład pojawia się obejście, rośnie liczba zgłoszeń albo przyspiesza termin publikacji.
To ważne: priority nie jest wyrokiem na zawsze. Jej sens polega właśnie na tym, że może się zmienić razem z biznesem. Severity zwykle jest stabilniejsza, bo opisuje sam defekt, a nie otoczenie wokół niego. Jeśli ten porządek jest jasny, łatwiej uniknąć kilku bardzo kosztownych pomyłek.
Najczęstsze błędy w triage błędów
W zespołach, które dopiero porządkują zarządzanie testami, widzę powtarzalny zestaw błędów. Brzmią niewinnie, ale potrafią rozwalić backlog i wydłużyć naprawy o całe sprinty.
- Mylenie severity z priority i traktowanie każdego krytycznego błędu jako absolutnego „must fix now”.
- Podkręcanie priority pod presją jednego interesariusza, bez spojrzenia na wpływ na całość produktu.
- Brak wspólnych definicji dla poziomów takich jak low, medium, high, przez co każdy rozumie je inaczej.
- Nieaktualizowanie oceny po pojawieniu się workaroundu, zmianie terminu lub nowych danych o skali problemu.
- Używanie priority jako skrótu do emocji, a nie do realnej kolejności napraw.
Najbardziej szkodzi brak spójności. Jeśli jeden tester uważa „high” za błąd blokujący logowanie, a drugi za każdy błąd widoczny na produkcji, zespół nie ma jednego języka. Bez tego trudno prowadzić sensowny backlog, raportować stan jakości i bronić decyzji przed biznesem. Dlatego następny krok to wpięcie tego rozróżnienia w codzienny proces testów i wydań.
Jak przenieść tę zasadę do procesu testów i wydań
W praktyce najlepiej działa prosty, powtarzalny schemat. Nie trzeba budować rozbudowanej teorii, jeśli zespół konsekwentnie stosuje kilka reguł przy każdym defekcie.
- Opisuj wpływ, nie tylko objaw. Sam komunikat o błędzie to za mało. Potrzebne są kroki odtworzenia, zakres i informacja, co dokładnie przestaje działać.
- Rozdziel technikę od biznesu. Severity ustalaj na bazie działania produktu, a priority na bazie terminu, ryzyka i wartości dla użytkownika.
- Ustal stałą matrycę decyzyjną. Dwa te same błędy, zgłaszane przez różne osoby, powinny trafiać do podobnych kategorii.
- Przeglądaj priority na triage. To dobry moment, żeby uwzględnić nowe zgłoszenia, zmiany w release planie i ryzyka operacyjne.
- Łącz defekty z decyzjami wydaniowymi. Jeśli błąd jest wysoki, ale naprawa wymaga dużej przebudowy, trzeba świadomie wybrać między poprawką teraz a ryzykiem później.
Ja traktuję to jako prostą zasadę higieny procesu: im szybciej zespół oddzieli „jak bardzo boli” od „jak pilnie to gasić”, tym mniej chaosu w komunikacji. To szczególnie ważne w środowiskach z krótkimi sprintami, ciągłymi wdrożeniami i dużą liczbą zgłoszeń. Zostaje jeszcze jedna rzecz, która porządkuje temat najlepiej, czyli praktyczna reguła do zapamiętania przez cały zespół.
Jedna prosta reguła, która porządkuje decyzje zespołu
Jeśli miałbym zostawić tylko jedną zasadę, brzmiałaby ona tak: severity opisuje wpływ usterki, a priority opisuje kolejność jej naprawy. To nie są synonimy, tylko dwa różne filtry, przez które patrzy się na ten sam defekt. Pierwszy pomaga ocenić skalę szkody, drugi pomaga zdecydować, co robić najpierw.
W dobrze prowadzonym procesie testowym ta różnica nie jest teorią z checklisty, tylko narzędziem do podejmowania lepszych decyzji. Gdy zespół rozumie oba pojęcia, łatwiej mu bronić priorytetów, szybciej zamykać krytyczne błędy i nie tracić energii na spory o nazwy. A to właśnie daje najwięcej porządku w testach: mniej intuicji, więcej wspólnego języka i jasne reguły działania.
