Kur pradėti nuo esamos svetainės bandymo automatikos?

Endrius klausia:

Neseniai prisijungiau prie internetinės bendrovės kaip pirmasis jų QA narys. Svetainė buvo sukurta per pastaruosius penkerius metus ir per šį laiką kūrėjai ir kiti komandos nariai atliko bandymus.

Nėra jokio oficialaus kokybės užtikrinimo ar testavimo proceso, todėl visi bandymai daugiausia buvo ad hoc.

Dabar mano vadybininkas, atsakingas už programinės įrangos pristatymą, nori, kad sukurčiau automatinį regresijos testavimo paketą, kurį komanda galėtų vykdyti, kai tik sukurtų naujų funkcijų.

Mano klausimas yra toks: kur pradėti testavimo automatizavimą, kad sukūrčiau šį regresijos paketą daugiau nei penkerius metus veikiančiai svetainei?

Bet kokios idėjos / pasiūlymai būtų labai vertinami.

Mano atsakymas:

Kai svetainė jau daugelį metų veikia ir aptarnauja tiesioginius klientus, ji yra subrendusi. Sakydamas „brandus“, turiu galvoje, kad sistemoje nėra (tikiuosi) akivaizdžių rimtų klaidų ir, jei tokių yra, tai bus subtilios ar svarbiausios problemos, kurias ne visi pastebi lengvai.

Ką mes neturėtų daryti, yra bandyti atgaline data parašyti visų jau sukurtų ir sistemos dalimi tapusių istorijų testus. Tačiau mes norime pagrindinių rinkinių, kurie naudoja sistemą nuo galo iki galo, siekiant užtikrinti, kad būsimi pokyčiai nepakenktų esamoms funkcijoms.

Toliau pateikiamos kelios gairės, kurias galima naudoti esamoje ir jau sukurtoje svetainėje, norint rasti pagrindinius scenarijus ir jų išplėtimo metodą, kad būtų sukurtas funkcinis regresijos paketas.

Susijęs:

• Ar „Test Automation“ turėtų atlikti atskira tam skirta komanda?
• Pliusai ir minusai apie bandomąją plėtrą

1. Tyrinėkite

Pirmiausia turite susipažinti su svetaine ir jos funkcijomis. Pradėkite nuo svetainės tyrinėjimo ir sužinokite jos elgesį. Tai darydami, jūs taip pat galite sukurti minčių žemėlapį apie svetainės struktūrą, kokius puslapius yra ir kokios funkcijos yra kiekviename puslapyje.

Minčių žemėlapiai yra puikus būdas gauti aukšto lygio vaizdą ir visos svetainės apžvalgą. Mes visada galime remtis minčių žemėlapiais, kad suprastume, kaip puslapiai yra susieti.

2. Surinkite metriką

Surinkite svetainės naudojimo metriką iš rinkodaros ir (arba) analizės komandos. Daugelis įmonių savo svetainėje įdeda „stebėjimo žymas“, tokias kaip „Google Analytics“, kad galėtų stebėti, kaip vartotojai naudojasi svetaine. Yra daug informacijos apie vartotojo elgseną ir įprasta vartotojų kelionės kuriuos galima gauti iš šių stebėjimo sistemų.

Priežastis, kodėl turime rinkti šią informaciją, yra ta, kad galėtume pirmiausia nustatyti prioritetus, kuriuos bandymo scenarijus pirmiausia automatizuoti, kad gautume didžiausią vertę per trumpiausią įmanomą laiką.

3. Pagrindiniai scenarijai

Pradėkite nuo pagrindinių „nuo galo iki pabaigos“ scenarijų automatizavimo per žiniatinklio programą. Tai bus mūsų „dūmų regresijos paketo“ pagrindas. Pvz., Tipinės el. Prekybos žiniatinklio programos pagrindinis scenarijus:

