Klient to platforma edukacji online z interaktywnymi lekcjami, zadaniami domowymi, kontami uczniów i rodziców oraz płatnościami internetowymi. Biznes jest silnie sezonowy: we wrześniu przybywa najwięcej nowych uczniów, a niedostępność platformy w pierwszych tygodniach roku szkolnego oznacza trwałą utratę klientów. Nie było wewnętrznego zespołu QA; testami między innymi zadaniami zajmowali się programiści. Testy regresyjne przed wydaniem trwały trzy dni, a mimo to pomijały krytyczne scenariusze — płatność, zapis na lekcję i wejście do klasy. Klient zgłosił się do nas po kolejnym incydencie, gdy błąd płatności kosztował szkołę część leadów zebranych latem.
Zbudować proces zapewniania jakości od zera:
strategię testów priorytetyzowaną według ryzyka biznesowego, automatyzację kluczowych scenariuszy, testy zintegrowane z CI i testy obciążeniowe przed wrześniowym szczytem. Ograniczenie: rozwój musiał być kontynuowany — wydania odbywały się co tydzień, a wrzesień nie mógł czekać.
Zaczęliśmy od analizy ryzyka, a nie od testów automatycznych: które scenariusze psują się najczęściej i gdzie koszt błędu jest największy? Automatyzacja ściśle trzymała się tej listy.
- Przeprowadziliśmy audyt jakości: przeanalizowaliśmy błędy z ostatnich sześciu miesięcy, porozmawialiśmy z zespołami i zmapowaliśmy najbardziej bolesne scenariusze — płatność, zapis na lekcję, wejście do klasy i powiadomienia dla rodziców.
- Opracowaliśmy strategię testów: poziomy testowania, zakresy odpowiedzialności, kryteria ukończenia funkcji oraz zasady raportowania błędów wspólne dla trzech zespołów deweloperskich.
- Zautomatyzowaliśmy krytyczną ścieżkę: scenariusze end-to-end Playwright dla platformy webowej, testy API backendu i zestaw smoke testów przed każdym wydaniem.
- Dodaliśmy bramki QA do CI: wydania nie można przeprowadzić bez poprawnego zestawu smoke testów, pełna regresja uruchamia się co noc, a wyniki są widoczne dla wszystkich zespołów w GitLabie.
- Przeprowadziliśmy testy obciążeniowe k6, modelując wrześniowy ruch szczytowy; znaleźliśmy wąskie gardła i usunęliśmy je wspólnie z zespołem backendowym przed sezonem.
- Przekazaliśmy proces klientowi: dokumentację, procedury i szkolenie inżyniera QA z testów automatycznych oraz potoku wdrożeniowego.
Kluczową decyzją była priorytetyzacja według ryzyka biznesowego, a nie „estetyki pokrycia testami”. Świadomie nie dążyliśmy do automatyzacji w 100%: pokrycie 75% kluczowych scenariuszy przyniosło większość efektu, bo chroniło właśnie te ścieżki, na których platforma zarabia i traci klientów. Resztę sprawdza się ręcznie i eksploracyjnie przed ważnymi wydaniami.
Głównym efektem ekonomicznym jest wcześniejsze wykrywanie usterek: błąd znaleziony przez test automatyczny w CI kosztuje dziesiątki razy mniej niż ten zauważony na produkcji przez rodzica ucznia. Platforma weszła w sezon z zapasem bezpieczeństwa, a zespoły zyskały możliwość częstego wydawania zmian bez obawy przed „efektem piątku”. Dodatkowym rezultatem jest zaufanie biznesu: dział sprzedaży może teraz uczciwie obiecywać szkołom partnerskim stabilną platformę w szczycie zapisów.
| Wskaźnik | Wynik |
|---|---|
| Krytyczne błędy na produkcji | 5–7 miesięcznie → 1–2 na kwartał |
| Regresja przed wydaniem | 3 dni ręcznie → 4 godziny z testami automatycznymi |
| Wrześniowy szczyt obciążenia | Incydenty co roku → 0 incydentów, bez spadku wydajności |
| Moment wykrycia błędu | Najczęściej na produkcji → Testy automatyczne wykrywają przed wydaniem |
Wskaźniki przeniesiono z oryginalnych materiałów przypadku. Okres podano tam, gdzie został określony w źródle.
- krytyczne błędy na kwartał (wcześniej 5–7 miesięcznie)
- 1–2
- regresja testami automatycznymi (wcześniej 3 dni ręcznie)
- 4 godz.
- kluczowych scenariuszy objętych testami automatycznymi
- 75%
- incydentów podczas wrześniowego szczytu
- 0
Skala ilustracyjna: 3 dni przeliczono na 72 godziny. Dla długości słupków miesięczny zakres błędów przeliczono na kwartał przez pomnożenie przez trzy; porównano górne granice.
- 01Commit
- 02Zestaw smoke testówBrak zielonego wyniku, brak wydania
- 03WydanieCo tydzień
- 04Nocne uruchomieniePełna regresja
Co rekomendujemy platformie jako następny krok:
- Wizualne testy regresyjne — automatyczna kontrola układu lekcji, wiadomości e-mail i kont osobistych.
- Fabryka danych testowych — generowanie realistycznych uczniów, grup i płatności na potrzeby każdego przebiegu.
- QA na produkcji — feature flagi i wydania canary umożliwiające stopniowe włączanie nowych funkcji.
Przestaliśmy bać się wydań. Wcześniej każdy piątek mógł zamienić się w analizę skarg, a teraz wdrożenie na produkcję jest rutynową procedurą trwającą piętnaście minut.
— CTO szkoły online