Cum să efectuați testarea post-lansare eficient și să minimizați impactul lansării pentru clienții live

how perform post release testing effectively

Când mi-am început cariera de QA, lucram cu o companie care își oferea produsele ca SaaS. Lansările de producție au fost esențiale și a existat posibilitatea de a afecta funcționalitatea pentru clienții live.

Pe măsură ce baza noastră de clienți a crescut, pentru a gestiona riscul și a minimiza impactul lansării pentru clienții vii, echipa QA a adoptat practica de testare post-lansare.

Toate acestea erau noi pentru mine și aveam atât de multe întrebări și îndoieli în minte:

• Ce este testarea după eliberare?
• Am testat totul corect, de ce trebuie să facem teste post-lansare?
• Testez totul din nou? Ce fac exact în verificarea post-lansare?
• Ce se întâmplă dacă găsesc o problemă? Etc.

Sunt bucuros să recunosc că mi-am găsit toate răspunsurile în primele mele lansări de producție.

Aici vă împărtășesc aceste cunoștințe tuturor. Am ales să scriu articolul într-un format de întrebare și răspuns pentru a vă arăta modul în care am descoperit răspunsurile.

Ce veți învăța:

• Ce este verificarea lansării după producție?
• Ce sarcini și activități sunt incluse în faza de verificare post-lansare?
• Trebuie să testez totul din nou?
• Cum formulez strategia de verificare după lansare?
• Cine creează planul de testare pentru lansare după producție?
• Cine aprobă planul de testare post-producție?
• Când creez planul de verificare a lansării post-producție?
• Am finalizat verificarea post-producție. Ce urmeaza?
• Ce se întâmplă dacă găsesc o problemă?
• Ce altceva mai trebuie să știu despre procesul de verificare a lansării post-producție?
• Concluzie:
• Lectură recomandată

Ce este verificarea lansării după producție?

Prin definitie, Post mijloace După , Lansarea producției se referă la desfășurare la medii LIVE / de producție și Verificare include asigurându-vă că funcțiile lansate îndeplinesc cerințele .

Citire recomandată=> Cum să pregătiți eficient „mediul de testare” înainte de a începe testarea

Obiectivul este de a verifica lansarea în producție / medii LIVE.

cum se repară gateway-ul implicit nu este disponibil Windows 10

Dar întrebările apar atunci:

• De ce trebuie să facem teste de lansare după producție atunci când am testat totul în mediul QA?
• De ce anticipăm să apară probleme la producție, deși am testat versiunea temeinic pe mediul de testare?

Există multe motive pentru care am avea probleme cu producția, chiar dacă am fi urmat complet Procesul de asigurare a calității (adică planificarea testelor , revizuirea planului de testare, ciclul de testare, teste de regresie etc.)

Motivele pentru care am avea probleme cu producția:

1) Problemă de date - Datele disponibile despre mediile de producție și testare pot varia. Acest lucru poate duce la pierderea unor probleme de tip colț în mediile de testare.

2) Problemă de implementare - Dacă compania dvs. are un proces de implementare manuală, versiunea dvs. poate fi mai predispusă la probleme de implementare. Unele scenarii obișnuite pot fi, lipsesc setările de configurare sau de site, lipsesc scripturile DB, ordinea de implementare care nu este urmată (mai întâi codul, apoi DB etc.), dependențele instalate incorect etc.

Citește și=> Ce ar trebui să știe Testerul QA despre procesul de implementare

3) Zonele de impact neidentificate - Pot exista unele scenarii pentru care zonele afectate pot să nu fi fost identificate corect și complet de către echipă.

De exemplu, ia în considerare un SaaS mediu inconjurator.

Dacă echipa nu a identificat impactul unei tabele DB re-factorizate asupra unui client utilizând schema de tabelă mai veche (de exemplu pierderea datelor, necesitatea migratia datelor înainte de lansare etc.), etc. Această problemă este mai puțin probabil să se întâmple pentru proiecte bine planificate, cu cerințe precise. Dar, există încă posibilitatea.

