INŻYNIERIA JAKOŚCI
Bramka czyta raport. Czerwony build nie wchodzi do merge.
Inżynieria jakości ustawia reguły pipeline, według których test z TestLab i skrypt z Automation Hub mają skutek. Artefaktem jest strategia w repo, próg w jobie i właściciel katalogu. Nie jest nim prezentacja o kulturze jakości.
Artefakty, które zostają po wejściu zespołu
- Strategia testów w repo: które poziomy istnieją, które ścieżki są na bramce, które mogą zostać poza nią.
- Bramka pipeline: job wymagany przed merge, z jawną listą zestawów, które muszą być zielone.
- Próg coverage tam, gdzie pomiar już jest w buildzie. Próg jest liczbą w konfiguracji, nie hasłem w dokumencie.
- Katalog testów z nazwą właściciela. Padnięty zestaw ma osobę, która czyta log, nie kolejkę bez adresata.
- Kwarantanna dla testów niestabilnych: osobny job, powód, data przeglądu.
Wejście zaczyna się od odczytu istniejącego CI. Jeśli runner już publikuje raport, bramka podpina się pod ten raport. Wymiana systemu buildów nie jest warunkiem pracy. Warunkiem jest to, żeby status joba był maszynowo czytelny.
Poziomy, które strategia rozdziela
| Poziom | Gdzie żyje | Skutek dla merge |
|---|---|---|
| Test jednostkowy i integracyjny backendu | PHPUnit, Jest, job na każdą zmianę | Czerwony zestaw blokuje merge. Próg coverage, jeśli jest włączony, jest warunkiem tego samego joba. |
| Kontrakt API | Schemat endpointu i test kontraktu | Niezgodność schematu z implementacją blokuje merge. Kontrakt nie jest dokumentem obok repo. |
| E2E krytycznych ścieżek | Playwright albo Selenium na środowisku testowym | Na bramce zostaje krótki zestaw ścieżek zapisu, odczytu i uprawnień. Reszta może iść w jobie nocnym, jeśli strategia tak stanowi. |
| Smoke po deployu | Osobny job na środowisku docelowym | Nie zastępuje bramki przed merge. Sprawdza, czy deploy wstał. Czerwony smoke zatrzymuje promocję wydania. |
Strategia ma prawo powiedzieć, że danego poziomu jeszcze nie ma. Brak E2E jest wtedy wpisem w strategii, z warunkiem, pod którym poziom powstanie, a nie milczeniem. Bramka nie udaje pokrycia, którego runner nie odpala.
Definicja zielonego builda
Zielony build oznacza, że wymagane joby zakończyły się kodem sukcesu, raport jest dołączony, a próg coverage, jeśli obowiązuje, jest spełniony. Pominięty job, pusty raport albo ręcznie kliknięty status „przeszło” nie spełniają definicji. Konfiguracja branch protection albo równoważna reguła w systemie CI zapisuje tę definicję tak, żeby dało się ją przeczytać bez pytania autora.
Wyjątek od bramki jest zdarzeniem w historii: kto, który job, jaki powód, do kiedy wyjątek obowiązuje. Wyjątek bez daty końca zostaje w repo jako dług. Przegląd długów jest częścią pracy inżyniera jakości, nie osobnym rytuałem bez wpisu.
Test niestabilny
Test, który na tym samym commicie raz przechodzi, a raz nie, psuje sygnał bramki. Zostaje zdjęty z wymaganej bramki i przeniesiony do kwarantanny. Wpis kwarantanny zawiera nazwę przypadku, objaw z logu, właściciela i datę decyzji: naprawa albo usunięcie. Powrót na bramkę następuje po serii zielonych przebiegów na kwarantannie, nie po jednej zielonej próbie.
Nie wyłączamy asercji po to, żeby słupek był zielony. Jeśli scenariusz sprawdza zachowanie, którego produkt już nie ma, test jest usuwany albo przepisywany razem ze zmianą produktu, w tym samym zestawie zmian.
Coverage jako próg, nie jako ozdoba
Pomiar coverage wchodzi do joba tylko wtedy, gdy narzędzie pomiaru już da się odpalić w runtime zespołu. Próg ustawiamy na wartości, którą aktualny zestaw spełnia, a potem podnosimy go przy kolejnych zmianach, zamiast wpisać liczbę z innego projektu. Spadek poniżej progu jest czerwonym jobem. Wyłączenie pomiaru w konfiguracji jest zmianą w repo i przechodzi review jak każda inna zmiana bramki.
Coverage nie zastępuje kontraktu API ani ścieżki E2E. Linia pokryta testem jednostkowym może nadal złamać schemat odpowiedzi. Dlatego strategia trzyma poziomy obok siebie, a nie sprowadza jakości do jednej liczby.
Jak wygląda wejście w organizację
-
01
Odczyt pipeline
Lista jobów, wymaganych checków, miejsc, w których status da się kliknąć ręcznie, i katalogów testów bez właściciela.
-
02
Strategia w pliku
Poziomy, bramka, progi, kwarantanna, właściciele. Plik leży w repo, nie w załączniku wiadomości.
-
03
Konfiguracja bramki
Wymagane checki w CI. TestLab dostarcza zestawy, których na liście brakuje. Hub dostarcza szablon joba, jeśli runner go nie ma.
-
04
Przegląd po pierwszym cyklu
Które joby były czerwone z powodu produktu, które z powodu testu, które z powodu środowiska. Kwarantanna dostaje wpisy. Próg zostaje albo się przesuwa, z uzasadnieniem w zmianie.
Godziny pracy inżyniera KoneV przy tej linii są w planach Business i Business Pro. Zakres Enterprise opisuje opiekuna i warunki osobno. Cennik jest na własnej podstronie. Praktyka osób, które takie bramki składały przez ponad 20 lat w usłudze zewnętrznej, jest opisana na stronie o nas. Spółka tę praktykę dopiero przenosi na własną ofertę.