Planul de testare Scrum minus este egal cu POC pe steroizi.
În zilele noastre, majoritatea proiectelor de succes încep cu un Proof of Concept (POC), o evaluare de dimensiuni relativ mici a unei idei, în care tehnologia și pachetul de caracteristici alese vor fi verificate mai întâi, evaluate pentru impactul potențial asupra utilizatorilor de afaceri și apoi, odată dovedite. demnă de investiție, o echipă de proiect de dimensiuni complete este desemnată să proiecteze și să livreze produsul cu funcții complete și să-l implementeze în producție.
Acesta este cazul perfect pentru o echipă Scrum. Echipa poate dezvolta rapid prototipul, adăugând noi funcții substanțiale la fiecare sprint, în timp ce utilizatorii de afaceri pot urmări în timp real progresul rapid și modul în care ideea este construită de la zero în doar aproximativ 10 sprinturi. Lasă o impresie puternică (care este, oricum, ținta principală a POC), dar are și o proprietate semnificativă – activități de testare minime sau deloc, și chiar și gândirea la procesul de testare ar fi o glumă.
Nu este o activitate distractivă în cadrul unei echipe Scrum, iar oamenilor le va plăcea cel mai mult ideea de a se dezvolta fără procese care să le încetinească. Aceasta este, practic, ceea ce orice activitate de testare va face implicit. Și cine își dorește încetineala inutilă în timpul în care trebuie să impresionăm cel mai mult utilizatorul final?
Starea care se întâmplă dacă echipa de proiect continuă în aceeași manieră după terminarea perioadei POC este ceva pe care îl folosesc pentru a numi POC pe steroizi – un sistem de producție care crește în dimensiune și caracteristici, dar care se comportă în continuare ca un POC – un produs complet care așteaptă defecte ascunse și carcase de colț neexplorate, așteaptă doar un accident grav.
Dar înainte de a se converti acolo, echipa va avea mai greu un timp de la sprint la sprint să țină pasul cu lansările stabile, deoarece rezolvarea problemelor de rulare va deveni doar mai complexă.
Iată câteva tehnici care s-au dovedit a funcționa atunci când am avut de-a face cu probleme similare și care cred că pot fi numite cele mai bune practici pentru implementarea proceselor solide de testare, fără a aglomera prea mult progresul dezvoltării – pentru că pentru asta ne dorim cu toții să fim o echipă Scrum.
Cuprins
Distribuiți durerea
De unde să începem când avem de-a face cu deranjamente inutile decât cu despărțirea durerii :).
Și ceea ce vreau să spun prin asta este crearea unui plan care va necesita o mică activitate suplimentară din partea dezvoltatorilor ici și colo, dar care va contribui foarte mult la ținta comună în timp, treptat, dar constant.
#1. Dezvoltați codul de test unitar pentru fiecare bucată de cod nou creată
Dacă reușiți să vă convingeți echipele scrum să adauge în clauza sa Definition Of Done dezvoltarea de teste unitare pentru fiecare cod nou creat în sprint, atunci dintr-o perspectivă pe termen lung, aceasta va fi o mare realizare.
Motivele sunt destul de evidente:
Va forța dezvoltatorii să se gândească la diferite căi non-standard ale codului. –
- Astfel de teste unitare pot fi conectate la conductele DevOps automatizate și executate cu fiecare implementare în mediul de dezvoltare sau de testare. De asemenea, valorile din conductă pot fi exportate cu ușurință și apoi utilizate pentru a demonstra utilizatorilor de afaceri acoperirea procentuală a cazurilor de testare direct legate de codul sursă.
Cel mai important este să începi foarte curând. Cu cât testele unitare vor începe să fie dezvoltate mai târziu, cu atât va deveni mai distragător pentru dezvoltatori să le adauge într-un sprint.
- Va fi nevoie de efort semnificativ pentru a dezvolta teste unitare pentru codul deja existent. Unele părți ale codului ar putea fi create de un alt dezvoltator, iar cunoștințele exacte despre cum ar trebui să funcționeze în fiecare parte a codului nu sunt tocmai clare pentru dezvoltatorul actual. În unele cazuri, se poate ajunge atât de departe încât adăugarea unui test unitar la codul modificat va dura mai mult timp decât dezvoltarea modificării caracteristicii pentru sprint (care este o stare pe care nimeni nu a calculat-o cu siguranță în timpul planificării sprintului).
#2. Faceți o rutină de executare a tuturor părților testelor unitare în mediul de dezvoltare
Chiar înainte de a crea o cerere de extragere pentru îmbinarea noului cod în ramura Master, va fi o activitate standard testarea atât a codului caracteristică, cât și a codului de testare unitară în mediul de dezvoltare. Procedând astfel, se va asigura că:
- Codul de test unitar funcționează de fapt pentru fiecare parte (în final, este doar un alt cod care trebuie verificat). Acest pas este foarte adesea sărit total. Se presupune cumva că, dacă testul unitar este oricum conectat la conducta DevOps, acesta va fi în cele din urmă executat și testat undeva în mod implicit. Cu toate acestea, aceasta nu este altceva decât împingerea problemelor la nivelurile superioare ale activităților de sprint, unde echipa are, de obicei, mai puțin timp și mai mult stres pentru a termina fiecare poveste angajată.
- Noul cod de caracteristică este testat de dezvoltator pentru funcționalitatea de bază. Evident, nu se poate aștepta de la acest test ca funcționalitatea afacerii să fie pe deplin verificată, dar cel puțin acest test va confirma că codul se comportă în modul în care l-a intenționat dezvoltatorul (ignorând, deocamdată, faptul că logica de business ar putea să fie înțeles greșit în timpul dezvoltării).
#3. Așteptați-vă execuția testului unitar după îmbinarea codului în ramura principală
Un lucru este să ai cod funcțional pe ramura locală (unde nimeni, în afară de proprietarul sucursalei, dezvoltă o nouă caracteristică), dar este un lucru complet diferit să ai același cod să funcționeze după cererea de extragere și să fuzionezi în ramura principală.
Ramura principală conține modificări de la alți membri ai echipei Scrum și, chiar dacă conflictele sunt rezolvate și totul arată bine, codul după îmbinare și rezolvarea conflictelor este, practic, încă o bucată de cod netestată și este riscant să o trimiteți mai departe fără a verifica mai întâi. inca functioneaza bine.
Deci, ceea ce s-a dovedit a fi eficient aici este doar solicitarea de a executa aceeași testare unitară – deja făcută anterior în mediul de dezvoltare – și pe mediu, care este construit din versiunea codului principal al ramurilor.
Pentru dezvoltatori, ar putea fi un pas suplimentar pe care trebuie să-l includă în viața lor, dar nu este un efort atât de mare, deoarece, în acest caz, nu trebuie inventat nimic nou – doar reexecută ceea ce a fost deja făcut o dată.
Acum, acest pas ar putea fi omis într-un anumit caz:
- Testele unitare automate din conductele DevOps sunt atât de cuprinzătoare încât acoperă deja întreaga testare manuală executată pe deasupra.
Deși atingerea acestei stări este cu siguranță fezabilă, nu am experimentat niciodată o astfel de stare în viața reală. Ar fi, probabil, chiar prea consumator de timp pentru dezvoltatori să creeze astfel de teste unitare automatizate atât de profund detaliate. Ar putea deveni ușor inacceptabil ca proprietarul produsului să lase echipa să dedice atât de mult timp acestei activități, deoarece ar avea un impact explicit asupra numărului de povești livrate într-un sprint.
Cu toate acestea, preferința pentru conținutul de sprint nu va fi niciodată o scuză pentru a nu face testele unitare sau chiar pentru a le minimiza. Făcând acest lucru, echipa se va converti din nou într-o astfel de stare, în care codul îi lipsește o acoperire prea mare a testului unitar, iar apoi, pentru o recuperare, ar putea fi deja prea târziu (din nou, efortul mai mare pentru finalizarea testului unitar decât cel real). schimbarea codului pentru un sprint).
Din toate aceste motive, aș recomanda reexecuția testelor unitare pe versiunea de cod master fără ezitare. Este un efort atât de mic în comparație cu ce valoare va aduce.
Acesta va efectua verificarea finală pentru pregătirea ramului principal pentru faza de testare a lansării. De asemenea, va ajuta să găsiți majoritatea erorilor tehnice (de exemplu, erori care împiedică executarea cu succes a codului sursă până la finalul cu succes), lăsând pentru următoarea fază să se concentreze exclusiv pe verificarea funcționalității afacerii.
Pregătiți-vă pentru testarea funcțională
Toate activitățile anterioare de testare vor duce la o concluzie specifică – codul de ramură principal este lipsit de erori tehnice și poate fi executat fără probleme pentru fluxurile funcționale end-to-end.
Aceasta este o fază care poate fi parcursă cu ușurință doar de o singură persoană, iar această persoană nici măcar nu are nevoie să aibă cunoștințe tehnice.
De fapt, este mult mai bine dacă acest lucru este executat de cineva deconectat de la dezvoltatori, dar cu conștientizare funcțională a modului în care utilizatorii de afaceri se așteaptă ca codul să se comporte. Există două activități principale de realizat:
#1. Noile povești de sprint, testate funcționale vizate
În mod ideal, fiecare sprint ar trebui să aducă o nouă funcționalitate (creșterea obiectivului de sprint) care anterior era inexistentă și astfel va fi verificată. Este important să ne asigurăm că noua bucată de software funcționează într-o asemenea măsură încât utilizatorii de afaceri sunt fericiți să o aibă acum, deoarece, evident, așteptau cu nerăbdare să o aibă cel puțin tot ultimul sprint :).
Este o experiență atât de tristă când funcționalitatea (de mult timp) promisă este în sfârșit anunțată a fi lansată, doar pentru a afla zilele trecute că de fapt nu funcționează bine.
Prin urmare, testarea corectă a noii funcționalități de sprint este crucială. Pentru ca acest lucru să devină un succes, este o bună practică să adunați în prealabil cazuri de testare importante și de la părțile interesate relevante (fie de la proprietarul produsului, fie chiar de la utilizatorii finali) și să faceți o listă cu toate astfel de cazuri de testare necesare pentru conținutul din interior. sprintul.
Acest lucru ar putea părea copleșitor la prima vedere, dar din experiența mea, este din nou complet gestionabil de o singură persoană. Deoarece sprinturile sunt de cele mai multe ori destul de scurte (cum ar fi o perioadă scurtă de două săptămâni), oricum nu este aproape niciodată prea mult conținut nou, deoarece sprintul conține, de asemenea, activități suplimentare, cum ar fi poveștile de datorii tehnice, documentația, povestirile de design/spike etc.
Cazurile de testare sunt apoi executate cu scopul de a verifica în primul rând funcționalitatea dorită. Dacă apare vreo problemă cu rezultatele, este abordat doar dezvoltatorul relevant (cel care deține modificările legate de acest defect special) pentru a rezolva problema rapid.
În acest fel, dezvoltatorii vor petrece timp minim conectat la testarea funcțională și se pot concentra în continuare pe activitățile care le plac cel mai mult.
#2. Executarea cazurilor de testare de regresie
Cealaltă parte a testării funcționale va fi să se asigure că tot ceea ce a funcționat până acum va funcționa și după următoarea lansare. Pentru asta sunt testele de regresie.
Cazurile de testare pentru testele de regresie sunt cele mai bune dacă sunt întreținute și revizuite în mod regulat înainte de fiecare lansare. Pe baza specificului concret al proiectului, cel mai bine este să le păstrați simple, dar să acoperiți majoritatea funcționalităților de bază și a fluxurilor importante end-to-end care traversează întregul sistem.
De obicei, fiecare sistem are astfel de procese care ating multe domenii diferite, acestea fiind cei mai buni candidați pentru cazurile de testare de regresie.
În unele cazuri, testele de regresie acoperă implicit și caracteristici noi în sprint, de exemplu, dacă noua poveste din sprint modifică o anumită parte a fluxului existent.
Deci, în majoritatea cazurilor, nu este deloc foarte complex să finalizați teste de regresie împreună cu testele de funcționalitate a noilor povești de sprint, mai ales dacă acest lucru se face în mod regulat înainte de fiecare lansare de producție, iar periodicitatea lansărilor de producție nu este prea mică.
Insistați să executați teste de asigurare a calității înainte de fiecare lansare de producție
Testul de asigurare a calității (QA) este pasul final înainte de lansarea în producție și adesea acest test este omis ca neimportant. Mai ales dacă echipa scrum este gestionată agresiv pentru conținut nou.
Chiar și utilizatorii de afaceri vor spune că sunt interesați de noi funcții și nu atât de păstrarea funcționalității sau de menținerea scăzută a numărului de defecte. Dar din nou – în timp, acesta este motivul principal pentru care echipa de dezvoltare va trebui să încetinească în cele din urmă, iar apoi utilizatorii de afaceri nu vor primi oricum ceea ce cer.
Testul QA va fi executat numai de către oamenii din afara echipei Scrum, în mod ideal de către utilizatorii de afaceri înșiși într-un mediu dedicat, care este cât mai aproape posibil de producția viitoare. Alternativ, proprietarul produsului poate înlocui aici utilizatorii finali.
În orice caz, acesta ar trebui să fie un test curat, funcțional din perspectiva utilizatorului final, fără nicio legătură cu echipa dev Scrum. Va prezenta o vedere finală a produsului și va fi folosit într-un mod posibil pe care nimeni din echipa Scrum nu a anticipat (deloc un caz ideal, dar cu siguranță se poate întâmpla). Mai este timp pentru corecții de ultim moment.
Alternativ, ar putea deveni clar că așteptările nu au fost bine înțelese de echipa scrum și, în acest caz, cel puțin putem conveni asupra unui plan de urmărire, încă cu mult înainte de lansarea reală a producției. Acesta nu este, din nou, un caz ideal, dar totuși mult mai bine ca să admitem eșecul imediat după raportarea unei lansări de producție de succes.
Unde să merg mai departe de aici?
Aplicarea acestor practici la munca zilnică de scrum vă poate aduce în mod serios la obiceiuri de lansare în sprint mai stabile și previzibile, fără a întârzia lansările de producție sau fără a petrece întregul sprint doar pregătindu-se pentru următoarea lansare, sau chiar fără a forța pe toți cei din echipa scrum să facă ceva ce nu fac. Nu prea îmi place sau nu știu cum să faci oricum eficient pentru majoritatea sprintului, adică.
Dar cu siguranță nu trebuie să te oprești aici.
Includerea testului de performanță este un subiect de numit aici. Acestea sunt adesea ignorate sau considerate inutile, răzbândind în prima rundă de „optimizare a activităților Scrum”. Totuși, am avut mereu îndoieli cu privire la modul în care se poate aștepta ca sistemul de producție să evolueze în timp dacă nu este verificat în mod regulat pentru performanță.
Mersul cu un nivel mai sus înseamnă și introducerea de teste automate.
Am acoperit deja un grup de teste automate (teste unitare în curs). Cu toate acestea, puteți dezvolta teste complete de regresie end-to-end complet automatizate și executate singuri după fiecare implementare în mediul de testare. Acest lucru ar elibera și mai mult echipa de dezvoltare scrum, dar este nevoie de o echipă dedicată pentru a dezvolta și menține astfel de teste automate. Ar deveni o muncă constantă, deoarece de fiecare dată când codul de producție se schimbă, unele teste automate existente pot deveni invalide și, prin urmare, trebuie actualizate pentru a continua să lucreze în curs de dezvoltare. Este un efort pentru care doar câțiva sunt dispuși să plătească, beneficiile pentru echipa dev scrum ar fi, totuși, grozave.
Acestea sunt subiecte care depășesc cu mult domeniul de aplicare al acestui articol și găsesc programul și calendarul potrivit pentru fiecare tip de test menționat aici – astfel încât să puteți ajunge într-o fereastră de sprint. Voi fi bucuros să mă scufund data viitoare!