Co to jest QA (Quality Assurance) i czym różni się od testera oprogramowania

Czas czytania: około 12 minut

„QA” to jedno z najczęściej wyszukiwanych i najgorzej rozumianych słów w branży IT. W jednej firmie „QA Engineer” klika po aplikacji i zgłasza błędy. W drugiej ta sama nazwa oznacza osobę, która nigdy nie dotyka gotowego produktu, tylko układa proces, zanim ktokolwiek napisze linijkę kodu. Zamieszanie ma koszt: firma zatrudnia testera, gdy potrzebuje kogoś od procesu, albo szuka „QA”, gdy naprawdę brakuje jej rąk do regresji przed wydaniem.

Ten tekst najpierw wyjaśnia, czym jest QA jako pojęcie i skąd bierze się jego szerokie znaczenie, a potem porządkuje różnicę wobec testera oprogramowania: obowiązki, moment wejścia w projekt, kompetencje i ścieżkę rozwoju. Piszemy dla osób, które chcą wiedzieć, w którą stronę rozwijać karierę, oraz dla liderów, którzy budują zespół i muszą zdecydować, kogo zatrudnić jako pierwszego.

Czym jest QA (Quality Assurance)?

QA (Quality Assurance) to zbiór działań skupionych na procesie wytwarzania oprogramowania, których celem jest zapobieganie błędom, a nie tylko ich wykrywanie; obejmuje ocenę wymagań, standardy, zarządzanie ryzykiem, metryki i raportowanie jakości do organizacji.

Słownik ISTQB definiuje zapewnianie jakości jako część zarządzania jakością skupioną na dawaniu pewności, że wymagania jakościowe zostaną spełnione. To odróżnia QA od kontroli jakości (quality control), która skupia się na spełnieniu wymagań w konkretnym produkcie. Sylabus ISTQB Foundation Level w wersji 4.0 upraszcza to do jednego zdania: testowanie to kontrola jakości, czyli praca na produkcie, a zapewnianie jakości to praca na procesie.

W praktyce polskiego rynku pracy „QA” znaczy więcej niż w podręczniku: skrót zadomowił się jako nazwa całego obszaru testowania i jakości oprogramowania, a „QA Engineer” w większości ogłoszeń oznacza po prostu testera, czasem z elementami automatyzacji. To nie jest błąd językowy, tylko fakt rynkowy, z którym trzeba się liczyć, czytając ogłoszenia: o realnej roli mówi zakres obowiązków, nie tytuł stanowiska. Rozwijamy to w sekcji niżej.

Czym różni się QA od testera oprogramowania?

Tester oprogramowania sprawdza gotowy produkt i znajduje w nim błędy, a specjalista QA pracuje na procesie, żeby błędów powstawało mniej; pierwszy odpowiada na pytanie, czy produkt działa, drugi na pytanie, czy sposób, w jaki go budujemy, daje jakość powtarzalnie.

Testowanie jest częścią zapewniania jakości, ale nie całym zapewnianiem jakości. W wielu firmach jedna osoba robi jedno i drugie, co nie zmienia różnicy między rolami. Jak rozłożyć odpowiedzialność za jakość między testerów, programistów, Product Ownera i zarząd, pokazujemy w artykule kto naprawdę odpowiada za jakość oprogramowania.

Co robi tester oprogramowania?

Tester oprogramowania projektuje i wykonuje testy, dokumentuje znalezione błędy, współpracuje z developerami przy ich naprawie i weryfikuje poprawki, żeby upewnić się, że nie wprowadziły nowych problemów.

• Projektowanie i wykonywanie testów. Tester tworzy plany testów, przypadki testowe i procedury, a potem wykonuje je ręcznie albo automatycznie.
• Identyfikacja i dokumentacja błędów. Znaleziony defekt dostaje opis: jak został wykryty, jakie są objawy, w jakich warunkach się pojawia.
• Współpraca z zespołem deweloperskim. Tester pracuje ramię w ramię z programistami, żeby zgłoszenia były zrozumiałe i szybko naprawiane.
• Walidacja poprawek i regresja. Po naprawie tester sprawdza, czy poprawka działa i czy nie zepsuła obszarów, które działały wcześniej.
• Testy akceptacyjne. Tester często prowadzi testy akceptacyjne użytkownika, żeby potwierdzić, że oprogramowanie spełnia wymagania biznesowe.

