Klientas — internetinio mokymo platforma: interaktyvios pamokos, namų darbai, mokinių ir tėvų paskyros bei mokėjimai internetu. Verslui būdingas ryškus sezoniškumas: rugsėjį ateina daugiausia naujų mokinių, o platformos sutrikimas pirmosiomis mokslo metų savaitėmis reiškia klientų praradimą visam laikui. Vidinės QA komandos nebuvo: testavimu tarp kitų užduočių užsiėmė patys kūrėjai. Regresinis testavimas prieš leidimą trukdavo tris dienas, bet vis tiek praleisdavo kritinius scenarijus — mokėjimą, registraciją į pamoką ir prisijungimą prie klasės. Klientas kreipėsi po dar vieno incidento, kai dėl mokėjimo klaidos mokykla prarado dalį vasarą surinktų užklausų.
Nuo nulio sukurti kokybės užtikrinimo procesą:
verslo rizikomis grįstą testavimo strategiją, svarbiausių scenarijų automatizavimą, CI integruotus patikrinimus ir apkrovos testavimą prieš rugsėjo piką. Sąlyga — dirbti nestabdant kūrimo: leidimai vyko kas savaitę, o rugsėjis nelaukė.
Pradėjome ne nuo automatinių testų, o nuo rizikos analizės: kurie scenarijai genda dažniausiai ir kur klaidos kaina didžiausia? Automatizavome griežtai pagal šį sąrašą.
- Atlikome kokybės auditą: peržiūrėjome pastarųjų šešių mėnesių klaidas, apklausėme komandas ir sudarėme skausmingiausių scenarijų žemėlapį — mokėjimas, registracija į pamoką, prisijungimas prie klasės ir pranešimai tėvams.
- Parengėme testavimo strategiją: testavimo lygiai, atsakomybės sritys, funkcijų užbaigimo kriterijai ir klaidų ataskaitų teikimo tvarka, bendra trims kūrimo komandoms.
- Automatizavome kritinį kelią: „Playwright“ e2e scenarijai interneto platformai, API testai serverinei daliai ir dūmų testų rinkinys prieš kiekvieną leidimą.
- Įtraukėme QA vartus į CI: leidimas negalimas, kol dūmų testų rinkinys nėra sėkmingas, visa regresija vykdoma kas naktį, o rezultatai matomi visoms komandoms „GitLab“.
- Atlikome apkrovos testus su k6: imitavome rugsėjo piko srautą, radome siauras vietas ir pašalinome jas kartu su serverinės dalies komanda dar prieš sezoną.
- Perdavėme procesą klientui: dokumentaciją, tvarkas ir QA inžinieriaus mokymus dirbti su automatiniais testais bei leidimų grandine.
Svarbiausias sprendimas buvo prioritetus nustatyti pagal verslo riziką, o ne „gražią aprėptį“. Sąmoningai nesiekėme visiško automatizavimo: 75% kritinių scenarijų aprėptis davė didžiąją dalį naudos, nes apsaugojo būtent tuos kelius, kuriais platforma uždirba ir praranda klientus. Visa kita patikrinama rankiniu tiriamuoju testavimu prieš svarbius leidimus.
Didžiausia ekonominė nauda — defektų aptikimo perkėlimas į ankstesnį etapą: CI automatiniu testu aptikta klaida kainuoja dešimtis kartų mažiau nei ta, kurią produkcijoje pastebi mokinio tėvai. Platforma sezoną pasitiko turėdama atsparumo rezervą, o komandos galėjo dažnai išleisti pakeitimus nebijodamos „penktadienio efekto“. Papildoma nauda — verslo pasitikėjimas: pardavimų skyrius dabar gali sąžiningai pažadėti partnerėms mokykloms stabilią platformą priėmimo į mokslus piko metu.
| Rodiklis | Rezultatas |
|---|---|
| Kritinės klaidos produkcijoje | 5–7 per mėnesį → 1–2 per ketvirtį |
| Regresija prieš leidimą | 3 dienos rankiniu būdu → 4 valandos automatiniais testais |
| Rugsėjo apkrovos pikas | Incidentai kasmet → 0 incidentų, našumui nemažėjant |
| Kada aptinkamas defektas | Dažniausiai produkcijoje → Automatiniai testai aptinka prieš leidimą |
Rodikliai perkelti iš pirminės atvejo medžiagos. Laikotarpis nurodomas ten, kur jis užfiksuotas šaltinyje.
- kritinės klaidos per ketvirtį (buvo 5–7 per mėnesį)
- 1–2
- regresija automatiniais testais (buvo 3 dienos rankiniu būdu)
- 4 val.
- pagrindiniai scenarijai padengti automatiniais testais
- 75%
- incidentai rugsėjo piko metu
- 0
Iliustracinė skalė: 3 dienos laikomos 72 valandomis. Stulpelių ilgiams mėnesinis klaidų intervalas perskaičiuojamas ketvirčiui, dauginant iš trijų; lyginamos viršutinės ribos.
- 01Commit
- 02Dūmų testų rinkinysBe sėkmingo patikrinimo leidimo nėra
- 03LeidimasKas savaitę
- 04Naktinis vykdymasVisa regresija
Ką platformai rekomenduojame kaip kitą žingsnį:
- Vizualinis regresinis testavimas — automatinis pamokų, laiškų ir paskyrų išdėstymo tikrinimas.
- Testinių duomenų gamykla — tikroviškų mokinių, grupių ir mokėjimų generavimas kiekvienam paleidimui.
- QA produkcijoje — funkcijų vėliavėlės ir kanariniai leidimai, kad naujos funkcijos būtų įjungiamos palaipsniui.
Nustojome bijoti leidimų. Anksčiau kiekvienas penktadienis galėjo virsti skundų nagrinėjimu, o dabar leidimas į produkciją — įprasta penkiolikos minučių procedūra.
— Internetinės mokyklos CTO