how improve test release process
Pogledajmo tipični postupak isporuke softvera od 'faze razvoja' do 'faze testiranja' za a uspješno puštanje softvera bez grešaka u proizvodnju / klijenta .
Ove procese ili zanemaruju ili preskaču softverske tvrtke, što rezultira lošim upravljanjem testovima i time ' lud 'Softver se izdaje klijentu, što dovodi do' nezadovoljni kupci '.
Čak iako puno vremena i velikog truda daje tim za testiranje za svako izdanje , kada izdani softver nema kvalitetu kako je definirana ili je standardno označen ili ne zadovoljava očekivane kriterije, to neće utjecati samo na reputaciju tvrtke kod kupaca već također demotivira i demoralizira projektni tim, što je najvažnije ispitni tim u cjelini .
Ako ste dio tima za testiranje u ovom scenariju, možda ćete i dalje razmišljati kako 'kako poboljšati moje mogućnosti testiranja i postoji li bolji način za prevladavanje ove situacije'.
Želim dati nekoliko savjeta i prijedloga, temeljenih na mojem iskustvu s različitim ispitnim timovima uključenim u softverske aplikacije i izdanja poslovnih proizvoda s više domena i platformi i s više okvira za testiranje, na kako poboljšati postupke objavljivanja testa , što će pojednostaviti vaš profesionalni život kao inženjera za ispitivanje ili voditelja ispitivanja za isporuku softvera svjetske klase.
Što ćete naučiti:
- Proces objavljivanja testa
- Poboljšanje procesa objavljivanja testa:
- Upravljanje i kontrola sadržaja testnog izdanja
- Uzorak predloška izvješća o izdanju:
- Zaključak:
- Preporučena literatura
Proces objavljivanja testa
Tablica u nastavku daje pregled postupka puštanja u test s tri univerzalne faze kao što su Ulaz, Proces i Izlaz.
kako testirati cross site skriptiranje
| ULAZNI | POSTUPAK | IZLAZ |
|---|---|---|
| 7 | Kontrolni popis za pregled koda je ažuriran i dostupan u VSS-u? | |
| Prethodni postupak Razvoj | Proces započinje s • Instalacija objavljenog softvera na poslužitelju za testiranje | Sljedeći postupak treba • Softver koji je prošao testiranje dima / razuma |
| Referenca informacija / dokumenata • Dokument o korisničkim zahtjevima • Specifikacije softverskih zahtjeva • Plan ispitivanja jedinica • Standardi kodiranja • Popis za provjeru koda • Plan razvoja • Plan osiguranja kvalitete • Dodjela zadataka • Radni paket • Raspored projekta • Plan projekta • Plan upravljanja konfiguracijom • Plan upravljanja rizicima. | Potprocesi • Priprema test slučajeva za sve jedinice • Razvoj i jedinstveno testiranje • Rukovanje postupcima neusklađenosti • Provedba plana upravljanja konfiguracijom. • Provođenje plana upravljanja rizikom • Praćenje napretka projekta • Ispravljanje pogrešaka i pregledi | Unutarnje potrebe kupaca • Izrada softvera s brojem verzije • Izvještaj o izdanju • Slučajevi za testiranje / dokument za Suite paketa • Planiranje izvršenja testa • Matrica sljedivosti • Podaci o ispitivanju |
| Provjera ulaznog ulaza • Projektna dokumentacija se pregledava i odobrava? • Standardi kodiranja, kontrolni popis za pregled koda dostupni su za referencu? • Dodijeljeni zadatak i ažuriran radni paket? • Funkcionalna specifikacija, plan razvoja i plan kvalitete su pregledani i odobreni? • Plan upravljanja rizicima sadrži ublažavanje i nepredviđene slučajeve za rješavanje rizika? • Učinkovitost rasporeda projekata za isporuku proizvoda na vrijeme? | Specifikacija procesa • Slučajevi jedinstvenih testova trebali bi se sastojati od svih kriterija ulaska i izlaska • Pridržavanje koda sa standardima kodiranja • NCP treba postupati prema Smjernicama • Koraci upravljanja konfiguracijom trebaju se pridržavati Plana upravljanja konfiguracijom • Upravljanje rizikom trebalo bi se pridržavati Plana upravljanja rizikom • Ispitivanje dima prolazi sve glavne značajke i funkcije | Potrebe vanjskih kupaca • Softver bez grešaka |
| Potporni procesi • Dodjela ljudi / hardvera / softvera / resursa • Održavanje kvara hardvera • Obuka za članove tima | Proces završava • Izvršenje ispitivanja dima / razuma na izdanoj zgradi | Parametri učinkovitosti • Svaka jedinica treba proći prvi krug testiranja • Zadaci koje treba izvršiti prema rasporedu projekata • Test pušenja treba proći prije puštanja • Testiranje timske strasti za testiranje softvera |
Svaki tim za testiranje trebao bi stvoriti a jedinstven spisak za izdanje softvera, prema domeni i platformi softvera i metodologiji upravljanja projektima (poput Agile Scrum itd.) i prema ručnom / automatiziranom okviru za testiranje, prihvatiti izdanu verziju prije početka izvođenja testa radi uštede vremena i truda.
Ovo je jedan od najvažnijih parametara učinkovitosti u fazi ispitivanja.
Poboljšanje procesa objavljivanja testa:
1) Pregledajte izvješće o izdanju za novu funkcionalnost, prilagodbu / modifikaciju postojeće funkcionalnosti, ispravke programskih pogrešaka iz prethodne verzije, koja će odlučiti započeti s izvršavanjem ispitivanja dima ili ispitivanja razuma, ili kombinacije oba.
dva) Pregledajte ažuriranje Ispitni dokumenti prema novoj funkcionalnosti i ispravcima programskih pogrešaka, ako već nisu ažurirani. Obično se tijekom životnog ciklusa razvoja softvera tim dokumentima ažuriraju ti dokumenti na temelju redovitih sastanaka za tjedni pregled projekata.
3) Pregledajte spremište za konfiguraciju softvera ažurira se za broj izrade, broj verzije, označava ili komentira s nazivom izdanja prema standardima definiranim u planu projekta. Također, osigurajte da je izrada uspješno sastavljena i instalirana na testnom poslužitelju.
4) Zakažite sastanak za brzi pregled projekta nakon objavljivanja kako bi razgovarali o prednostima i nedostacima objavljene gradnje, poznatim programskim pogreškama i kritičnoj funkcionalnosti itd., kako bi se izbjegle bilo kakve pogrešne komunikacije i pregledali svi važni zahtjevi klijenta. Strogo izbjegavajte bilo kakvu usmenu komunikaciju između razvojnih i ispitnih timova, jer to jako utječe na kvalitetu izdanja softvera.
5) Provjerite je li alat za praćenje grešaka pravilno konfiguriran , za dodijeljeni ispitni tim i razvojni tim projekta, brojeve izrade i izdanja softvera, kao i module / funkcionalnost softvera, koji će pomoći u učinkovitom prijavljivanju programskih pogrešaka. Ako nije, treba ih proslijediti voditelju projekta ili voditelju ispitivanja na visokom prioritetu.
6) Vratite Izgradnju razvojnom timu bez ikakvih kompromisa, ako izrada ne uspije u testiranju dima ili razuma. Strogo, ispitivanje se ne bi trebalo nastaviti kada sustav zakaže pri testiranju dima. To će uštedjeti puno vremena i truda i poboljšati kvalitetu softvera objavljenog u sljedećim izdanjima.
7) Zakažite objavljivanje projekta 1svDan u tjednu što će voditelju testa pomoći da planira nadolazeći ciklus testiranja na temelju stabilnosti gradnje, a također i voditelju projekta poslati brzo izvješće o testiranju koje će unaprijed eskalirati kvalitetu softvera. Ako razvojni tim zakaže puštanje projekta u petak, vikend se može iskoristiti za bilo kakve klizaljke, kao i za sve probleme u vezi s gradnjom u ručnom ili automatiziranom okviru za izradu.
8) Osigurajte da su ispitivači pravilno obučeni na domeni što će pomoći ispitnom timu da se pridržava rasporeda ispitivanja i prikupi vrijeme za sljedeći krug testiranja. Također, ispitni tim trebao bi biti obučen i biti izložen potrebnoj tehnologiji poput Scriptinga i SQL-a ako projekt zahtijeva bijeli boks.
9) Izbjegavajte dodjelu testera u više projekata jer uvelike utječe na kvalitetu izvođenja testa u stvarnom vremenu. U praksi čak i iskusni testeri previdju značajke i funkcionalnost, kao i preskakanje test slučajeva, pod pretpostavkom da neki test slučajevi nikada ne propadnu, kada su preopterećeni poslom ili dodijeljeni na više projekata s rokovima.
10) Cijenimo ispitni tim koji ima strasti jer testeri ne bi trebali raditi za 'Dan' ili komentirati 'Nazovite ga danom'. Kada softver ima više modula, a funkcionalist je potpuno ili djelomično integriran ili međusobno povezan, testeri bi trebali imati strast za pisanje / izvršavanje testnih slučajeva s velikom pokrivenošću i matricom sljedivosti, ciljajući kvalitetu konačnog softvera / proizvoda. Jer čak je i kozmetički problem 'greška' i računa se kao '1 greška'.
jedanaest) Osigurajte da je instalacija softvera laka i jednostavna jer pomaže timu za testiranje da ponovno instalira softver kad je to potrebno, umjesto da čeka da voditelj razvoja ili upravitelj instalacije rade isti posao, što će nepotrebno ubiti dostupno vrijeme testiranja. Na primjer, iako je instalacija zasnovana na sustavu Windows jednostavna, ali kada uključuje više web poslužitelja i mreže širokog područja u višeslojnom testnom okruženju, testerima će trebati sati da instaliraju softver. Ako je pokriva testiranje softvera i instalacija, deinstalacija , zakrpe ili ažuriranja softvera, vjerojatnije je da će se o procesu izvršavanja testnih slučajeva detaljno razgovarati s testnim timom.
12) Osigurajte da su automatizirani alati dostupni s licencom za okvir za ispitivanje automatizacije . Izvršenje test slučajeva u automatiziranom okviru lako je u usporedbi sa scenarijem ručnog testiranja, pod uvjetom da su automatizirani alati pravilno konfigurirani i licencirani za više korisnika. Pogotovo, kada plan testiranja uključuje testiranje performansi i učitavanja, osim redovnog izvršavanja testnog slučaja i regresijskog testiranja, testeri bi trebali obuhvaćati izvršavanje testnih slučajeva u više okruženja kao što su više poslužitelja, više preglednika, više korisnika itd.
13) Osigurajte da su Ghosted Machines postavljeni za testiranje prije početka izvođenja testa. Ghosted strojevi su strojevi s različitim testnim okruženjem. Na primjer, softver web aplikacija može se planirati za testiranje u više okruženja kao što su Windows 7 i Access DB ili Windows 2008 i SQL Server ili Windows 8 & Oracle ili Mainframe & DB2 itd., Sa svim preglednicima kao što su Chrome, Firefox, Internet Explorer , Safari itd., Neko 'testiranje sustava' čak zahtijeva potpuno formatiranje tvrdog diska i instaliranje svježeg softvera ili ažuriranje postojećeg softvera zakrpama i ažuriranjima itd.
14) Izbjegavajte primjenu novih značajki / zahtjev za promjenom zaustavljanjem izvođenja testa i ponovnim puštanjem softvera za ponovno navođenje faze testiranja. To je vrlo loša praksa u mnogim softverskim organizacijama prema poslovnim zahtjevima da bi se zadovoljili vanjski kupci ili barem da bi se zadovoljili zahtjevi upravnog odbora ili ponekad prodajnih / marketinških timova. Iako se zahtjevi za promjenu od kupaca uvijek potiču u „agilnom“ projektnom okruženju, trebalo bi ih pravilno planirati i implementirati prije izdavanja softvera za tim za testiranje.
Upravljanje i kontrola sadržaja testnog izdanja
Upravljanje i kontrola sadržaja testnog izdanja najvažnije je za bilo koji IT softver, pa čak i za bilo koje softversko okruženje koje nije IT, a koje će biti prikazane na donjoj slici.
- Voditelji projekata i / ili odbor za upravljanje projektom ovisi o ovlastima matrice organizacije, odgovoran je za odabir sadržaja za svako izdanje.
- Jednom kada se programske pogreške i / ili nove značajke i zahtjev kupaca identificiraju i odobre, implementirat će ih razvojni tim koji bi trebao biti predstavljen dionicima projekta prije početka razvoja / implementacije.
- Na temelju provedenog konačnog izdanja, tim za testiranje ažurirat će povezane dokumente i pripremiti se za testiranje u skladu s tim.
- Testirajući tim započet će testiranje dima / razuma u skladu s definiranim zahtjevima u izvješću o izdanju.
- Nakon što Sanity prođe, ispitni tim započet će izvršavanje testa prema rasporedu i dodijeljenim zadacima, naime, funkcionalno testiranje, nefunkcionalno ispitivanje, sigurnosno testiranje, testiranje sustava, ispitivanje performansi, ispitivanje opterećenja, ispitivanje prihvaćanja korisnika itd.
- Nakon što se završi prva runda ciklusa testiranja, izvještaji o testiranju bit će poslani svim dionicima i voditelju razvojnog tima da planiraju sljedeću iteraciju izvođenja testa.
- Ovisno o statusu izvještaja o ispitivanju te težini i složenosti programskih pogrešaka, planirat će se cjeloviti ciklus drugog kruga izvođenja ili regresijskog testiranja zajedno s korisničkim ispitivanjem prihvaćanja.
- Nakon završetka planiranih ciklusa izvođenja testa, izvještaji o testiranju bit će poslani svim dionicima projekta za prođene / neuspjele / propuštene značajke, funkcionalnost i ispravke programskih pogrešaka.
Uzorak predloška izvješća o izdanju:
Bilješka : Uzorak MS Word predloška za izvješće o izdanju također je dostupan za preuzimanje u nastavku.
Pronađite ispod ' Uzorak izvješća o izdanju ”Koji pokriva glavne aspekte postupka izdavanja što profesionalni život cijelog projektnog tima čini puno sretnijim nego ikad prije.
GPSNavigation_Release_Report_Ver_1.0.7_Release_14.0_Build_105.25.03
# 1) Opseg
GPS navigacija za XYZ Company Limited pušta se na interno testiranje. Objavljena verzija je 1.0.7, broj izdanja je 14.0, a broj gradnje 105.25.03. Ovo izdanje softvera uključuje nove značajke i glavne ispravke programskih pogrešaka iz prethodnog izdanja. Testiranje dima prelazi se iz razvojne faze, ali prije odlaska na regresijsko testiranje potreban je Smoke & Sanity.
# 2) Reference
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) Opis izdanja
Ovo izdanje je kontrolirano izdanje GPS navigacije i sadrži sljedeće značajke i funkcije.
Značajke označene s * nove su u ovom izdanju.
Sljedeće značajke nisu implementirane u ovo izdanje.
1. Modul 1
1.1 Značajka 1
1.1.1 Funkcionalnost 1
# 4) Upravljanje konfiguracijom
Visual Source Safe koristimo kao alat za upravljanje konfiguracijom. Izgradnja je dostupna na sljedećem putu.
Interna veza: http://234.23.45.111/internalbuild/gpsnavigation/release1.0.13
Vanjska poveznica: https: // 234.23.45.111/externalbuild/gpsnavigation/release1.0.13
# 5) Upute i koraci za instalaciju
Dajte detaljne informacije za instalaciju gradnje QA / ispitnom timu.
# 6) Ispravljeni problemi / bugovi
Status grešaka ažurira se u sustavu za praćenje nedostataka.
# 7) Problemi / greške koje treba popraviti
# 8) Isporučeno
# 9) Poznate greške / problemi
# 10) Popis za provjeru izdanja
| Da ne / | Opis | Y / N |
|---|---|---|
| 1 | Jesu li sve datoteke provjerene u programu Visual Source Safe? | |
| dva | Je li naljepnica stavljena na odgovarajuću mapu u VSS-u prema internim standardima? | |
| 3 | Je li izdanje moguće identificirati kao 'vanjsko' / 'unutarnje' izdanje u VSS-u? | |
| 4 | Je li se u komentarima verzija spominjala u VSS-u? | |
| 5 | Je li u komentarima spomenut kratki opis u VSS-u? | |
| 6 | Kôd je pregledan, a problemi s pregledom koda prijavljeni su u Clear Quest? | |
| 8 | Jedinstveni testni dokument pripremljen je i pregledan? | |
| 9 | Izvršeni jedinstveni testni slučajevi i ažurirani rezultati za status? | |
| 10 | Ažurirani dokument o jedinstvenom testnom slučaju dostupan je u VSS-u? | |
| jedanaest | Svi problemi s Clear Questom za ovo izdanje su riješeni / zatvoreni? | |
| 12 | Svi zadaci radnog paketa dovršeni i ažurirani u VSS-u? | |
| 13 | Je li testiranje dima završeno i položeno? |
=> preuzimanje datoteka: Kliknite ovdje za preuzimanje uzorka predloška izvješća o izdanju u MS Word formatu.
Zaključak:
Kako kontinuirano poboljšavati postupak objavljivanja testa
Savjet br. 1) Postavite inženjerski tim za izdanja koji će se pobrinuti za kritične čimbenike održavanja izdanja i izrade softvera i odgovoran za centralizirane sustave za upravljanje konfiguracijom softvera.
Savjet br. 2) Motivirajte i cijenite projektne timove za praćenje procesa uključenih u životni ciklus razvoja softvera, životni ciklus razvoja proizvoda i životni ciklus testiranja softvera. Možemo definirati postupak, ali dok ga ne slijede uključeni ljudi, nema koristi od definiranja procesa.
Savjet br. 3) Procijenite napor na testiranju na temelju iskustava i prethodne povijesti. Pisanje testnih slučajeva potpuno se razlikuje od izvršavanja istih. Ispitivači bi trebali razumjeti što testirati, kako testirati i kada testirati, u protivnom se napori uloženi u ciklus testiranja troše, iako se dogodilo više krugova test ciklusa.
Savjet br. 4) Napokon, ako je moguće i izvedivo, automatizirajte fazu testiranja pomoću nekih općeprihvaćenih alata za testiranje. Korištenje automatiziranih alata za izradu i automatiziranih alata za ispitivanje smanjuje napore testiranja za više od 50% poboljšavajući kvalitetu softvera i osiguravajući 100% kvalitetu ako je okvir za automatizaciju pravilno dizajniran.
Savjet br. 5) I na kraju, ali ne najmanje važno, izdanje testa nije samo posao, to je umijeće olakšati život svih dionika u projektu lakšim i ugodnijim.
O autoru: Balu A. iskusni je tehno-funkcionalni IT stručnjak s više od dva desetljeća iskustva u IT softveru i desetljećem iskustva u upravljanju projektima i testovima, isporučujući poslovne aplikacije i rješenja za mobilnost na više domena koristeći tehnologije Microsoft, Oracle, Java i Mobile. U osnovi je vođa koji strastveno promovira ljude da postanu vođe s pravim stavom i voli raditi u procesno orijentiranom okruženju i vjeruje da proces poboljšava učinkovitost, kvalitetu i produktivnost zaposlenika.
Usljedeći vodič, naučit ćemo - Kako Poboljšati učinkovitost testnih slučajeva.
Javite nam svoje misli / upite u komentarima ispod.
Imajte izdanje softvera prema postupku!
Kompletno testiranje prema rasporedu uz veliku produktivnost i napore !!
Pokušajte postići isporuku softvera bez grešaka, osiguranu kvalitetu !!!
Ako vam se sviđa ovaj članak, razmislite o tome da ga podijelite sa svojim prijateljima!
Preporučena literatura
- Tečaj za testiranje softvera: Koji bih se institut za testiranje softvera trebao pridružiti?
- Najbolji alati za testiranje softvera 2021. (Alati za automatizaciju ispitivanja kvalitete)
- Posao za QA pomoćnika za testiranje softvera
- Što je ispitivanje majmuna u testiranju softvera?
- Odabir testiranja softvera za vašu karijeru
- Testiranje softvera Posao pisca tehničkog sadržaja Posao slobodnjaka
- Uzorak izvještaja o greškama
- Praktično testiranje softverskog tijeka QA procesa (zahtjevi za objavljivanje)