4) Zonele de impact necunoscute - Acest lucru se poate întâmpla dacă domeniul de aplicare și zonele afectate ale versiunii nu sunt cunoscute. De exemplu, într-o companie cu mai multe produse software care partajează DB și arhitectură comune, chiar și o mică modificare poate rupe funcționalitatea multor produse.

Ce sarcini și activități sunt incluse în faza de verificare post-lansare?

Activitățile și activitățile de lansare post-producție includ în general:

• Verificarea lansării după producție
• Raportați rezultatele verificării
• Raportarea oricăror probleme constatate la producție
• Curățarea datelor de verificare după lansare
• Monitorizare post lansare (dacă este cazul)

Trebuie să testez totul din nou?

Nu neaparat. Acest lucru depinde de versiunea care urmează să fie lansată și de analiza impactului.

Testarea detaliată trebuie făcută în timpul ciclului regulat de control al calității. Verificarea post-lansare trebuie făcută urmând un plan de testare a verificării post-producție care ar trebui să fie un derivat al planului complet de testare pentru acea versiune.

Cum formulez strategia de verificare după lansare?

Planificarea verificării lansării după producție trebuie să se facă în mod similar planificării testelor obișnuite.

Strategia ar trebui să fie pe aceleași linii ca și fluxul de testare urmat în timpul ciclului QA. Este important să includeți pașii importanți și critici care permit acoperirea funcționalității maxime.

întrebare de interviu sql pl pentru experimentat

O strategie bună de lansare după producție ar trebui:

• Includeți pași pentru a testa caracteristici noi, precum și caracteristici majore existente
• Verificați zonele cu impact major
• Permiteți o acoperire maximă a funcționalității
• Opțional: includeți orice erori critice care au fost găsite în mediul de testare
• Opțional: includeți prioritatea cazurilor de testare

Cine creează planul de testare pentru lansare după producție?

Acest lucru va varia în funcție de companii și va depinde de structura organizației.

Să luăm un exemplu despre următoarea organizare a echipei QA.

În acest scenariu, QA care lucrează la proiectul specific va formula planul inițial de testare după producție.

Cine aprobă planul de testare post-producție?

Acest lucru va varia în funcție de companii și va depinde de structura organizației.

Din nou, luând în considerare aceeași structură organizatorică așa cum se arată în întrebarea anterioară, planul de testare după lansarea producției ar trebui revizuit și aprobat de Conducătorul de test sau Managerul QA .

Când creez planul de verificare a lansării post-producție?

Planul de testare post-producție poate fi creat oricând în timpul ciclului de dezvoltare software după ce cerințele, domeniul de dezvoltare și zonele de impact sunt identificate și blocate. De obicei, este mai ușor pentru QA să creeze planul de testare post-producție la jumătatea sprintului. Acest lucru asigură că există suficient timp pentru revizuire și aprobare.

Este o practică bună să includeți acest plan de testare împreună cu oricare documente oficiale de semnare a QA înainte ca proiectul să intre în faza de implementare și lansare.

Am finalizat verificarea post-producție. Ce urmeaza?

După finalizarea verificării post-lansare, următorii pași ar fi

1) Comunicarea rezultatelor verificării - Rezultatele verificării ar trebui să fie comunicate părților interesate, inclusiv orice probleme care ar fi putut fi găsite la producție.

2) Raportarea oricăror probleme găsite în producție în instrumentul de gestionare a defectelor - La facilitează analiza cauzei rădăcină și trasabilitate .

3) Curățați datele de verificare după lansare - Curățarea datelor trebuie efectuată după finalizarea verificării.

De exemplu, ia în considerare un lansare pentru o aplicație de comerț electronic și spuneți că ați creat o comandă de testare la producție. Această comandă de testare trebuie anulată după finalizarea verificării.

4) Monitorizare post-producție (dacă este cazul) - Unele versiuni necesită monitorizarea producției.

