Primjer predloška strategije agilnog testiranja

Agilna strategija ispitivanja

U agilnom okruženju, gdje radimo u kratkim sprintima ili ponavljanjima, svaki je sprint usredotočen na samo nekoliko zahtjeva ili korisničkih priča, pa je prirodno da dokumentacija možda nije toliko opsežna, kako u pogledu broja, tako i u pogledu sadržaja.

Svrha dokumenta agilne strategije testiranja je navođenje najboljih praksi i nekih oblika strukture koje timovi mogu slijediti. Zapamtite, okretan ne znači nestrukturiran.

Ovdje ćemo pogledati primjer strategije agilnog testiranja i što sve uključiti u dokument.

Test strategija obično ima izjavu o misiji koja bi se mogla povezati sa širim poslovnim ciljevima.

Tipična izjava o misiji može biti:

Neprestano isporučivati ​​radni softver koji ispunjava zahtjeve kupca _ pružanjem brze povratne informacije _ i _prevencijom nedostataka, umjesto otkrivanjem nedostataka.



Podržan od:


  • Nijedan kôd ne smije biti napisan za priču dok prvo ne definiramo kriterije / testove prihvaćanja

  • Priča se ne može smatrati cjelovitom dok ne prođu svi testovi prihvaćanja

U dokumentu Strategije agilnog testiranja, također bih uključio podsjetnik svima o osiguranju kvalitete


  • QA je skup aktivnosti kojima se želi osigurati da proizvodi zadovoljavaju zahtjeve kupaca na sustavan, pouzdan način.


  • U SCRUM-u (agilnom) QA je odgovornost svih, a ne samo testera. QA je sve aktivnosti koje radimo kako bismo osigurali ispravnu kvalitetu tijekom razvoja novih proizvoda.

Razine ispitivanja

Jedinstveno ispitivanje

ZAŠTO: Kako bi se osiguralo da se kod pravilno razvija

WHO: Programeri / tehnički arhitekti

ŠTO: Sav novi kôd + preračunavanje starog koda kao i Javascript testiranje jedinica

KADA: Čim se napiše novi kod

GDJE: Lokalni Dev + CI (dio gradnje)

KAKO: Automatizirano, Junit, TestNG, PHPUnit

API / servisno testiranje

ZAŠTO: Kako bi se osiguralo da komunikacija između komponenata funkcionira

WHO: Programeri / tehnički arhitekti

ŠTO: Nove web usluge, komponente, kontroleri, itd

KADA: Čim se razvije novi API i spremi

GDJE: Lokalni Dev + CI (dio gradnje)

KAKO: Automatizirano, korisničko sučelje sapuna, klijent za odmor

Ispitivanje prihvaćanja

ZAŠTO: Kako bi se osiguralo da se ispune očekivanja kupca

WHO: Developer / SDET / Manual QA

ŠTO: Potvrđivanje testova prihvaćanja priča, provjera značajki

KADA: Kada je značajka spremna i jedinica testirana

GDJE: CI / Test okruženje

KAKO: Automatizirano (krastavac)

Ispitivanje sustava / Ispitivanje regresije / UAT

ZAŠTO: Kako bi se osiguralo da cijeli sustav radi kada je integriran

WHO: SDET / Manual QA / Poslovni analitičar / Vlasnik proizvoda

ŠTO: Testiranje scenarija, protok korisnika i tipična putovanja korisnika, testiranje performansi i sigurnosti

KADA: Kada se završi ispitivanje prihvatljivosti

GDJE: Scensko okruženje

KAKO: Automatizirano (Webdriver) istraživačko ispitivanje

Zaostatak proizvoda

Najčešći uzrok neuspjeha u razvoju softvera je zbog nejasnih zahtjeva i različitog tumačenja zahtjeva različitih članova tima.

Priče korisnika trebaju biti jednostavne, kratke i jednoznačne. Kao dobra smjernica, najbolje je slijediti INVEST model za pisanje korisničkih priča.

Dobra korisnička priča trebala bi biti:

Ja neovisno (od svih ostalih)

N pogodljiv (nije poseban ugovor za značajke)

