Inżynieria
Programista
Pięć poziomów od Junior Developera do Principal Engineera i sześć kompetencji – od dostarczania kodu po rozwój zespołu.
- 5 poziomów
- 6 kompetencji
Szablon drabiny kariery
Szablon drabiny kariery QA Engineera
Cztery poziomy od Junior do Lead QA Engineera i sześć kompetencji – od projektowania testów po praktyki jakości.
Plan bezpłatny · Bez karty kredytowej
Ta drabina kariery jest przeznaczona dla QA Engineerów w firmach tworzących oprogramowanie, liczących mniej więcej od 20 do 200 osób – tam, gdzie testerzy pracują w zespołach produktowych, w całej firmie może być ich zaledwie kilku, a ta sama osoba rano prowadzi testy eksploracyjne, a po południu pisze testy automatyczne. Opisuje cztery poziomy – od osoby, która uczy się dobrze testować jedną funkcję, po kogoś, kto decyduje o podejściu do jakości w całej firmie. Najwyższy poziom, Lead QA Engineer, jest poziomem eksperckim, a nie rolą menedżerską.
Każdy poziom określa to, co dana osoba robi i jak daleko sięga jej praca, a nie lata doświadczenia czy liczba zgłoszonych błędów. Czytaj wiersz matrycy kompetencji od lewej do prawej, aby zobaczyć, jak rośnie jedno oczekiwanie; czytaj sekcję poziomu, aby zobaczyć wszystko, czego się na nim oczekuje. Wykorzystaj ją, by wyjaśnić, co oznacza kolejny krok, prowadzić samoocenę i check-iny oraz utrzymać porównywalność decyzji o awansie między zespołami.
Traktuj ją jako wersję roboczą. Jeśli twoi QA Engineerowie nie piszą automatyzacji albo większość testów należy do programistów, zmień sformułowania przed opublikowaniem drabiny – oczekiwanie, którego w twoich warunkach nikt nie może spełnić, tylko frustruje.
Poziomy w skrócie
Junior QA Engineer
Testuje dobrze zdefiniowane funkcje na podstawie istniejących przypadków testowych i poznaje produkt oraz jego użytkowników.
- Zakres
- Pojedyncze historyjki lub poprawki błędów w jednym obszarze produktu, z planami testów przeglądanymi przez kogoś bardziej doświadczonego.
Mid QA Engineer
Odpowiada za testowanie funkcji w jednym zespole – od lektury wymagań po zatwierdzenie wydania.
- Zakres
- Funkcje jednego zespołu produktowego wraz z ich testami manualnymi i automatycznymi.
Senior QA Engineer
Kształtuje to, jak jeden lub dwa zespoły wbudowują jakość w swoją pracę, i odpowiada za strategię testów większych projektów.
- Zakres
- Strategia testów, zestawy testów automatycznych i decyzje o wydaniach jednego lub dwóch zespołów oraz projekty wykraczające poza granice zespołów.
Lead QA Engineer
Wyznacza podejście firmy do jakości i pomaga każdemu zespołowi wydawać z mniejszą liczbą błędów, które przedostają się na produkcję.
- Zakres
- Jakość całego produktu: wspólna infrastruktura testowa, standardy wydań oraz to, jak QA jest obsadzone i jak pracuje.
Matryca kompetencji
Każdy wiersz to kompetencja, a każda kolumna – poziom. Czytaj wiersz od lewej do prawej, aby zobaczyć, jak rosną oczekiwania.
Co oznacza każda kompetencja
- Projektowanie i analiza testów
- Ustalanie, co może pójść źle, i dobór testów, które to wykryją.
- Automatyzacja testów
- Budowanie testów automatycznych, które są szybkie, stabilne i cieszą się zaufaniem zespołu.
- Analiza i zgłaszanie błędów
- Znajdowanie, odtwarzanie i wyjaśnianie problemów tak, by szybko zostały naprawione.
- Ocena wydań i ryzyka
- Decydowanie, czy coś jest gotowe do wydania, i jasne mówienie o tym.
- Praktyki jakości
- Wbudowywanie jakości w sposób pracy zespołu zamiast dotestowywania jej na końcu.
- Mentoring i dzielenie się wiedzą
- Pomaganie innym lepiej testować i dbanie o to, by wiedza o produkcie nie była w jednej głowie.
| Kompetencja | Junior QA Engineer | Mid QA Engineer | Senior QA Engineer | Lead QA Engineer |
|---|---|---|---|---|
| Projektowanie i analiza testów | Starannie wykonuje istniejące przypadki testowe, pisze nowe przypadki dla małych historyjek, obejmujące główną ścieżkę i oczywiste przypadki brzegowe, i przed rozpoczęciem testów dopytuje o niejasne wymagania. | Pisze plan testów dla każdej funkcji w zespole, obejmujący przypadki brzegowe, uprawnienia, stany danych i integracje, i przegląda wymagania przed rozpoczęciem prac programistycznych, by wychwycić luki. | Projektuje strategię testów dla projektów obejmujących kilka funkcji lub zespołów, decyduje, co pokryć na poziomie testów jednostkowych, API i end-to-end, i skupia wysiłek na częściach, które najpewniej się zepsują. | Określa, jak firma decyduje, co i jak dogłębnie testować, na podstawie ryzyka i danych o użyciu, i dba o to, by każdy zespół stosował to spójnie. |
| Automatyzacja testów | Dodaje testy automatyczne do istniejącego frameworka testowego zgodnie z przyjętymi wzorcami, uruchamia zestaw lokalnie i zgłasza błędy, których nie potrafi wyjaśnić, zamiast uruchamiać testy ponownie, aż przejdą. | Automatyzuje testy regresji dla funkcji zespołu, dba o ich stabilność i czytelność oraz naprawia lub usuwa niestabilne testy, zamiast je ignorować. | Projektuje strukturę zestawu testów automatycznych, włącza go do pipeline’u wdrożeniowego z rozsądnym czasem wykonania i przegląda testy pisane przez programistów i innych QA Engineerów. | Wybiera narzędzia testowe i wspólną infrastrukturę firmy, równoważy warstwy piramidy testów w różnych produktach i utrzymuje cały zestaw na tyle szybki, że zespoły faktycznie czekają na jego wynik. |
| Analiza i zgłaszanie błędów | Zgłasza błędy z jasnymi krokami, oczekiwanym i faktycznym wynikiem oraz opisem środowiska, tak by programista mógł odtworzyć problem bez dodatkowych pytań. | Zawęża przyczyny błędów, korzystając z logów, śladów ruchu sieciowego i bazy danych, ocenia ich wagę według wpływu na użytkowników i potwierdza poprawki, łącznie z sąsiednimi przypadkami. | Bada sporadyczne problemy i takie, które występują tylko na produkcji, w wielu serwisach, dostrzega wzorce w powracających błędach i zamienia je w propozycje, które eliminują całą klasę błędów. | Odpowiada za to, jak firma śledzi błędy i nadaje im priorytety, raportuje kierownictwu inżynierii trendy błędów, które przedostały się na produkcję, i dba o to, by na usunięcie największych źródeł błędów znalazły się środki. |
| Ocena wydań i ryzyka | Wykonuje przydzielone kontrole przed wydaniem, raportuje, co zostało, a co nie zostało przetestowane, i zgłasza wątpliwości bardziej doświadczonemu QA Engineerowi. | Daje jasną rekomendację „wydajemy” lub „nie wydajemy” dla wydań zespołu, wyjaśniając znane ryzyka i to, co pozostało nieprzetestowane, i bierze udział w kontrolach po wydaniu. | Razem z programistami decyduje o sposobie wydania ryzykownych zmian – feature flagi, stopniowe wdrażanie, dodatkowy monitoring – i prowadzi testy podczas incydentów i hotfixów. | Ustala standardy wydań, według których pracuje każdy zespół, określa, kiedy wydanie można zablokować, i jest osobą, którą kierownictwo pyta, czy produkt jest gotowy na ważną premierę. |
| Praktyki jakości | Przestrzega obowiązującej w zespole definicji ukończenia i procesu testowania oraz wskazuje kroki, które są pomijane lub niejasne. | Uczestniczy w refinementach i dyskusjach projektowych, by wcześnie dodać kryteria akceptacji i kwestie testowalności, i pracuje z programistami nad tym, co powinny pokrywać ich własne testy. | Usprawnia proces testowania jednego lub dwóch zespołów – środowiska testowe, dane testowe, checklisty do review – i mierzy, czy zmiana zmniejszyła liczbę błędów, które przedostają się na produkcję. | Kształtuje praktyki jakości w całej inżynierii, decyduje, gdzie pracują QA Engineerowie i za co odpowiadają programiści, i sprawia, że jakość jest wspólną odpowiedzialnością, a nie zadaniem jednego zespołu. |
| Mentoring i dzielenie się wiedzą | Podczas testowania dokumentuje to, czego dowiaduje się o produkcie, i dzieli się z zespołem przydatnymi odkryciami i narzędziami. | Utrzymuje aktualną dokumentację testową zespołu, wprowadza nowe osoby w swój obszar produktu i wyjaśnia techniki testowania programistom, którzy o nie pytają. | Świadomie mentoruje juniorów QA, prowadzi dla programistów sesje o podejściach do testowania i bierze udział w rozmowach rekrutacyjnych na role QA. | Rozwija umiejętności i ścieżki kariery w grupie QA, określa, jak QA Engineerowie są rekrutowani i wdrażani, i rozwija kolejnych seniorów i leadów QA. |
Przewiń tabelę w bok, aby zobaczyć wszystkie poziomy.
Pobierz jako CSV Otwiera się w Excelu, Arkuszach Google lub Numbers.
Junior QA Engineer: czego się oczekuje
Testuje dobrze zdefiniowane funkcje na podstawie istniejących przypadków testowych i poznaje produkt oraz jego użytkowników. Pojedyncze historyjki lub poprawki błędów w jednym obszarze produktu, z planami testów przeglądanymi przez kogoś bardziej doświadczonego.
- Projektowanie i analiza testów
- Starannie wykonuje istniejące przypadki testowe, pisze nowe przypadki dla małych historyjek, obejmujące główną ścieżkę i oczywiste przypadki brzegowe, i przed rozpoczęciem testów dopytuje o niejasne wymagania.
- Automatyzacja testów
- Dodaje testy automatyczne do istniejącego frameworka testowego zgodnie z przyjętymi wzorcami, uruchamia zestaw lokalnie i zgłasza błędy, których nie potrafi wyjaśnić, zamiast uruchamiać testy ponownie, aż przejdą.
- Analiza i zgłaszanie błędów
- Zgłasza błędy z jasnymi krokami, oczekiwanym i faktycznym wynikiem oraz opisem środowiska, tak by programista mógł odtworzyć problem bez dodatkowych pytań.
- Ocena wydań i ryzyka
- Wykonuje przydzielone kontrole przed wydaniem, raportuje, co zostało, a co nie zostało przetestowane, i zgłasza wątpliwości bardziej doświadczonemu QA Engineerowi.
- Praktyki jakości
- Przestrzega obowiązującej w zespole definicji ukończenia i procesu testowania oraz wskazuje kroki, które są pomijane lub niejasne.
- Mentoring i dzielenie się wiedzą
- Podczas testowania dokumentuje to, czego dowiaduje się o produkcie, i dzieli się z zespołem przydatnymi odkryciami i narzędziami.
Mid QA Engineer: czego się oczekuje
Odpowiada za testowanie funkcji w jednym zespole – od lektury wymagań po zatwierdzenie wydania. Funkcje jednego zespołu produktowego wraz z ich testami manualnymi i automatycznymi.
- Projektowanie i analiza testów
- Pisze plan testów dla każdej funkcji w zespole, obejmujący przypadki brzegowe, uprawnienia, stany danych i integracje, i przegląda wymagania przed rozpoczęciem prac programistycznych, by wychwycić luki.
- Automatyzacja testów
- Automatyzuje testy regresji dla funkcji zespołu, dba o ich stabilność i czytelność oraz naprawia lub usuwa niestabilne testy, zamiast je ignorować.
- Analiza i zgłaszanie błędów
- Zawęża przyczyny błędów, korzystając z logów, śladów ruchu sieciowego i bazy danych, ocenia ich wagę według wpływu na użytkowników i potwierdza poprawki, łącznie z sąsiednimi przypadkami.
- Ocena wydań i ryzyka
- Daje jasną rekomendację „wydajemy” lub „nie wydajemy” dla wydań zespołu, wyjaśniając znane ryzyka i to, co pozostało nieprzetestowane, i bierze udział w kontrolach po wydaniu.
- Praktyki jakości
- Uczestniczy w refinementach i dyskusjach projektowych, by wcześnie dodać kryteria akceptacji i kwestie testowalności, i pracuje z programistami nad tym, co powinny pokrywać ich własne testy.
- Mentoring i dzielenie się wiedzą
- Utrzymuje aktualną dokumentację testową zespołu, wprowadza nowe osoby w swój obszar produktu i wyjaśnia techniki testowania programistom, którzy o nie pytają.
Senior QA Engineer: czego się oczekuje
Kształtuje to, jak jeden lub dwa zespoły wbudowują jakość w swoją pracę, i odpowiada za strategię testów większych projektów. Strategia testów, zestawy testów automatycznych i decyzje o wydaniach jednego lub dwóch zespołów oraz projekty wykraczające poza granice zespołów.
- Projektowanie i analiza testów
- Projektuje strategię testów dla projektów obejmujących kilka funkcji lub zespołów, decyduje, co pokryć na poziomie testów jednostkowych, API i end-to-end, i skupia wysiłek na częściach, które najpewniej się zepsują.
- Automatyzacja testów
- Projektuje strukturę zestawu testów automatycznych, włącza go do pipeline’u wdrożeniowego z rozsądnym czasem wykonania i przegląda testy pisane przez programistów i innych QA Engineerów.
- Analiza i zgłaszanie błędów
- Bada sporadyczne problemy i takie, które występują tylko na produkcji, w wielu serwisach, dostrzega wzorce w powracających błędach i zamienia je w propozycje, które eliminują całą klasę błędów.
- Ocena wydań i ryzyka
- Razem z programistami decyduje o sposobie wydania ryzykownych zmian – feature flagi, stopniowe wdrażanie, dodatkowy monitoring – i prowadzi testy podczas incydentów i hotfixów.
- Praktyki jakości
- Usprawnia proces testowania jednego lub dwóch zespołów – środowiska testowe, dane testowe, checklisty do review – i mierzy, czy zmiana zmniejszyła liczbę błędów, które przedostają się na produkcję.
- Mentoring i dzielenie się wiedzą
- Świadomie mentoruje juniorów QA, prowadzi dla programistów sesje o podejściach do testowania i bierze udział w rozmowach rekrutacyjnych na role QA.
Lead QA Engineer: czego się oczekuje
Wyznacza podejście firmy do jakości i pomaga każdemu zespołowi wydawać z mniejszą liczbą błędów, które przedostają się na produkcję. Jakość całego produktu: wspólna infrastruktura testowa, standardy wydań oraz to, jak QA jest obsadzone i jak pracuje.
- Projektowanie i analiza testów
- Określa, jak firma decyduje, co i jak dogłębnie testować, na podstawie ryzyka i danych o użyciu, i dba o to, by każdy zespół stosował to spójnie.
- Automatyzacja testów
- Wybiera narzędzia testowe i wspólną infrastrukturę firmy, równoważy warstwy piramidy testów w różnych produktach i utrzymuje cały zestaw na tyle szybki, że zespoły faktycznie czekają na jego wynik.
- Analiza i zgłaszanie błędów
- Odpowiada za to, jak firma śledzi błędy i nadaje im priorytety, raportuje kierownictwu inżynierii trendy błędów, które przedostały się na produkcję, i dba o to, by na usunięcie największych źródeł błędów znalazły się środki.
- Ocena wydań i ryzyka
- Ustala standardy wydań, według których pracuje każdy zespół, określa, kiedy wydanie można zablokować, i jest osobą, którą kierownictwo pyta, czy produkt jest gotowy na ważną premierę.
- Praktyki jakości
- Kształtuje praktyki jakości w całej inżynierii, decyduje, gdzie pracują QA Engineerowie i za co odpowiadają programiści, i sprawia, że jakość jest wspólną odpowiedzialnością, a nie zadaniem jednego zespołu.
- Mentoring i dzielenie się wiedzą
- Rozwija umiejętności i ścieżki kariery w grupie QA, określa, jak QA Engineerowie są rekrutowani i wdrażani, i rozwija kolejnych seniorów i leadów QA.
Jak dopasować tę drabinę
Zapisz, jakie są u ciebie proporcje testów manualnych i automatycznych
Jeśli twoi QA Engineerowie skupiają się na testach eksploracyjnych, skróć wiersz „Automatyzacja testów” i rozbuduj „Projektowanie i analiza testów”. Jeśli głównie budują automatyzację, podnieś oczekiwania co do jakości kodu. Tak czy inaczej, nazwij ten wybór wprost, by nikt nie był oceniany za pracę, do której go nie zatrudniono.
Wprowadź poziom Lead dopiero wtedy, gdy to realna praca
Przy dwóch–trzech QA Engineerach firma zwykle potrzebuje tylko poziomów Junior, Mid i Senior. Dodaj Lead, gdy ktoś naprawdę ustala standardy jakości dla każdego zespołu – nie jako nagrodę dla testera z najdłuższym stażem. W tej drabinie Lead to poziom ekspercki; jeśli twój QA lead zarządza też testerami, dodaj oczekiwania dotyczące ludzi z drabiny engineering managera.
Zrównaj poziomy z drabiną programistów
Przypisz każdemu poziomowi QA poziom programisty o porównywalnym zakresie i wynagrodzeniu. Gdy Senior QA Engineer stoi obok Senior Developera, przejście między tymi ścieżkami staje się krokiem w bok, a nie degradacją ani skokiem.
Zbieraj dowody, a nie liczbę błędów
Na check-iny i do wniosków o awans zbieraj przykłady, takie jak plan testów, który wychwycił kosztowny błąd, niestabilny zestaw testów, który stał się niezawodny, czy decyzja o wydaniu, która się obroniła. Liczenie zgłoszonych błędów nagradza szum i karze testerów w stabilnych zespołach.
FAQ
Pytania o tę drabinę
Ile poziomów potrzebuje drabina kariery QA Engineera?
W firmie liczącej 20–200 osób zwykle wystarczą trzy lub cztery, bo grupy QA są małe. Ten szablon ma cztery: Junior QA Engineer, Mid QA Engineer, Senior QA Engineer i Lead QA Engineer. Piąty dodaj dopiero wtedy, gdy zakres pracy naprawdę wykracza poza ustalanie standardów jakości dla całego produktu.
Czy testerzy manualni i automatyzujący powinni mieć wspólną drabinę kariery?
W większości mniejszych firm tak. Sedno pracy – rozumienie ryzyka, projektowanie testów i ocena wydań – jest takie samo; różnią się tylko narzędzia. Utrzymuj jedną drabinę i uzgodnij dla każdej osoby lub zespołu, w jakim stopniu obowiązuje wiersz „Automatyzacja testów”.
Czy QA Engineer może przejść na ścieżkę programisty?
Tak, i najlepiej sprawdza się to jako zaplanowane przejście. Porównaj daną osobę z drabiną programisty, uzgodnij kilka działań rozwojowych, takich jak samodzielne prowadzenie małych funkcji czy poprawek błędów, i przenieś ją, gdy stale spełnia oczekiwania tego poziomu. Doświadczenie w testowaniu zwykle czyni z niej lepszego programistę, a nie gorszego.
Jak oceniać pracę QA Engineera bez liczenia błędów?
Patrz na rezultaty i zachowanie: błędy, które w jego obszarze przedostały się na produkcję, niezawodność i szybkość zestawu testów automatycznych, to, jak wcześnie sygnalizuje ryzyka, i to, jak obroniły się decyzje o wydaniach. Omawiaj konkretne przykłady względem drabiny na regularnych check-inach, zamiast polegać wyłącznie na dashboardach.
Ilu QA Engineerów potrzebuje zespół programistów?
Nie ma stałej proporcji. Wiele firm tej wielkości ma jednego QA Engineera na czterech–ośmiu programistów, ale właściwa liczba zależy od tego, ile programiści testują sami i jak kosztowny jest błąd dla twoich użytkowników. Obserwuj błędy, które przedostają się na produkcję, i opóźnienia wydań, a zatrudniaj, gdy jedno lub drugie stale rośnie.
Zbuduj tę drabinę kariery w LadderKit – za darmo
Ustaw jej poziomy i umiejętności dla swojego zespołu, oceniaj według nich ludzi w check-inach i zachowaj spójność decyzji o awansach.
Plan bezpłatny · Bez karty kredytowej
Powiązane szablony
Inżynieria
DevOps Engineer
Cztery poziomy od Junior do Staff DevOps Engineera i sześć kompetencji – od infrastruktury po wsparcie programistów.
- 4 poziomy
- 6 kompetencji
Inżynieria
Engineering Manager
Cztery poziomy od Engineering Managera do VP of Engineering i sześć kompetencji menedżerskich.
- 4 poziomy
- 6 kompetencji