Pagrindinis Judrus Kaip nustatyti kokybės užtikrinimo funkciją nuo nulio

Kaip nustatyti kokybės užtikrinimo funkciją nuo nulio

Tai yra įprastas scenarijus: pradedančioji įmonė turi naują idėją ir pasamdo daugybę kūrėjų, kad sukurtų veikiantį idėjos modelį.

Dėl startuolių pobūdžio, ty, kad idėjai plėtoti per mažai laiko skiriama nedaug lėšų, pagrindinės pastangos yra sutelktos kuriant naują produktą, kad jis būtų viešas, kad išbandytų vandenis, ir, savaime suprantama, bandymai. ir kokybės užtikrinimas nėra pagrindinis kūrėjų komandos prioritetas.

Po to, kai paaiškėja, kad idėja pasisekė, įmonė nori išplėsti idėją ir pradėti samdyti daugiau kūrėjų, tačiau tuo pačiu metu jie taip pat nori, kad produktas būtų išbandytas prieš pasirodant viešai.

Kurį laiką bandymus atlieka tas, kas yra įmonėje, ir tai daugiausia yra ad hoc, be tinkamų procesų.

Tada ateina momentas, kai startuolių įmonė nusprendžia pasamdyti savo pirmąjį vyresnįjį kokybės užtikrinimo specialistą, kad jis pradėtų įgyvendinti naują kokybės užtikrinimo procesą kūrėjų komandai.

Šiame straipsnyje manysiu, kad startuolis yra internetinė įmonė, pvz. elektroninės prekybos svetainę.

Kokybės kokybės proceso įgyvendinimas

Pagrindinis kokybės užtikrinimo proceso tikslas yra užtikrinti, kad tinkamas produktas būtų pagamintas teisingai, pirmą kartą. Tai reiškia, kad prieš pradėdami koduoti, turime užtikrinti, kad reikalavimai būtų tinkamai apibrėžti ir kūrėjų komanda gerai suprastų naujų funkcijų funkcionalumą.

Svarbu pažymėti, kad testavimas nėra etapas, tai yra veikla ir kad testavimas prasideda nuo pat kūrimo pradžios, nuo tada, kai rašomos vartotojo istorijos.

Testavimas turėtų palaikyti plėtrą, todėl testavimo veikla yra lygiagreti kūrimo veiklai, ir kiekviename kūrimo proceso etape turime užtikrinti, kad kodas būtų kruopščiai išbandytas.

Prieš diegdami testavimo procesą, turime žinoti dabartinę kūrimo metodiką ir procesą bei prireikus atlikti pakeitimus, kad patobulintume procesą.

Regresijos testavimas / Sprinto testavimas

Kai pradedate būti pirmuoju kokybės užtikrinimo asmeniu įmonėje, yra tikimybė, kad nėra regresijos testavimo, todėl, kai kuriamos naujos funkcijos, jūs neįsivaizduojate, ar jie neigiamai veikia dabartinę veikiančią svetainę. Be to, turite neatsilikti nuo kūrėjų komandos, kad išbandytumėte naujas funkcijas ir įsitikintumėte, jog jos veikia tinkamai ir pagal specifikacijas.

Lygiagrečiai yra bent dvi užduotys: Naujų istorijų testavimas sprinte ir tam tikro laipsnio regresijos testavimas.

Naujų funkcijų testavimui teikiama pirmenybė, nes yra didesnė tikimybė rasti klaidų naujame kode nei sulaužyti dabartinę darbo vietą. Tačiau tuo pačiu metu reikalingas regresijos testavimas, siekiant užtikrinti, kad esama programa ir toliau veiktų kuriant naujas funkcijas.

Regresijos testavimo paketą reikia paleisti iš karto, kai tik atnaujinama programa, kad kūrimo komanda galėtų jį gauti greitas grįžtamasis ryšys dėl paraiškos sveikatos.

Nėra pakankamai laiko parašyti regresijos testus, taip pat neatsilikti nuo naujų funkcijų testavimo. Kaip mes galime nutraukti šį ciklą?

Paprastai pirmosiomis sprinto dienomis kūrėjai užima kodavimą, todėl naujos funkcijos kurį laiką nebus paruoštos išbandyti. Tai gera proga pradėti dirbti su regresijos testais.

Yra geriausios regresijos bandymų praktikos, tačiau paprastai reikėtų nustatyti pagrindines pagrindines vartotojo keliones visoje svetainėje, kad kiekviename naujame svetainės leidime galėtume būti tikri, kad programą vis dar gali naudoti dauguma jos narių. vartotojų.

Nereikia pateikti išsamaus šių scenarijų sąrašo, tiesiog pakaks pagrindinių ir svarbiausių, kad būtų galima paleisti nedidelį regresijos paketą, kurį galima vykdyti kiekviename kūrinyje. Vėliau, bręstant regresijos paketui, galime pradėti pridėti daugiau scenarijų.

