Powrót do: AI_Testers vol. 1 – Bonusy (aktywnie rozwijane)

W tym odcinku…

Najgorsze zgłoszenie błędu? “Nie działa”.
Główny problem: ściana czerwonego tekstu. Gdy w aplikacji coś nie działa (np. klikasz “Zapisz” i nic się nie dzieje), zgłoszenie programiście samego „przycisk nie działa” to za mało — programista najpewniej odpowie „u mnie działa”. Aby znaleźć prawdziwą przyczynę, tester musi zajrzeć pod maskę przeglądarki.

Najlepsze zgłoszenie to takie, które mówi programiście dokładnie, w którym miejscu frontend wysłał złe dane do backendu. W tym odcinku łączymy Diagnostykę z Raportowaniem. Pokażę Ci proces, dzięki któremu w 2 minuty zamienisz “cichy błąd” w profesjonalny bilet w Jirze.

Dlaczego tłumaczymy błędy z AI?
Logi z konsoli i sieci często wyglądają jak czarna magia (niezrozumiały kod). Wklejenie ich do AI z prośbą o przetłumaczenie na “ludzki język” pozwala nam dowiedzieć się, czy zepsuty jest Frontend (strona wizualna) czy Backend (logika serwera). Dzięki temu nie tworzysz już lakonicznego zgłoszenia “coś nie działa”, ale profesjonalny Bug Report z konkretną diagnozą.

📚 Pojęcia, które warto znać:

  • Zakładka Network (Sieć) i Payload:
    Ukryte w przeglądarce miejsce, gdzie widać, jak strona rozmawia z serwerem. Payload to dosłownie “ładunek”, czyli paczka danych (np. zawartość formularza), która jest wysyłana na serwer.
  • Lighthouse:
    Darmowe narzędzie wbudowane w przeglądarkę Chrome. Służy do przeprowadzania audytów strony (np. czy jest przyjazna dla osób z niepełnosprawnościami, czy szybko się ładuje).

🚀 Twoja nowa super-moc:

  • 🕵️‍♂️ Śledztwo w Network Tab:
    Zamiast zgadywać, kopiujemy Request i Response do AI. Dowiadujemy się, czy winny jest Frontend (złe dane) czy Backend (awaria serwera).
  • 📝 Generator Bug Reportów:
    Jednym promptem zamieniamy techniczną diagnozę w gotowy szablon zgłoszenia: [Tytuł] [Kroki] [Logi dla Deva].
  • ⚖️ Tłumacz Biznesowy:
    Jak wytłumaczyć managerowi błędy techniczne (CORS, API), używając argumentów o ryzyku biznesowym.

Prompty z odcinka

  1. Diagnoza
    🔗 https://rickandmortyapi.com/graphql
    [kod z Network] 
    Rola: Senior Backend Developer.
Zadanie: Przeanalizuj ten Request (Payload) i Response z zakładki Network.
Format: Czy to wina Frontendu (błędne dane), czy Backendu (awaria)? Wyjaśnij mi to prostym językiem.
  2. Raport

    



Rola: Lead QA Engineer.
Zadanie: Na podstawie powyższej diagnozy napisz profesjonalne zgłoszenie błędu (Bug Report).
Format:
Tytuł: (Krótki i techniczny)
Kroki do reprodukcji: (Precyzyjne)
Rzeczywisty Rezultat: (Techniczny opis błędu + informacja o braku walidacji)
Oczekiwany Rezultat: (Jak powinno być)
Dla Developera: (Wklej tu kluczowy fragment JSON-a z błędem)
  3. Tłumacz Ryzyka
    🔗 https://projects.accesscomputing.uw.edu/au/before.html
    [błąd WCAG] 
    



Rola: Product Owner / Analityk.
Zadanie: Wytłumacz mi ten błąd techniczny.
Kontekst: Muszę wyjaśnić managerowi, dlaczego to jest ryzyko dla biznesu, a nie tylko "błąd w kodzie".
Format: Wiadomość e-mail.

Emilia Krzemińska-Komenda


Emilia to doświadczona inżynierka QA w Hicron Software, łącząca w swojej pracy analityczny umysł testera z pasją do automatyzacji.

Mocno wierzy, że technologia, w tym sztuczna inteligencja, powinna służyć ludziom, dlatego aktywnie rozwija swoją wiedzę w kierunku testowania AI oraz dostępności cyfrowej. Wierzy, że testowanie to droga do tworzenia lepszych i bardziej inkluzywnych produktów.

6 komentarzy

    1. Trafione w punkt! Złota zasada QA: nie ma spania, dopóki system nie poprosi o litość. Designer płacze nad estetyką, my płaczemy dla zasady, ale walczymy do końca!

      Emilia Krzemińska-Komenda Emilia Krzemińska-Komenda
      Odpowiedz

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *