how improve test release process
Să vedem procesul tipic implicat în livrarea de software de la „faza de dezvoltare” la „faza de testare” pentru un lansarea cu succes a software-ului fără erori către producție / client .
Aceste procese sunt fie trecute cu vederea, fie omise de companiile de software, ceea ce duce la o gestionare deficitară a testelor și, prin urmare, „un„ carucior „Software-ul este lansat către client, ceea ce duce la„ clienți nemulțumiți ”.
Chiar dacă Echipa de testare oferă mult timp și eforturi mari pentru fiecare lansare , atunci când software-ul lansat nu are calitatea definită sau notată sau nu îndeplinește criteriile așteptate, nu numai că va afecta reputația companiei cu clienții, ci și demotivează și demoralizează echipa de proiect cel mai important, echipa de testare în ansamblu .
Dacă faceți parte dintr-o echipă de testare în acest scenariu, s-ar putea să vă gândiți în continuare „cum să îmi îmbunătățesc capacitățile de testare și există o modalitate mai bună de a depăși această situație”.
Vreau să dau câteva sfaturi și sugestii, pe baza experienței mele cu diverse echipe de testare implicate în aplicații software și lansări de produse de întreprindere cu mai multe domenii și platforme și cu mai multe cadre de testare, pe cum să îmbunătățim procesele de lansare a testelor , ceea ce vă va simplifica viața profesională ca inginer de testare sau manager de testare pentru furnizarea de software de talie mondială.
Ce veți învăța:
- Procesul de lansare a testului
- Îmbunătățirea procesului de lansare a testului:
- Gestionarea și controlul conținutului lansării testului
- Exemplu de șablon de raport de lansare:
- Concluzie:
- Lectură recomandată
Procesul de lansare a testului
Tabelul de mai jos oferă o prezentare generală a unui proces de lansare a testului cu trei faze universale, cum ar fi Intrare, Proces și Ieșire.
întrebări de interviu cu privire la testarea serviciilor web
| INTRARE | PROCES | IEȘIRE |
|---|---|---|
| 7 | Lista de verificare a revizuirii codului a fost actualizată și disponibilă în VSS? | |
| Procesul anterior Dezvoltare | Procesul începe cu • Instalarea software-ului lansat în serverul de testare | Următorul proces are nevoie • Software care a trecut testarea fumului / sănătății |
| Informații / document de referință • Document privind cerințele utilizatorului • Specificații privind cerințele software • Planul de testare unitară • Standarde de codificare • Lista de verificare a revizuirii codului • Plan de dezvoltare • Plan de asigurare a calității • Alocarea sarcinilor • Pachet de lucru • Programul proiectului • Plan de proiect • Plan de gestionare a configurației • Planul de gestionare a riscurilor. | Subprocese • Pregătirea cazurilor de test pentru toate unitățile • Dezvoltare și testare unitară • Gestionarea procedurilor de neconformitate • Implementarea planului de gestionare a configurației. • Implementarea planului de gestionare a riscurilor • Monitorizarea progresului proiectului • Corecție erori și recenzii | Nevoile interne ale clienților • Construire software cu număr de versiune • Raport de lansare • Cazuri de testare / Document de testare • Planificarea executării testului • Matricea de trasabilitate • Date de testare |
| Verificare intrare intrare • Documentele proiectului sunt revizuite și aprobate? • Standardele de codificare, Lista de verificare a revizuirii codului sunt disponibile pentru referință? • Sarcina alocată și pachetul de lucru actualizat? • Specificațiile funcționale, planul de dezvoltare și planul de calitate sunt revizuite și aprobate? • Planul de management al riscului are atenuare și contingență pentru a gestiona riscul? • Eficacitatea programului de proiect pentru a livra produsul la timp? | Specificația procesului • Cazurile de testare unitară ar trebui să fie alcătuite din toate criteriile de intrare și ieșire • Respectarea codului cu standardele de codificare • NCP ar trebui tratat conform Ghidului • Pașii de gestionare a configurației trebuie să respecte planul de gestionare a configurației • Tratarea riscurilor ar trebui să respecte Planul de gestionare a riscurilor • Testarea fumului depășește toate caracteristicile și funcționalitățile majore | Nevoile externe ale clienților • Bug Free Software |
| Procese de susținere • Alocare umană / hardware / software / resurse • Întreținere defecțiune hardware • Instruirea membrilor echipei | Procesul se încheie cu • Executarea testelor de fum / sănătate asupra clădirii eliberate | Parametrii de eficiență • Fiecare unitate ar trebui să treacă prima rundă de testare • Sarcini care trebuie îndeplinite conform Planificării proiectului • Testul de fum trebuie trecut înainte de eliberare • Testarea pasiunii echipei pentru testarea software-ului |
Fiecare echipă de testare ar trebui să creeze un unic listă de verificare pentru lansarea software-ului, conform domeniului și platformei software-ului și metodologiei de gestionare a proiectelor (cum ar fi Agile Scrum etc.) și conform cadrului de testare manual / automatizat, pentru a accepta versiunea lansată, înainte de a începe executarea testului pentru a economisi timp și efort.
Acesta este unul dintre cei mai importanți parametri de eficiență în faza de lansare a testului.
Îmbunătățirea procesului de lansare a testului:
1) Examinați raportul de lansare pentru noua funcționalitate, personalizarea / modificarea funcționalității existente, remedierea erorilor din versiunea anterioară, care va decide să înceapă executarea Testului de fum sau a Testului de sănătate sau a unei combinații a ambelor.
2) Examinați actualizarea Documente de testare conform noii funcționalități și remediilor de erori, dacă nu au fost deja actualizate. În mod normal, în timpul ciclului de viață al dezvoltării software-ului, aceste documente sunt actualizate de echipa de testare pe baza reuniunilor săptămânale regulate de revizuire a proiectului.
3) Examinați versiunea de software în depozitul de configurare este actualizat pentru numărul de versiune, numărul versiunii, etichetat sau comentat cu numele versiunii conform standardelor definite în planul de proiect. De asemenea, asigurați-vă că compilarea este compilată și instalată cu succes pe serverul de testare.
4) Programați o reuniune rapidă de revizuire a proiectului după lansare să discute avantajele și dezavantajele versiunii lansate, erorile cunoscute și funcționalitatea critică etc., pentru a evita orice comunicare greșită și pentru a revizui orice cerințe importante ale clientului. Evitați cu strictețe orice comunicare orală între echipele de dezvoltare și testare, deoarece are un impact puternic asupra calității lansării software-ului.
5) Asigurați-vă că instrumentul de urmărire a erorilor este configurat corect , pentru echipa de testare alocată și echipa de dezvoltare a proiectului, crearea și lansarea numerelor software, precum și modulele / funcționalitatea software-ului, care vor ajuta la înregistrarea eficientă a erorilor. Dacă nu, ar trebui să fie trimis la managerul de proiect sau managerul de testare pe o bază cu prioritate ridicată.
6) Întoarceți construcția echipei de dezvoltare fără compromisuri, în cazul în care construcția eșuează în testarea fumului sau a sănătății. În mod strict, testarea nu trebuie continuată atunci când sistemul eșuează în Testarea fumului. Acest lucru va economisi mult timp și efort și va îmbunătăți calitatea software-ului lansat în versiunile ulterioare.
7) Programați lansarea proiectului pe 1SfZi a săptămânii ceea ce va ajuta managerul de testare să planifice următorul ciclu de testare pe baza stabilității construcției și, de asemenea, să trimită un raport rapid de testare managerului de proiect, care va escalada calitatea software-ului cu mult timp în avans. Dacă echipa de dezvoltare programează lansarea proiectului vineri, weekendul poate fi utilizat pentru orice derapaj, precum și pentru orice problemă de construcție într-un cadru de construcție manual sau automat.
8) Asigurați-vă că testerii sunt instruiți corespunzător pe domeniu ceea ce va ajuta echipa de testare să respecte programul de testare și să adune timp pentru următoarea rundă de testare. De asemenea, echipa de testare ar trebui să fie instruită și să aibă expunerea la tehnologia necesară, cum ar fi Scripting și SQL, dacă proiectul necesită box alb.
9) Evitați alocarea testerelor în mai multe proiecte deoarece afectează foarte mult calitatea execuției testului în timp real. În practică, chiar și testerii experimentați trec cu vederea caracteristicile și funcționalitatea, precum și ignoră cazurile de testare, presupunând că unele cazuri de testare nu eșuează niciodată, atunci când sunt supraîncărcate cu muncă sau sunt alocate pe mai multe proiecte cu termene limită.
10) Apreciați echipa de testare pentru a avea pasiune deoarece testerii nu ar trebui să lucreze pentru „Ziua” sau să comenteze „Numiți-o o zi”. Atunci când software-ul are mai multe module și funcționalistul este integrat sau parțial complet sau parțial, testerii ar trebui să aibă pasiunea pentru scrierea / executarea cazurilor de testare cu o matrice de acoperire și trasabilitate excelentă, vizând calitatea software-ului / produsului final. Deoarece chiar și o problemă cosmetică este o „eroare” și este considerată „1 eroare”.
unsprezece) Asigurați-vă că instalarea software-ului este ușoară și simplă deoarece ajută echipa de testare să reinstaleze software-ul atunci când este necesar, în loc să aștepte ca managerul de dezvoltare sau un manager de instalare să facă aceeași treabă, ceea ce va ucide timpul de testare disponibil inutil. De exemplu, chiar dacă instalarea bazată pe Windows este ușoară, dar atunci când implică mai multe servere web și rețele extinse într-un mediu de testare pe mai multe niveluri, testerii pot dura ore întregi pentru a instala software-ul. Dacă testarea software-ului de acoperire și instalare, dezinstalare , patch-uri sau actualizări de software, este mai probabil să se discute în detaliu procesul de executare a cazurilor de testare cu echipa de testare.
12) Asigurați-vă că instrumentele automate sunt disponibile cu licență pentru un cadru de testare a automatizării . Executarea cazurilor de testare într-un cadru automat este ușoară în comparație cu un scenariu de testare manuală, cu condiția ca instrumentele automatizate să fie configurate și licențiate corespunzător pentru mai mulți utilizatori. Mai ales, atunci când planul de testare implică testarea performanței și a sarcinii, în afară de execuția regulată a cazurilor de testare și testarea de regresie, testerii ar trebui să acopere executarea cazurilor de testare pe mai multe medii, cum ar fi mai multe servere, mai multe browsere, mai mulți utilizatori etc.
13) Asigurați-vă că mașinile Ghosted sunt configurate pentru testare înainte de a începe executarea testului. Mașinile Ghosted sunt mașini cu mediul de testare diferit. De exemplu, un software de aplicație web poate fi planificat pentru testare în mai multe medii precum Windows 7 și Access DB sau Windows 2008 și SQL Server sau Windows 8 și Oracle sau Mainframe și DB2 etc., cu toate browserele precum Chrome, Firefox, Internet Explorer , Safari etc., Unele „testări de sistem” chiar necesită formatarea completă a hard diskului și instalarea unui software nou sau actualizarea software-ului existent cu patch-uri și actualizări etc.
14) Evitați implementarea noilor caracteristici / cerere de modificare prin oprirea executării testului și relansarea software-ului pentru declararea din nou a fazei de testare. Aceasta este o practică foarte proastă în multe organizații software, conform cerințelor de afaceri pentru a satisface clienții externi sau cel puțin pentru a satisface cerințele comitetului de conducere al managementului sau uneori al echipelor de vânzări / marketing. Chiar dacă solicitările de schimbare de la clienți sunt întotdeauna încurajate într-un mediu de proiect „Agile”, acestea ar trebui să fie planificate și implementate corespunzător înainte de lansarea software-ului către echipa de testare.
Gestionarea și controlul conținutului lansării testului
Gestionarea și controlul conținutului lansării testului este cel mai important pentru orice software IT sau chiar pentru orice mediu software non-IT care va fi descris în figura de mai jos.
- Managerii de proiect și / sau comitetul de coordonare a proiectului depind de autoritatea matricei organizației, fiind responsabil de selectarea conținutului pentru fiecare versiune.
- Odată identificate și aprobate erorile și / sau noile caracteristici și cererea de modificare de la clienți, acestea vor fi puse în aplicare de către echipa de dezvoltare, care ar trebui să fie informată părților interesate din proiect înainte de începerea dezvoltării / implementării.
- Pe baza versiunii finale implementate, echipa de testare va actualiza documentele aferente și se va pregăti pentru testare în consecință.
- Echipa de testare va începe testarea fumului / sănătății conform cerințelor definite în raportul de lansare.
- Odată ce Sanity a trecut, echipa de testare va începe executarea testului conform programului și sarcinilor alocate și anume, Testare funcțională, Testare nefuncțională, Testare de securitate, Testare sistem, Testare performanță, Testare sarcină, Testare acceptare utilizator etc.
- Odată ce prima rundă a ciclului de testare este finalizată, rapoartele de testare vor fi trimise tuturor părților interesate și managerului echipei de dezvoltare pentru a planifica următoarea iterație a executării testului.
- Depinde de starea rapoartelor de testare și de severitatea și complexitatea erorilor, un ciclu complet al unei a doua runde de execuție a testului sau testare de regresie va fi planificat împreună cu testarea de acceptare a utilizatorului.
- După finalizarea ciclurilor de execuție a testului planificate, rapoartele de testare vor fi trimise tuturor părților interesate ale proiectului pentru trecerea / eșuarea / ratarea caracteristicilor, funcționalității și remedierilor de erori.
Exemplu de șablon de raport de lansare:
Notă : Exemplul de șablon MS Word pentru raportul de lansare este de asemenea disponibil pentru descărcare mai jos.
Găsiți mai jos un „ Exemplu de raport de lansare ”Care acoperă principalele aspecte ale procesului de lansare, ceea ce face viața profesională a întregii echipe de proiect mult mai fericită ca niciodată.
GPSNavigation_Release_Report_Ver_1.0.7_Release_14.0_Build_105.25.03
#1 Domeniul de aplicare
Navigarea GPS pentru XYZ Company Limited este lansată pentru testare internă. Versiunea lansată este 1.0.7, numărul de lansare este 14.0 și numărul de construcție 105.25.03. Această versiune software include noile caracteristici și remedierile majore de erori de la versiunea anterioară. Testarea fumului este trecută din faza de dezvoltare, dar este necesar un fum și sănătate înainte de a merge la testarea de regresie.
# 2) Referințe
GPSNavigation_URD_1.0.12, GPSNavigation_FFD_2.17, GPSNavigation_BusinessUseCases_1.23.10, GPSNavigation_TestPlan_1.44, GPSNavigation_TestSuites_2.10, GPSNavigation_UnitTesting_23.3
# 3) Descrierea versiunii
Această versiune este o versiune controlată de navigare GPS și conține următoarele caracteristici și funcționalități.
Funcțiile marcate cu * sunt noi în această versiune.
Următoarele caracteristici nu au fost implementate în această versiune.
1. Modulul 1
1.1 Caracteristica 1
1.1.1 Funcționalitate 1
# 4) Managementul configurației
Folosim Visual Source Safe ca instrument de gestionare a configurației. Construirea este disponibilă în următoarea cale.
Link intern: http://234.23.45.111/internalbuild/gpsnavigation/release1.0.13
Link extern: https: // 234.23.45.111/externalbuild/gpsnavigation/release1.0.13
# 5) Instrucțiuni de instalare și pași
Oferiți informațiile detaliate pentru instalarea versiunii echipei QA / Testing.
# 6) Probleme / erori remediate
Starea erorilor este actualizată în sistemul de urmărire a defectelor.
# 7) Probleme / erori de remediat
# 8) Livrabile
# 9) Erori / probleme cunoscute
# 10) Lista de verificare a lansării
| Da nu / | Descriere | DA / N |
|---|---|---|
| unu | Au fost verificate toate fișierele în Visual Source Safe? | |
| Două | A fost pusă eticheta în folderul corespunzător din VSS conform standardelor interne? | |
| 3 | Versiunea este identificabilă ca versiune „externă” / „internă” în VSS? | |
| 4 | În comentarii, a fost menționată versiunea în VSS? | |
| 5 | În comentarii, a fost menționată o scurtă descriere în VSS? | |
| 6 | Codul a fost revizuit și problemele de revizuire a codului sunt înregistrate în Clear Quest? | |
| 8 | Documentul de testare a fost pregătit și revizuit? | |
| 9 | Cazurile testelor unitare au fost executate și rezultatele actualizate pentru starea? | |
| 10 | Documentul actualizat al cazului de testare unitar este disponibil în VSS? | |
| unsprezece | Toate problemele Clear Quest pentru această versiune au fost rezolvate / închise? | |
| 12 | Toate sarcinile pachetului de lucru au fost finalizate și actualizate în VSS? | |
| 13 | Testul de fum este făcut și trecut? |
=> Descarca: Faceți clic aici pentru a descărca un șablon de raport de versiune în format MS Word.
Concluzie:
Cum se îmbunătățește continuu procesul de lansare a testului
Sfatul nr. 1) Instalați o echipă de ingineri de versiuni care va avea grijă de factorii critici ai menținerii versiunilor și construcțiilor de software și responsabilă pentru sistemele centralizate de gestionare a configurației software-ului.
Sfatul nr. 2) Motivați și apreciați echipele de proiect pentru urmărirea procesului implicat în ciclul de viață al dezvoltării software-ului, al ciclului de viață al dezvoltării produselor și al ciclului de viață al testării software-ului. Putem defini procesul, dar până și dacă nu este urmat de persoanele implicate, nu are rost să definim procesul.
Sfatul nr. 3) Estimează efortul de testare pe baza experiențelor și a istoriei anterioare. Scrierea cazurilor de testare este total diferită de executarea acelorași. Testatorii ar trebui să înțeleagă ce să testeze, cum să testeze și când să testeze, în caz contrar, eforturile date ciclului de testare sunt irosite, chiar dacă au avut loc mai multe runde ale ciclului de testare.
Sfatul nr. 4) În cele din urmă, dacă este posibil și fezabil, automatizați faza de testare folosind unele instrumente de testare universal acceptate. Utilizarea instrumentelor de construire automate și a instrumentelor de testare automate reduc eforturile de testare cu mai mult de 50% îmbunătățind calitatea software-ului și asigură 100% calitate dacă cadrul de automatizare este proiectat corect.
Sfatul nr. 5) Nu în ultimul rând, lansarea testului nu este doar o slujbă, este o artă de a face viața tuturor părților interesate într-un proiect ușoară și mai confortabilă.
Despre autor: Balu A. este un profesionist IT cu experiență tehnofuncțională, cu peste două decenii de experiență în software IT și un deceniu de experiență în gestionarea proiectelor și testelor, oferind aplicații de întreprindere și soluții de mobilitate pe domenii folosind tehnologiile Microsoft, Oracle, Java și Mobile. Este practic un lider cu o pasiune de a promova oamenii să devină lideri cu atitudinea corectă și iubește să lucreze într-un mediu orientat spre proces și crede că procesul îmbunătățește eficiența, calitatea și productivitatea angajaților.
Înurmătorul tutorial, vom învăța - Cum să Îmbunătățiți eficiența cazului de testare.
Spuneți-ne părerile / întrebările dvs. în comentariile de mai jos.
Aveți o versiune de software conform procesului!
Testare completă la program, cu mare productivitate și eforturi !!
Încercați să obțineți livrarea de software fără erori, asigurată de calitate !!!
Dacă îți place acest articol, ia în considerare partajarea cu prietenii tăi!
Lectură recomandată
- Curs de testare software: La ce institut de testare software ar trebui să mă alătur?
- Cele mai bune instrumente de testare software 2021 (Instrumente de automatizare a testelor de calitate)
- Testare software Job asistent QA
- Ce este testarea maimuțelor în testarea software-ului?
- Alegerea testării software ca carieră
- Testarea software-ului Conținut tehnic Scriitor freelancer
- Exemplu de raport de erori
- Testarea software-ului practic Flux de proces QA (Cerințe de lansare)