Svarbiausia, kad šie regresijos scenarijai turėtų būti automatizuoti.

Automatizuotas testavimas

Vikriame projekte, kur sprintas paprastai trunka apie dvi savaites, nėra pakankamai laiko atlikti visus bandymus rankiniu būdu. Yra ir naujų istorijų, ir regresijos bandymai. Nors prasminga atlikti tiriamuosius bandymus norint išbandyti naujas funkcijas, regresijos testai turėtų būti automatizuoti, kad būtų sumažinta kasdienė užduotis pakartotinai atlikti tuos pačius testus rankiniu būdu.

Dujotiekio diegimas / kūrimas

Diegimas arba statybos vamzdynas pagal judrų projektą apibrėžia, kaip istorija patenka iš produktų nepilnos į tiesioginę gamybos vietą. Jis apibrėžia procesą ir veiksmus, kurie vyksta kiekviename etape.

Norint įgyvendinti sėkmingą kokybės užtikrinimo procesą, užtikrinantį, kad dažnai išleidžiame kokybės kodą, visi suinteresuotieji subjektai turi apibrėžti diegimo planą ir jo laikytis. Diegimo vamzdynas yra programinės įrangos pristatymo stuburas.

Vamzdynas turėtų būti pagrįstas geriausia patirtimi ir apimti kiekviename etape vykdomą veiklą.

Istorijos dirbtuvės

Viena iš svarbiausių veiklaus projekto veiklų yra dažnai pasakojimų dirbtuvės. Tai yra, kai produkto savininkas, kūrėjai ir bandytojai susirenka į kambarį ir pradeda rengti bei išdėstyti istorijų detales. Tai svarbu, nes visi, prieš pradėdami kūrimo darbus, turėtų vienodai suprasti istoriją.

Kokybės užtikrinimas yra susijęs su defektų prevencija, o ne su aptikimu, todėl pasakojimų dirbtuvėse komanda gauna galimybę užduoti klausimus apie istorijos detales, visus techninius ar dizaino apribojimus ir bet kokius blokatorius, trukdančius kurti istorijas.

Tai puiki proga pradėti rašyti istorijų priėmimo kriterijus. Kiekvienas turėtų prisidėti ir pradėti galvoti apie galimus kiekvienos istorijos scenarijus, nes kiekvienas turės skirtingą idėją, todėl kuo daugiau pasakojimų apie galvą, tuo daugiau scenarijų galima sugalvoti ir didesnė tikimybė užkirsti kelią defektų atsiradimui.

Kai visi yra tikri dėl kiekvienos istorijos detalių ir apimties, prasideda kūrimas.

Kūrėjo testavimas / testavimas kūrimo metu

Už produkto kokybę turėtų atsakyti visi, o ne tik bandytojai. Prieš diegiant bandymų aplinką tolimesniam bandymui, turi būti pakankamai „kūrėjo bandymų“, kad būtų užtikrinta, jog parašytas kodas yra aukštos kokybės.

Be abejo, kiekvienas naujas funkcionalumas turėtų būti gerai išbandytas. Be to, reikia atlikti integravimo, API ir UI testus.

Kolegų kodų apžvalgos ar „bičiulių testavimas“ gali antrą kartą atkreipti dėmesį į kūrėjo darbą. Testuotojas gali padėti peržiūrėti vieneto testus ir API testus, kad įsitikintų, jog buvo parašyti teisingi testai, taip pat padėti parašyti aukšto lygio automatizuotus vartotojo sąsajos testus.

Nuolatinė integravimo / bandymo aplinka

Norėdami efektyviai išbandyti naujas funkcijas, turime užtikrinti, kad kodas veiktų ne tik kūrėjo mašinoje, bet ir kitose aplinkose bei būtų integruotas su kitu kūrėjo kodu.

Nuolatinė integracija padeda identifikuoti bet kokias sukūrimo problemas proceso pradžioje, kad nepavykus diegti galėtume pradėti ieškoti, iš kur kyla problema.

Testavimo aplinka suteikia testuotojams ir kitiems komandos nariams galimybę išbandyti naujas funkcijas prieš pradedant gyventi.

Nefunkcinis testavimas

Kai reikia, taip pat turėtume atlikti nefunkcinius bandymus, tokius kaip našumo, apkrovos ir saugumo testai. Dažnai daugiausia dėmesio skiriama tam, kad funkcionalumas gerai veiktų, tačiau nefunkciniams bandymams turėtų būti teikiamas tas pats prioritetas, ypač žiniatinklio programoms, nes joms gali būti padaryta didelė apkrova ir (arba) atakos.

Atlikdami nefunkcinius bandymus, galime būti tikri, kad mūsų programa gali atlaikyti apkrovą piko metu ir kad tai nėra grėsmė saugumui.