Główny cel testera to wykrycie i udokumentowanie defektów, zanim produkt trafi do użytkowników. Jak wejść do tego zawodu od zera, opisujemy w przewodniku Jak zostać testerem oprogramowania, a pytania, które o tę pracę padają na rozmowie rekrutacyjnej, zebraliśmy w artykule praca jako tester oprogramowania: 15 pytań, na które musisz znać odpowiedź.

Co robi specjalista QA?

Specjalista QA zapewnia jakość na wszystkich etapach cyklu życia oprogramowania: ocenia wymagania i dokumentację, ustala standardy i procesy, zarządza ryzykiem, monitoruje jakość i raportuje ją do zarządu, a także szkoli zespół.

• Jakość na każdym etapie cyklu życia. QA angażuje się w planowanie, projektowanie i ocenę procesów wytwórczych, nie tylko w testowanie.
• Zarządzanie ryzykiem. Ocenia ryzyka projektu na każdym etapie, analizuje wymagania i specyfikacje, zanim ktokolwiek zacznie kodować.
• Standardy jakości i procesy. Tworzy i utrzymuje standardy oraz procedury kontroli stosowane przez zespoły projektowe.
• Monitorowanie i raportowanie. Śledzi procesy i wyniki testów, ocenia ogólną jakość i raportuje ją kierownictwu wraz z zaleceniami.
• Wsparcie po wdrożeniu. Po wydaniu QA nadal monitoruje produkt i procesy, żeby utrzymanie odbywało się z zachowaniem tych samych standardów.

Główny cel QA to zapobieganie błędom, a nie tylko ich wykrywanie. Podejście QA jest całościowe: obejmuje wszystko od wymagań, przez implementację i testowanie, po wsparcie po wdrożeniu.

Kiedy w cyklu życia oprogramowania wchodzi tester, a kiedy QA?

Tester wchodzi do procesu, gdy jest co testować, czyli po implementacji, a w zespołach Agile równolegle w sprincie; specjalista QA jest w projekcie od planowania i analizy wymagań, zanim powstanie pierwsza linia kodu.

Ta różnica w momencie wejścia to sedno sporu o role. Zespół, który ma tylko testerów, dowiaduje się o problemie wtedy, gdy poprawka jest już droga. Zespół, który ma QA, ale nie ma testerów, ma piękny proces i nikogo, kto sprawdzi wersję przed piątkowym wydaniem. O przesuwaniu jakości na początek procesu piszemy w tekście o shift left testing.

Jakie kompetencje ma tester, a jakie specjalista QA?

Tester potrzebuje przede wszystkim kompetencji technicznych: narzędzi testowych, podstaw programowania, znajomości Agile i DevOps oraz myślenia analitycznego; specjalista QA dokłada do tego znajomość procesów wytwórczych, standardów jakości, komunikację z interesariuszami i zarządzanie projektem.

Trzy kompetencje są wspólne i bez nich nie ma sensu wchodzić w żadną z ról: rozwiązywanie problemów, ciągłe uczenie się, bo branża zmienia się szybko, oraz zorientowanie na szczegóły. Różnica leży nie w tym, kto jest lepszy, tylko w tym, na czym pracuje: tester na produkcie, QA na sposobie jego budowania.

Dlaczego nazwy stanowisk „QA” tak często mylą?

Nazwy stanowisk mylą, bo firmy używają słowa QA jako synonimu testera, a ta sama nazwa oznacza inne obowiązki w różnych organizacjach; o roli mówi zakres obowiązków w ogłoszeniu, nie tytuł.

Jeżeli w opisie stanowiska są przypadki testowe, regresja i zgłaszanie błędów, to jest praca testera niezależnie od tego, jak ją nazwano. Jeżeli są standardy, audyty procesu, metryki jakości i decyzje o wydaniu, to jest QA. Obie mogą się nazywać tak samo.