Pagrindinis puslapis -> Paieškos rezultatai -> Informacija apie produktą -> Kliento prisijungimas / registracija -> Mokėjimo duomenys -> Užsakymo patvirtinimas

Svarbu pažymėti, kad pirmiausia turime tik užtikrinti, kad mes galime pereiti per puslapius, pradedant nuo pagrindinio puslapio ir pasiekiant užsakymo patvirtinimo puslapį. Tikslas yra patikrinti, ar pirkimo srautas nėra suskaidytas, o ne išsamiai patikrinti kiekvieno puslapio funkcionalumą.

Kai turėsime paprasčiausią ir dažniausią naudotojų srautą, galėsime ieškoti daugiau variantų. Nepaisant daugybės funkcijų ir puslapių derinių, galima pastebėti, kad į sistemą reikia atkreipti dėmesį tik į keletą naudotojų kelionių.

Nagrinėdami analizės duomenis, tikriausiai pastebėsite, kad 80% vartotojų eitų tais pačiais keliais, bet turėtų skirtingus duomenis. Todėl mūsų dūmų regresijos paketas turėtų būti kuriamas remiantis šiais scenarijais.

4. Padidinkite aprėptį

Pastaba apie aprėptį, čia aš nekalbu apie bandymų aprėptį; dėmesys skiriamas funkcijų aprėptis .

Išplėskite dūmų regresijos paketą, kad sukurtumėte platesnį funkcijų regresijos paketą, naudodami minčių žemėlapius ir taikydami būsenos perėjimo testavimo metodiką scenarijams kurti.

Įėjimo taškai - Pirmiausia pirmiausia turime rasti įėjimo taškus į sistemą. Šie įėjimo taškai gali būti vartotojo nukreipimas į pagrindinį puslapį, išsamios informacijos apie gaminį puslapis arba SEM (paieškos sistemų rinkodara) konkretus puslapis.

Kai nustatome konkretų nukreipimo puslapį, turime pamatyti, kokios funkcijos yra tame puslapyje, su kuriomis vartotojas gali sąveikauti. Čia minčių žemėlapiai tampa labai naudingi. Turime aukšto lygio puslapio ir jo funkcijų apžvalgą.

Čia funkcijos reikšmė yra vienas komponentas, pvz., Išskleidžiamasis laukas rūšiuoti parinktį, arba užpildoma vartotojo informacijos forma, arba taip paprasta, kaip spustelėti nuorodą.

Pradinė būsena - Kai pirmą kartą nusileisime į įėjimo tašką programoje, bus būsena, susieta su tuo puslapiu. Mes tai įrašome kaip pradinę programos būseną. Kai tik sąveikaujame su bet kuria iš to puslapio funkcijų, greičiausiai pakeisime jo pradinę būseną.

Suaktyvinti - Kai kurios funkcijos, sąveikaujant, arba įkels tą patį puslapį (pvz., Rūšiavimo parinktys išlaikys tą patį puslapį, bet duomenys bus rūšiuojami), arba perėjimas į kitą puslapį (pvz., Pateikiant galiojančius vartotojo kredencialus). Dalykas, sukeliantis šį perėjimą į tą patį ar kitą puslapį, vadinamas aktyvikliu, pvz., Pateikimo mygtukas.

Teiginiai - Tada yra teiginiai. Kai tik keičiama programos būsena, sąveikaudami su funkcija, turime pateikti teiginius, kad patikrintume naujos būsenos būseną. Pavyzdžiui, kai pateikiame prisijungimo formą su galiojančiais vartotojo duomenimis, turime tvirtinti, kad vartotojas dabar yra prisijungęs.

Naują perėjimą galime tęsti tokiu pačiu būdu arba grįžti į pradinę būseną ir bendrauti su kita funkcija, kol apimsime visas svarbias minčių žemėlapių ypatybes.

Laikui bėgant, pasitikėjimo lygis diegiant naują kodą didėja, nes daugiau scenarijų yra automatizuojama ir vykdoma reguliariai.