V aluable (ili vertikalni )

JE stimable (u dobru aproksimaciju)

S tržni centar (kako bi se uklopio u iteraciju)

T estable (u principu, čak i ako za to još nema testa)

Sljedeći format trebao bi se koristiti za pisanje korisničkih priča

As a [role] I want [feature] So that [benefit]

Važno je ne zaboraviti dio 'Benefit', jer bi svi trebali biti svjesni koju vrijednost dodaju razvojem priče.

Kriteriji prihvatljivosti

Svaka od korisničkih priča mora sadržavati kriterije prihvaćanja. Ovo je možda najvažniji element koji potiče komunikaciju s različitim članovima tima.

Kriteriji prihvaćanja trebaju biti napisani u isto vrijeme kada se kreira korisnička priča i trebaju biti ugrađeni u tijelo priče. Svi kriteriji prihvatljivosti trebaju biti provjerljivi.

Svaki kriterij prihvaćanja trebao bi imati niz testova prihvatljivosti predstavljenih kao scenariji napisani u Gherkin formatu, npr.

Scenario 1: Title Given [context] And [some more context]... When  [event] Then  [outcome] And [another outcome]...

Story radionice / planiranje sprinta

U svakoj radionici priča svi u timu uče o detaljima priča kako bi programeri i QA znali opseg posla. Svi bi trebali imati isto razumijevanje o čemu se priča.

Programeri bi trebali dobro razumjeti tehničke detalje koji su uključeni u isporuku priče, a QA bi trebao znati kako će se priča testirati i postoje li prepreke za testiranje priča.

Sprječavanje nedostataka

Na radionicama priča, PO, BA, Dev i QA moraju biti uključeni.

Treba razmisliti o scenarijima (valjani, nevaljani i rubni slučajevi) (QA ovdje može dodati veliku vrijednost apstraktnim razmišljanjem o priči) i zapisati ih u značajke datoteka.

Važno je napomenuti da će scenariji (više od svega ostalog) otkriti nedostatke prilikom testiranja proizvoda, pa što je više truda i vremena utrošenog na ovu aktivnost, na kraju će se postići najbolji rezultati.

Budući da je većina nedostataka posljedica nejasnih i nejasnih zahtjeva, ova će aktivnost također pomoći u sprječavanju provođenja neispravnog ponašanja jer bi svi trebali imati isto razumijevanje priče.

Isto tako, na sastancima za planiranje sprinta, procjene dane za priču trebale bi uključivati ​​i napor testiranja, a ne samo napor kodiranja. QA (priručnik i automatizacija) također moraju biti prisutni na sastancima za planiranje sprinta kako bi se dala procjena za testiranje priče.

Razvoj

Kad razvoj započne, novi proizvodni kôd i / ili preinaka starog koda trebali bi podržati jedinični testovi koje su napisali programeri i recenzirao ih je drugi programer ili kvalificirani SDET.

Svako predavanje spremištu koda trebalo bi pokrenuti izvršavanje jediničnih testova s ​​CI poslužitelja. Ovo pruža brzi mehanizam povratnih informacija razvojnom timu.

Jedinstveni testovi osiguravaju da sustav radi na tehničkoj razini i da nema pogrešaka u logici.

Ispitivanje programera

Kao programer ponašajte se kao da nemate provjeru kvalitete u timu ili organizaciji. Istina je da QA imaju različito razmišljanje, ali trebali biste testirati najbolje što znate.

Mislite da štedite vrijeme brzim prijelazom na sljedeću priču, ali u stvarnosti, kad se pronađe i prijavi kvar, treba više vremena da se ispravi problem, nego potrošiti nekoliko minuta osiguravajući da značajka radi dobro.

Bilo koji novi kôd i / ili refaktoriranje starog koda trebali bi imati odgovarajuće jedinice testove koji će biti dio jedinice regresijskog testa.

Automatizirani testovi prihvaćanja i nefunkcionalno ispitivanje

Automatizirani testovi prihvaćanja uključuju testove integracije i servisne testove te testove korisničkog sučelja kojima se želi dokazati da softver radi na funkcionalnoj razini i da udovoljava korisničkim zahtjevima i specifikacijama.