De exemplu, dacă echipa a făcut îmbunătățiri pentru a îmbunătăți timpii de încărcare a paginii în aplicație, acest lucru ar trebui monitorizat într-o anumită perioadă de timp pentru a se asigura că îmbunătățirea a fost într-adevăr văzută după lansare. Persoana (persoanele) responsabilă (e) pentru monitorizare ar trebui să fie identificată și comunicată în mod clar.

cum să scrieți un e-mail unui eșantion de recrutor

Ce se întâmplă dacă găsesc o problemă?

Orice probleme ar trebui raportate în Instrument de gestionare a defectelor și comunicate părților interesate. Dacă se constată probleme critice cu privire la producție, comunicarea rezultatelor ar trebui să aibă loc imediat, deoarece ar trebui luată o decizie în cazul în care construcția trebuie revocată pentru a investiga problema în continuare.

Este important ca toate problemele găsite să fie raportate în Instrumentul de urmărire a defectelor. Este recomandat ca acestea să fie ridicate ca tip de problemă separat (de exemplu, eroare post-producție) pentru a arăta separarea de erorile obișnuite ale ciclului QA. Aceste probleme pot fi filtrate cu ușurință, dacă sunt necesare în scopul analizei cauzelor principale.

Ce altceva mai trebuie să știu despre procesul de verificare a lansării post-producție?

În afară de procesul, planul și strategia de verificare post-producție, mai jos sunt câteva indicații:

• Este important să stabiliți așteptări clare în ceea ce privește scopul și scopul verificării după lansare. Părțile interesate (interne și externe) ar trebui să fie conștiente de următoarele
  • Echipa nu poate testa totul în producție
  • Echipa nu poate stoarce zile în valoare de testare în câteva ore rezervate pentru verificarea post-lansare

Prin urmare, testarea producției s-ar baza în esență pe planul de testare aprobat după lansarea producției.

Limitări:

Ar trebui să se acorde atenția cuvenită în timp ce se decide amploarea testării post-producție. Există limitări în ceea ce privește și cât de mult putem testa efectiv asupra producției. Mediul de producție conține date în direct ale clienților și trebuie tratat cu mare atenție. Ar trebui făcută o planificare suplimentară pentru modificările care implică migrarea datelor, actualizarea, ștergerea etc.

Exemplul nr. 1): Pentru o companie eSurvey, dacă testarea implică răspunsul și trimiterea sondajului, QA ar trebui să trimită o cerere de ștergere a sondajului de testare după verificare, astfel încât să nu aibă impact asupra datelor de colectare a sondajului clienților și asupra statisticilor acestora.

ESTE xample # 2): Pentru o companie de comerț electronic, să presupunem că o actualizare a prețurilor, lucrarea SQL se execută la miezul nopții în fiecare zi și încarcă prețul final pe site. Nu putem rula acest SQL la cerere, de mai multe ori în scopul verificării post-lansare, deoarece acest lucru poate duce la transmiterea datelor nefinalizate la producție.

Mai mult, poate crește șansele de Blocaje DB și consum ridicat de resurse CPU și memorie în timpul orelor de lucru de vârf, care pot afecta performanța aplicației client.

• Efortul necesar pentru testarea post-lansare și toate activitățile conexe ar trebui să fie încorporate și incluse în Planul de proiect. În funcție de regulile de afaceri și de specificul proiectului, acest lucru poate fi considerat ca o cheltuială generală a proiectului sau inclus în ciclul de asigurare a calității sau inclus ca parte a planului de gestionare a lansării.
• Pentru problemele care sunt raportate în timpul verificării post-lansare, ar trebui efectuată o analiză a cauzei principale pentru a afla motivul pentru care problema nu a fost surprinsă mai devreme și ce se poate face mai bine data viitoare pentru a evita confruntarea cu problema. Analiza cauzei principale poate ajuta echipa să învețe din aceste probleme anterioare și să completeze orice lacune din implementare. Pe baza structurii organizației, conducătorul testului sau managerul de asigurare a calității poate finaliza analiza cauzei rădăcină cu contribuția echipei de proiect. Unele cauze principale comune pot fi o problemă de codificare, o cerință, o problemă de proiectare, o problemă de date, o limită terță parte, un scenariu de test lipsă etc. Pot fi create și urmărite acțiuni corective și preventive corespunzătoare.
• Jurnalele serverului poate fi, de asemenea, utilizat pentru a monitoriza construcția după lansare. Jurnal server poate conține evenimente sau probleme care pot să nu fie vizibile pentru client, dar care să provoace probleme în backend. Această monitorizare poate fi atribuită ca element de acțiune echipei Dev Dev și echipei DevOps.

