Ce este testarea agilă?
TESTAREA AGILE este o practică de testare care respectă regulile și principiile dezvoltării software-ului agil. Spre deosebire de metoda Waterfall, Testarea Agilă poate începe la începutul proiectului cu integrare continuă între dezvoltare și testare. Metodologia Agile Testing nu este secvențială (în sensul că este executată doar după faza de codificare), ci continuă.
În acest articol, vom discuta
- Planul de testare agilă.
- Strategii de testare agile.
- Cadrantul de testare agilă.
- Provocări QA cu dezvoltarea software-ului agil.
- Risc de automatizare în procesul agil.
Planul de testare agilă
Planul de testare agilă include tipuri de testare efectuate în această iterație, cum ar fi cerințele de date de testare, infrastructură, medii de testare și rezultate ale testelor. Spre deosebire de modelul cascadă, într-un model agil, un plan de testare este scris și actualizat pentru fiecare versiune. Planurile de testare tipice în agile includ
- Domeniul de testare
- Funcționalități noi care sunt testate
- Nivelul sau tipurile de testare bazate pe complexitatea caracteristicilor
- Testarea sarcinii și a performanței
- Considerare a infrastructurii
- Plan de atenuare sau riscuri
- Resurse
- Livrabile și repere
Strategii de testare agile
Ciclul de viață al testelor agile se întinde pe patru etape
(a) Iterarea 0
În prima etapă sau iterația 0, efectuați sarcini inițiale de configurare. Include identificarea persoanelor pentru testare, instalarea instrumentelor de testare, programarea resurselor (laborator de testare a utilizabilității), etc. Următorii pași sunt setați pentru a realiza în Iterarea 0
a) Stabilirea unui caz de afaceri pentru proiect
b) Stabiliți condițiile limită și domeniul de aplicare al proiectului
c) Descrieți cerințele cheie și cazurile de utilizare care vor conduce la compromisurile de proiectare
d) Descrieți una sau mai multe arhitecturi candidate
e) Identificarea riscului
f) Estimarea costurilor și pregătirea unui proiect preliminar
(b) Ierații în construcții
A doua fază a metodologiei de testare agilă este Iterări de construcții, majoritatea testelor au loc în această fază. Această fază este observată ca un set de iterații pentru a construi o creștere a soluției. Pentru a face acest lucru, în cadrul fiecărei iterații, echipa implementează un hibrid de practici din XP, Scrum, modelare Agile și date agile și așa mai departe.
În iterația de construcție, echipa agilă urmează practica de cerință prioritară: cu fiecare iterație, iau cele mai esențiale cerințe rămase din stiva de articole de lucru și le implementează.
Iterația de construcție este clasificată în două, teste de confirmare și teste de investigație. Testarea confirmatorie se concentrează pe verificarea faptului că sistemul îndeplinește intenția părților interesate, așa cum a fost descris echipei până în prezent, și este efectuat de către echipă. În timp ce testele de investigație detectează problema pe care echipa de confirmare a omis-o sau a ignorat-o. În testele de investigație, testerul determină problemele potențiale sub forma unor povești cu defecte. Testarea de investigație se ocupă de probleme comune, cum ar fi testarea integrării, testarea sarcinii / stresului și testarea securității.
Din nou, pentru testarea confirmativă există două aspecte testarea dezvoltatorului și testarea agilă de acceptare . Ambele sunt automatizate pentru a permite testarea continuă de regresie pe tot parcursul ciclului de viață. Testarea confirmativă este echivalentul agil al testării la specificație.
Testarea de acceptare agilă este o combinație de testare funcțională tradițională și testare de acceptare tradițională ca echipă de dezvoltare, iar părțile interesate o fac împreună. În timp ce testarea pentru dezvoltatori este un amestec de testare unitară tradițională și testare tradițională de integrare a serviciilor. Testarea dezvoltatorului verifică atât codul aplicației, cât și schema bazei de date.
(c) Eliberați sfârșitul jocului sau faza de tranziție
Obiectivul „Release, End Game” este să vă implementați sistemul cu succes în producție. Activitățile incluse în această fază sunt formarea utilizatorilor finali, oameni de sprijin și oameni operaționali. De asemenea, include comercializarea lansării produsului, backup și restaurare, finalizarea sistemului și documentația utilizatorului.
Etapa finală de testare a metodologiei agile include testarea completă a sistemului și testarea acceptării. Pentru a finaliza ultima etapă de testare fără obstacole, ar trebui să testați produsul mai riguros în timp ce se află în iterații de construcție. În timpul jocului final, testerii vor lucra la poveștile cu defecte.
(d) Producție
După etapa de lansare, produsul va trece la etapa de producție.
Cadranții de testare agili
Cadranțele de testare agile separă întregul proces în patru Cadrante și ajută la înțelegerea modului în care se efectuează testarea agilă.
a) Agile Quadrant I - Calitatea codului intern este principalul accent în acest quadrant și constă din cazuri de test care sunt bazate pe tehnologie și sunt implementate pentru a sprijini echipa, include
1. Teste de unitate
2. Teste de componente
b) Agile Quadrant II - Conține cazuri de test care sunt orientate spre afaceri și sunt implementate pentru a sprijini echipa. Acest cadran se concentrează pe cerințe. Tipul de test efectuat în această fază este
1. Testarea exemplelor de scenarii și fluxuri de lucru posibile
2. Testarea experienței utilizatorului, cum ar fi prototipurile
3. Testarea perechii
c) Quadrantul Agil III - Acest cadran oferă feedback cadranelor unu și doi. Cazurile de testare pot fi utilizate ca bază pentru efectuarea testelor de automatizare. În acest cadran, se efectuează multe runde de recenzii de iterații care creează încredere în produs. Tipul de testare făcut în acest cadran este
1. Testarea utilizabilității
2. Testarea exploratorie
3. Testează perechea cu clienții
4. Testarea colaborativă
5. Testarea acceptării utilizatorului
d) Agile Quadrant IV - Acest cadran se concentrează pe cerințele nefuncționale, cum ar fi performanța, securitatea, stabilitatea etc. Cu ajutorul acestui cadran, aplicația este realizată pentru a oferi calitățile nefuncționale și valoarea așteptată.
1. Teste nefuncționale precum testarea stresului și a performanței
2. Testarea securității cu privire la autentificare și hacking
3. Testarea infrastructurii
4. Testarea migrării datelor
5. Testarea scalabilității
6. Testarea sarcinii
Provocări QA cu dezvoltarea software-ului agil
a) Șansele de eroare sunt mai agile, deoarece documentația are o prioritate mai mică, în cele din urmă pune mai multă presiune pe echipa de asigurare a calității
b) Funcțiile noi sunt introduse rapid, ceea ce reduce timpul disponibil pentru echipele de testare pentru a identifica dacă cele mai recente caracteristici sunt în conformitate cu cerința și se adresează cu adevărat suitelor de afaceri
c) Testerii sunt deseori obligați să joace un rol semi-dezvoltator
d) Ciclurile de execuție ale testelor sunt foarte comprimate
e) Foarte puțin timp pentru pregătirea planului de testare
f) Pentru testarea de regresie, acestea vor avea un timp minim
g) Schimbarea rolului lor de la a fi un purtător al calității la a fi partener în calitate
h) Modificările cerințelor și actualizările sunt inerente unei metode agile, devenind cea mai mare provocare pentru QA
Risc de automatizare în procesul agil
- IU automatizat oferă un nivel ridicat de încredere, dar sunt lent de executat, fragile de întreținut și costisitoare de construit. Este posibil ca automatizarea să nu îmbunătățească semnificativ productivitatea testului decât dacă testatorii știu cum să testeze
- Testele nesigure sunt o preocupare majoră în testarea automată. Remedierea testelor nereușite și rezolvarea problemelor legate de testele fragile ar trebui să fie o prioritate pentru a evita falsurile pozitive
- Dacă testul automat este inițiat manual mai degrabă decât prin CI (Integrare continuă), atunci există riscul ca acestea să nu ruleze în mod regulat și, prin urmare, pot provoca eșecul testelor
- Testele automate nu înlocuiesc testele manuale exploratorii. Pentru a obține calitatea preconizată a produsului, este necesar un amestec de tipuri și niveluri de testare
- Multe instrumente de automatizare disponibile în comerț oferă funcții simple, cum ar fi automatizarea captării și redării cazurilor de testare manuale. Un astfel de instrument încurajează testarea prin UI și duce la teste inerente fragile și dificil de întreținut. De asemenea, stocarea cazurilor de test în afara sistemului de control al versiunii creează o complexitate inutilă
- Pentru a economisi timp, de multe ori planul de testare a automatizării este prost planificat sau neplanificat, ceea ce duce la eșecul testului
- Procedurile de configurare și eliminare a testului sunt de obicei ratate în timpul automatizării testului, în timp ce efectuarea testării manuale, o procedură de configurare și eliminare a testului sună perfect
- Măsurile de productivitate, cum ar fi un număr de cazuri de testare create sau executate pe zi, pot fi teribil de înșelătoare și ar putea duce la investiții mari în efectuarea testelor inutile.
- Membrii echipei de automatizare agile trebuie să fie consultanți eficienți: abordabili, cooperanți și plini de resurse, altfel acest sistem va eșua rapid
- Automatizarea poate propune și livra soluții de testare care necesită prea multă întreținere continuă în raport cu valoarea furnizată
- Testarea automată poate să nu aibă expertiza necesară pentru a concepe și furniza soluții eficiente
- Testarea automată poate avea un succes atât de mare încât să rămână fără probleme importante de rezolvat și astfel să apeleze la probleme neimportante.
Concluzie
Metodologia agilă în testarea software implică testarea cât mai curând posibil în ciclul de viață al dezvoltării software-ului. Solicită implicarea ridicată a clienților și codul de testare imediat ce devine disponibil. Codul ar trebui să fie suficient de stabil pentru a-l duce la testarea sistemului. Se pot face teste extinse de regresie pentru a vă asigura că erorile sunt remediate și testate. În principal, comunicarea dintre echipe face succes testarea modelelor agilă !!!