Automatizirani testovi prihvaćanja obično su napisani na kornišonskom jeziku i provode se pomoću BDD alata kao što je krastavac.

Zapamtiti : Ne moraju sva ispitivanja biti automatizirana!

Budući da ti testovi obično zahtijevaju komunikaciju preko HTTP, oni se trebaju izvršiti na postavljenoj aplikaciji, a ne izvoditi se kao dio gradnje.

Nefunkcionalni testovi kao što su testovi performansi i sigurnosti jednako su važni kao i funkcionalni testovi, stoga ih je potrebno izvršiti pri svakom postavljanju.

Testovi performansi trebali bi provjeravati mjerne podatke izvedbe na svakom postavljanju kako se ne bi pogoršale performanse.

Sigurnosni testovi trebali bi provjeriti postoje li osnovne sigurnosne ranjivosti izvedene iz OWASP

Od vitalne je važnosti da ovo bude potpuno automatiziran postupak s vrlo malo održavanja kako bi se od automatiziranih implementacija izvukla najveća korist. To znači da ne smije biti povremenih neuspjeha u testiranju, problema sa skriptom za testiranje i oštećenog okruženja.

Kvarovi bi trebali nastati samo zbog izvornih nedostataka koda, a ne zbog problema sa skriptom, pa bi svaki test neuspjeha koji nije posljedica istinskih kvarova trebalo odmah popraviti ili ukloniti iz paketa automatizacije kako bi se mogli dobiti dosljedni rezultati.

Ispitivanje regresije

Ne očekujući da ću pronaći mnoge nedostatke. Njihova je svrha samo pružiti povratne informacije da nismo pokvarili glavnu funkcionalnost. Trebalo bi postojati vrlo malo ručnog regresijskog ispitivanja.

Paket dima - ne smije biti duži od 15 minuta

Ovaj paket sadrži samo visoku razinu funkcionalnosti kako bi se osiguralo da je aplikacija dovoljno stabilna za daljnji razvoj ili testiranje.

Na primjer, za web mjesto e-trgovine testovi uključeni u ovaj paket mogu biti:

  • Pretraživanje proizvoda,
  • Pregled proizvoda
  • Predmet kupnje
  • Stvaranje računa / Prijava računa

Kompletni regresijski paket - trebao bi trajati najviše 1 sat

Ovaj paket sadrži puni regresijski niz testova i sadrži sve ostalo što nije uključeno u dimni paket.

Ovdje je cilj dobiti brzu povratnu informaciju s većim nizom testova. Ako povratne informacije traju više od 1 sata, nisu brze. Ili smanjite broj testova tehnikom uparenih testova, stvorite pakete testova na temelju rizika ili paralelno pokrenite testove.

UAT i istražna ispitivanja

Nema razloga zašto UAT i istraživačka ispitivanja ne mogu raditi paralelno s automatiziranim testovima prihvaćanja. Napokon, to su različite aktivnosti i cilj im je pronaći drugačija pitanja. Cilj UAT-a je osigurati da razvijene značajke imaju poslovnog smisla i korisne za kupce.

PO (vlasnik proizvoda) treba pokrenuti testove prihvaćanja korisnika ili testovi poslovnog prihvaćanja kako bi se potvrdilo da je ugrađeni proizvod ono što se očekivalo i da ispunjava očekivanja korisnika.

Eksploracijsko testiranje trebalo bi se usredotočiti na korisničke scenarije i otkriti greške koje automatizacija propušta. Istraživačko testiranje ne bi trebalo pronaći trivijalne greške, već bi trebalo naći suptilne probleme.

Gotovi kriteriji

Jednom kada su sve gore navedene aktivnosti dovršene i nisu pronađeni problemi, priča je takva Gotovo!

Gore su navedene neke smjernice o tome što se može uključiti u dokument Agile Test Strategy Strategy. Očito je da ovo treba prilagoditi potrebama vaše organizacije, ali nadamo se da će vam ovaj predložak pomoći u stvaranju vlastitog dokumenta Agile Test Strategy.