Czy QA to awans dla testera?

QA to naturalny kierunek rozwoju dla testera, który chce wpływać na proces zamiast tylko sprawdzać jego wynik, ale nie jedyny: równoległe ścieżki to automatyzacja, testy wydajności i bezpieczeństwa albo rola lidera zespołu testowego.

Tester, który po kilku latach zna produkt, widzi powtarzające się błędy i wie, gdzie w procesie powstają, ma większość wiedzy potrzebnej do pracy QA. Brakuje mu zwykle dwóch rzeczy: nawyku pracy na wymaganiach zamiast na gotowej wersji oraz języka, którym rozmawia się z zarządem o koszcie jakości. Obie da się wyćwiczyć, a rozwój liderów jakości wspieramy w programie QA Leadership Academy. Nie każdy tester chce zostać QA i nie każdy powinien: dobry tester automatyzujący albo specjalista od testów wydajnościowych jest w zespole równie potrzebny.

Kogo potrzebuje Wasza firma: testera czy QA?

Jeżeli błędy wychodzą na produkcji, a przed wydaniem brakuje rąk do regresji, potrzebujecie testera; jeżeli testerów macie, a błędy i tak wracają w tych samych miejscach, potrzebujecie QA, który naprawi proces, a nie kolejnej pary rąk.

Trzy sygnały, które widzimy w audytach procesów QA najczęściej. Pierwszy: firma zatrudnia kolejnych testerów, a czas regresji i tak rośnie, co jest sygnałem braku automatyzacji i procesu, czyli pracy QA. Drugi: zespół ma spisane standardy i metryki, ale nikt nie sprawdza wersji przed wydaniem, bo QA „nie jest od klikania”, co jest sygnałem braku testera. Trzeci, najczęstszy: jedna osoba robi jedno i drugie i żadnego porządnie, bo tuż przed wydaniem zawsze wygrywa klikanie.

Dla PKO BP opracowaliśmy i wdrożyliśmy strategię jakości oprogramowania dla całej organizacji, przeprowadziliśmy audyt istniejących procesów QA oraz szkolenia dla zespołów. To była praca QA w pełnym znaczeniu, na procesie, nie na pojedynczej wersji. Dla Argos, sklepu internetowego, automatyzacja testów i uporządkowanie procesów skróciły regresję z pięciu dni do dziesięciu godzin i obniżyły liczbę błędów krytycznych na produkcji o 46 procent. Tam potrzebne były obie role naraz.

Jeżeli nie wiecie, której brakuje Wam bardziej, najtańszy pierwszy krok to sprawdzić, gdzie w procesie powstają błędy, zanim zatrudnicie kogokolwiek. Robimy to w ramach audytu QA, a gdy brakuje rąk do testów, dostarczamy je w modelu zespołu dedykowanego albo body leasingu. Kompetencje testerskie budujemy szkoleniami z testowania manualnego.

Powiązane na blogu Quality Island

• Jak zostać testerem oprogramowania: ścieżka krok po kroku bez dyplomu informatyka
• Shift left testing: co to jest, zalety, wady i jak wdrożyć krok po kroku
• Poziomy testowania oprogramowania: od testów jednostkowych po akceptacyjne
• Testowanie oprogramowania: możliwe ścieżki rozwoju zawodowego
• Dobry tester oprogramowania: czyli kto?
• Certyfikat ISTQB: co to jest, poziomy, cena egzaminu i czy warto go zdawać

Pełna lista źródeł

• ISTQB Glossary, hasła quality assurance i quality control
• ISTQB, sylabus Certified Tester Foundation Level v4.0, rozdział o różnicy między testowaniem a zapewnianiem jakości
• Dane własne Quality Island: projekty dla PKO BP (strategia jakości, audyt procesów QA, szkolenia zespołów) i Argos (e-commerce, regresja skrócona z 5 dni do 10 godzin, 46 procent mniej błędów krytycznych), liczby potwierdzone przez klientów