Un exemplu:

Rezumatul proiectului:

Următoarele modificări trebuie făcute unei aplicații de socializare, în special în procesul de înscriere

1. Validarea câmpului de nume de familie trebuie eliminată. A fost implementat anterior ca „Numele de familie ar trebui să aibă minimum 4 caractere” (Îmbunătățire pentru câmpul existent)
2. Implementați butonul de comutare de lângă adresa de e-mail, astfel încât utilizatorul să poată seta setările de confidențialitate pentru adresa de e-mail pentru a fi afișate în profilul său (cerere de funcție nouă)
3. Utilizatorul ar trebui să-și poată alege avatarul (cerere de funcție nouă)
4. Reduceți apelurile API în timpul procesului de înscriere pentru a îmbunătăți performanța aplicației (îmbunătățire)

Planul de verificare a lansării după producție:

Concluzie:

Cu majoritatea companiilor de software acum adoptând metodologia Agile , numărul lansărilor de producție a crescut.

De exemplu, în timp ce utilizați Model cascadă , o echipă poate avea o lansare de producție la fiecare 1,5 luni, totuși, cu procesul Agile, aceeași echipă poate avea acum o lansare de producție la fiecare 2-3 săptămâni.

Cu fiecare lansare de producție, avem posibilitatea de a influența în mod conștient sau fără să știi funcționalitatea clienților live. Adoptarea verificării post-producție a lansării imediat după lansare poate oferi o încredere suplimentară asupra lansării, oferind în același timp rețeaua de siguranță a revocării versiunii înainte ca clienții noștri live să întâmpine unele probleme.

Pentru proiecte cu impact / risc ridicat , planul de verificare a lansării post-producție poate fi structurat pe baza priorității scenariului de testare. Testul de prioritate critică poate fi executat mai întâi și comunicarea către părțile interesate cu privire la rezultate și orice problemă. Dacă nu se găsesc probleme critice, atunci verificarea post-producție poate continua, în caz contrar, trebuie luată decizia de retragere pentru a minimiza timpul de nefuncționare al aplicației și impactul asupra clienților vii.

În plus, testarea post-producție poate fi automatizată iar scripturile de test pot fi rulate la cerere după fiecare lansare ca test de regresie. Din nou, trebuie să se acorde atenția cuvenită în timpul executării scripturilor de test automat la producție, deoarece acestea pot afecta datele și funcționalitatea clientului live.

Verificarea post-producție este ultima linie de apărare pentru orice companie de software. Dacă nu surprindem problemele, clienții noștri o vor face și acest lucru poate fi devastator pentru reputația oricărei companii de software.

Pentru a menține fiabilitatea produsului, este esențial să verificăm modificările implementate în producție imediat după implementare.

Despre autor: Acest articol util este scris de Neha B. În prezent lucrează ca manager de asigurare a calității și se specializează în conducerea și gestionarea echipelor interne și offshore de asigurare a calității.

Distribuiți cititorilor noștri strategia / sfaturile / experiența de testare a lansării post-producție.

Lectură recomandată

• Cele mai bune instrumente de testare software 2021 (Instrumente de automatizare a testelor de calitate)
• Descărcare eBook Descărcare Primer
• Implementarea practică în 7 pași a testării manuale înainte de lansarea producției
• Testarea încărcării cu tutoriale HP LoadRunner
• Testarea software-ului practic Flux de proces QA (Cerințe de lansare)
• Diferența dintre Desktop, Client Server Testing și Web Testing
• Ce este testarea Gamma? Etapa finală de testare
• Ce este testarea timpurie: testați devreme, testați deseori DAR cum? (Un ghid practic)