Rola QA w nowoczesnym zespole: QA vs SDET vs Developer
Co tak naprawdę robi inżynier QA? Poznaj różnice między QA, SDET i Developerem, granice testów i anty-wzorce, które niszczą jakość w zespole.
“Co właściwie robisz cały dzień?”
To pytanie słyszałem więcej razy, niż jestem w stanie zliczyć — od programistów, product ownerów, rekruterów i czasem od własnej rodziny. Zwykle pada z dobrymi intencjami, ale ujawnia prawdziwą lukę w rozumieniu tego, czym jest nowoczesna inżynieria QA.
To ważne, bo sposób, w jaki zespół myśli o QA, kształtuje strukturę pracy, zakres zaangażowania różnych ról i ostatecznie ilość jakości, którą produkt faktycznie posiada. W tym artykule chcę rozwiać zamieszanie między trzema rolami — QA Engineer, SDET i Developer — i wyjaśnić, jak wyglądają ich zdrowe i niezdrowe warianty.
Trzy role zdefiniowane
QA Engineer (Quality Assurance)
Głównym obszarem działania QA Engineera jest strategia jakości, analiza ryzyka i doskonalenie procesów. To osoba w zespole, która pyta “co może pójść nie tak?” zanim kod zostanie napisany.
Kluczowe umiejętności: Projektowanie testów, exploratory testing, analiza wymagań, komunikowanie defektów, dokumentacja.
Wyniki pracy: Plany testów, przypadki testowe, oceny ryzyka, notatki z sesji eksploracyjnych, metryki jakości, rekomendacje usprawnień procesów.
Czego może, a czego nie musi robić: QA Engineer niekoniecznie pisze kod automatyzacji. Niektórzy to robią — szczególnie w nowoczesnych zespołach — ale “QA” nie oznacza automatycznie automatyzacji.
Najlepsi QA Engineerowie, z którymi pracowałem, wyróżniają się myśleniem krytycznym, komunikacją i systemowym rozumieniem produktu. Potrafią wychwycić niejednoznaczne wymaganie w user story na odległość i wiedzą, która kombinacja danych wejściowych z największym prawdopodobieństwem zepsuje nową funkcję.
SDET (Software Development Engineer in Test)
SDET to inżynier oprogramowania specjalizujący się w narzędziach testowych, frameworkach automatyzacji i infrastrukturze testów. Rola łączy strategię QA z inżynierią oprogramowania.
Kluczowe umiejętności: Programowanie, CI/CD, projektowanie frameworków testowych, testowanie API, narzędzia do testów wydajnościowych.
Wyniki pracy: Frameworki automatyzacji, helpery testowe, konfiguracje pipeline CI, własne reportery testów, fabryki danych testowych.
Co odróżnia ich od QA: SDET pisze kod o jakości produkcyjnej — nie tylko skrypty. Myślą o pielęgnowalności, wzorcach projektowych i wydajności samego zestawu testów. Słabo napisana suita E2E to ich problem do naprawienia.
Co odróżnia ich od programistów: SDET myślą o tym, jak testować system, nie tylko jak go budować. Projektują z myślą o testowalności. Dbają o obserwowalność. Od pierwszego dnia pytają “jak będziemy wiedzieć, że to się zepsuło?”
Developer (z odpowiedzialnością za testowanie)
W nowoczesnych zespołach każdy programista ma obowiązki testowe — i to nie jest opcjonalne.
Podstawowe obowiązki testowe:
- Pisanie i utrzymywanie testów jednostkowych dla logiki biznesowej
- Udział w code review uwzględniający pokrycie testami
- Rozróżnianie między testowaniem a debugowaniem
- Nie mergowanie kodu, który psuje zestaw testów
Gdzie wiele zespołów zawodzi: Programiści, którzy traktują testowanie jako “robotę QA”, tworzą strukturalny bottleneck, którego żadne zasoby QA nie są w stanie wypełnić. Jeśli dwóch programistów wprowadza defekty szybciej, niż jeden QA może je znaleźć i zgłosić, pipeline przecieka — na stałe.
Gdzie leżą granice testów
Jednym z najbardziej użytecznych ćwiczeń dla każdego zespołu jest jawne określenie, kto pisze, utrzymuje i przegląda każdą warstwę testów.
| Warstwa testów | Główny właściciel | Pomocniczy właściciel | Przegląd |
|---|---|---|---|
| Testy jednostkowe | Developer | — | Code review |
| Testy integracyjne | Developer / SDET | QA (strategia) | Code review |
| Testy API / kontraktowe | SDET | Developer | Sign-off QA |
| Testy E2E | SDET / QA | Developer | QA |
| Exploratory testing | QA | SDET | — |
| Testy wydajnościowe | SDET | DevOps | Strategia QA |
Ta tabela nie jest uniwersalna — rozmiar zespołu, dojrzałość i architektura wpływają na własność. Ale posiadanie jawnej tabeli jest znacznie bardziej użyteczne niż mgłowe założenia.
Wzorce współpracy, które działają
Three Amigos (Trzech Amigos)
Three Amigos to krótkie spotkanie (15–30 min), podczas którego trzy perspektywy recenzują user story przed rozpoczęciem developmentu:
- Developer — “Jak to zbuduję?”
- QA — “Jak to przetestuję? Co może pójść nie tak?”
- Product Owner / BA — “Czy to faktycznie spełnia potrzebę biznesową?”
Celem jest wczesne wykrycie nieporozumień — gdy marker tablicy jest tańszy niż refaktor kodu.
Definicja ukończenia jako quality gate
Dobrze napisana Definition of Done wymusza rozmowy o jakości w ramach przepływu pracy sprintu. DoD, która zawiera “pokrycie testami jednostkowymi dla nowego kodu” i “sesja eksploracyjna zakończona dla nowych funkcji”, to strukturalny quality gate — nie zależy od tego, czy ktoś o nim pamięta.
Pair Testing (testowanie w parze)
Testowanie wspólnie przez programistę i QA Engineera — gdzie programista prowadzi, a QA zadaje pytania — ujawnia przypadki brzegowe, których żaden z nich nie znalazłby sam. Buduje też wzajemne rozumienie, co oznacza “gotowe.”
Anty-wzorce, które niszczą jakość zespołu
”QA jako gatekeeper”
Najczęstszy i najbardziej szkodliwy anty-wzorzec. QA siedzi na końcu sprintu jako ostatni punkt kontrolny. Development “rzuca pracę przez mur” do QA, który znajduje defekty, zgłasza je, a development je naprawia — w pętli, która wydłuża każdy sprint o dni.
Konsekwencje: Kultura obwiniania, wolna dostawa, QA jako bottleneck, “QA to zatwierdziło” jako wymówka dla bugów produkcyjnych.
Rozwiązanie: Angażuj QA na planowaniu sprintu. Testuj równolegle z developmentem. Usuń “fazę QA” z harmonogramu sprintu.
”QA to tylko wykonywanie”
QA dostaje plan testów napisany przez kogoś innego i jest proszony o jego wykonanie. Znajduje defekty, ale nie ma wpływu na to, co jest testowane ani jak produkt jest projektowany.
Konsekwencje: Defekty znajdowane zbyt późno, brak priorytetyzacji opartej na ryzyku, załamanie morale QA, wysoka rotacja.
Rozwiązanie: QA powinno współtworzyć kryteria akceptacji. QA powinno przeglądać projekty. QA powinno mieć głos w priorytetyzacji.
”Programiści nie testują”
“To robota QA” słychać na sprint review, gdy testerzy znajdą bugi, które programiści powinni byli wykryć. QA staje się zbiornikiem na rzeczy, które powinny były być zapobiegane.
Konsekwencje: QA spędza 80% czasu na znajdowaniu oczywistych bugów, 20% na prawdziwej analizie ryzyka.
Rozwiązanie: Testy jednostkowe jako element Definition of Done. Sprawdzanie pokrycia w code review. Pair testing dla złożonych funkcji.
”SDET to robot testujący”
SDET jest zatrudniony, dostaje listę manualnych przypadków testowych i jest proszony o “zautomatyzowanie wszystkiego.” Żadnej strategii, żadnego projektowania frameworka, żadnej analizy ryzyka — tylko konwersja skryptów do kodu Playwright.
Konsekwencje: Tysiące testów E2E, które działają godzinami, często nie przechodzą i nic sensownego nie mówią. SDET odchodzi w ciągu 12 miesięcy.
Rozwiązanie: Daj SDET problem strategiczny, nie problem transkrypcji. Pozwól im zaprojektować framework. Pozwól im wybierać, czego nie automatyzować.
Nowoczesny model — wbudowana jakość
Model, który działa w wysoko wydajnych zespołach inżynierskich, wygląda tak:
- QA jest zaangażowane od etapu wymagań, nie dopiero od “gotowe do testowania”
- Programiści posiadają jakość testów jednostkowych i integracyjnych
- SDET utrzymuje framework automatyzacji i integrację CI
- Quality gates są zautomatyzowane — bez ludzkiego bottlenecka
- Exploratory testing to zaplanowana aktywność, nie reakcja kryzysowa
To nie jest utopia — to co faktycznie robią zespoły z dobrą kulturą jakości. I zaczyna się od jednej rzeczy: uzgodnienia, kto za co odpowiada.
Podsumowanie
Nie istnieje jeden słuszny model dla ról QA, SDET i Developer. Zależy to od rozmiaru zespołu, dojrzałości produktu i struktury organizacji. Istnieją jednak modele błędne — i te najbardziej powszechne to anty-wzorce opisane powyżej.
Zacznij od najprostszej zmiany: angażuj QA wcześniej. Dziel własność testów. Włącz kryteria jakości do Definition of Done. Te trzy zmiany poprawią jakość bardziej niż jakiekolwiek nowe narzędzie czy framework testowy.
To jest drugi artykuł z serii Seria 1 — QA Ogólne.