Meni

Što QA tester treba znati o procesu upravljanja puštanjem i postavljanjem

what qa tester should know about release

Isprobajte Naš Instrument Za Uklanjanje Problema

Na današnjem sastanku našeg tima, menadžer je provjeravao sve na svom spremnost za izvršenje testa . Spomenuo je da će 'kôd biti spreman za osiguranje kvalitete do sutra ujutro'. Na što je mislio kad je rekao 'kôd će biti spreman', znači li to da će programeri večeras napisati kôd u QA okruženju?

Zapravo je mislio da se implementacija planira obaviti noću, a novi će kôd biti postavljen u QA okruženje na testiranje.

Mnogi od vas sada se mogu pitati, što je implementacija i što oni zapravo rade u njoj?

proces upravljanja puštanjem i raspoređivanjem za qa

Što ćete naučiti:

Sveukupni postupak upravljanja objavljivanjem i postavljanjem i važnost za QA tim

  • Zašto doista održavamo različita okruženja?
  • Kako se kôd premješta iz jednog okruženja u drugo?

U ovom ću članku pokriti sljedeće teme

  1. Zašto je važno da testeri budu svjesni postupka puštanja i postavljanja?
  2. Različita okruženja
  3. Što podrazumijevate pod Izradom i implementacijom?
  4. Planirano u odnosu na hitno raspoređivanje
  5. Kontrolni popis za osiguranje kvalitete - prije i poslije primjene

# 1. Zašto je za testere važno biti svjestan procesa implementacije?

Naš glavni posao provođenja testa ovisi o tome koliko je uspješna implementacija bila uspješna. Ako se tim za implementaciju suočio s izazovima i naišao na nekoliko problema te nije uspio pravilno rasporediti kôd, to će sigurno značiti da će QA tim identificirati puno pogrešaka koje bi mogle biti povezane s okolinom ili procesom implementacije.

  • Ako su testeri svjesni procesa raspoređivanja, shvatit će važnost izvršavanja svojih zadataka u planiranom vremenskom okviru.
  • Ispitivači će dobiti ideju je li problem stvarno programska greška ili nešto uzrokovano tijekom postavljanja, kažu da je dodijeljen tester za testiranje značajke izvješća, ali kada se pokuša prijaviti na web mjesto, vidi pogrešku što znači da je okoliš u kvaru , takva se pitanja ne mogu smatrati funkcionalnim, već okolišnim. Ako je ispitivač svjestan implementacije, problem može povezati s problemom implementacije.
  • Mnoga neispravna pitanja mogu se izbjeći ako su testeri doista svjesni popisa koji je postavljen. Ponekad se dogodi da testirate i prijavite problem za područja koja nikad nisu bila raspoređena.

# 2. Različita okruženja

Različita okruženja

U gornjoj klasifikaciji obradio sam 4 najvažnija okruženja koja slijedi većina organizacija, međutim, mnogi klijenti održavaju puno više okruženja poput postavljanja na scenu, prethodnog postavljanja itd. Također, konvencija imenovanja može se razlikovati.

  • DEV - Razvojno okruženje je ono koje je stvorio i održavao razvojni tim za pisanje koda. Pristup ovom okruženju daje samo razvojni tim. QA tim obično nema pristup ovom okruženju. Ovo okruženje Dev tim uglavnom koristi za svoje jedinstveno testiranje.
  • QA - QA okruženje je ono u kojem se testiranje zapravo i odvija. Ovo okruženje je u vlasništvu QA tima. DEV tim nema pristup ovom okruženju. Nakon završetka dizajna i kodiranja, kôd se premješta u QA okruženje kako bi QA tim proveo izvršavanje testa.
  • UAT - Test prihvaćanja korisnika je okruženje u kojem testiranje provode poslovni korisnici. To se radi nakon završetka testiranja sustava. Glavna namjera je testirati sustav s poslovnog gledišta. Pristup ovom okruženju imaju samo poslovni korisnici. Međutim, u nekim prilikama zatraže pomoć osiguranja kvalitete, u takvim okolnostima tim osiguranja osiguranja dobiva privremeni pristup okolišu.
  • PROD - PROD okruženje je stvarno živo okruženje koje je izloženo stvarnim korisnicima i nijedan od DEV i QA timova nema pristup za čitanje / pisanje u ovo okruženje. Održavaju se stalni timovi za rješavanje problema povezanih s proizvodnim okruženjem.

Također pročitajte=> Kako učinkovito pripremiti 'ispitni ležaj' i umanjiti nedostatke testnog okruženja

# 3. Što podrazumijevate pod Izgradnjom i implementacijom

Izgradnja uglavnom sadrži kompajlirani paket koji može sadržavati izvršnu datoteku bat, exe, biblioteke poput dll, lib i arhive poput zip datoteka. Razvojni tim kreira izgradnju i pruža je timu za postavljanje na instalaciju.

Za sastavljanje izvornog koda uglavnom se brine razvojni tim i nakon što generiraju gradnju, smještaju je na neko određeno mjesto kojemu tim za implementaciju može pristupiti za postavljanje u drugo okruženje.

Jednom kada je gradnja implementirana, QA tim se obavještava da izvrši testiranje provjere gradnje (BVT) i ako je uspješan, tim izvodi ostatak funkcionalno ispitivanje .

U nekoj organizaciji u kojoj ne održavaju zasebni tim za implementaciju, razvojni tim osigurava izgradnju QA-a, a QA tim sam dovršava implementaciju. Uključen je veliki rizik, u takvim slučajevima resursi osiguranja kvalitete trebali bi biti tehnički ispravni kako bi razumjeli cjelokupni proces implementacije gradnje, a također bi trebali znati kako sanirati problem u slučaju.

Građevine se održavaju pomoću brojeva recimo 1.0.01 ili 1.0.03. Dakle, moguće je da verzija 1.0.01 možda ima DLL v0.2, a verzija 1.0.03 DLL v0.5. Za QA tim postaje važno osigurati da se ispravna izrada implementira u okruženje prije početka testiranja. Uvijek je dobra evidencija o promjenama navedenim kao dio svake gradnje.

Održavanje odvojenog tima za implementaciju uvijek je dobra praksa jer pomaže glatkom premještanju koda iz jednog okruženja u drugo.

Implementacija je postupak kroz koji se kod / gradnja premješta iz jednog okruženja u drugo. Većina organizacije ovih dana slijedi odgovarajući kanal za raspoređivanje i održava zaseban tim koji se brine o svemu tome.

Izgradnja i implementacija

Prije dana postavljanja sastaje se tim koji se sastoji od programera, voditelja razvoja, inženjera implementacije, voditelja ispitivanja i ostalih poslovnih dionika. Na sastanku se od programera obično traži da opiše svoju promjenu. Obično trebaju ispuniti određeni obrazac s detaljima o promjenama i planu povratka.

U slučaju da se propuste neki detalji, promjene ne dobivaju odobrenje za primjenu. Tada tim odlučuje može li promjena biti dio uvođenja sljedećeg dana. Mole se QA Test Lead za odobrenje kako bi se osiguralo da promjena neće utjecati na bilo koji od postojećih testova. Na sastanku su planirane konačne stavke raspoređivanja.

Odobreni popis obrađuje tim za raspoređivanje na dan raspoređivanja. Tim izvodi skup programa kako je definirano u svakom od obrazaca promjena (koje pružaju programeri), a zatim šalje komunikaciju kao završenu implementaciju.

Poruka Deployment Complete dokazuje QA timu da su promjene / novi kôd spremni za testiranje.

Odgovornost je tima za implementaciju da premjesti promjene s DEV-a na QA. Nakon završetka QA testiranja, kôd se premješta u UAT. Premještanje podataka PROD-a najvažniji je dio i to se mora raditi izvan radnog vremena, jer tijekom implementacije treba srušiti okoliš i to s najvećom pažnjom, jer bi to moglo imati ozbiljan utjecaj na poslovanje.

Većina implementacija Proda obavlja se kasno navečer kada su šanse da krajnji korisnici ugroze okoliš manje.

# 4. Planirano u odnosu na hitno raspoređivanje

Svaka organizacija održava kalendar raspoređivanja. Mnogi kupci prate primjenu jednom u tjednu, a mnogi odlaze na dvotjednik, kažu da bi se planirano postavljanje trebalo dogoditi samo utorkom ili se može dogoditi u utorak i petak. Dani raspoređivanja mogu se promijeniti ako planirani dan raspoređivanja padne na praznik.

U gornjem odjeljku opisao sam postupak koji se slijedi za bilo koji planirano raspoređivanje .

Planirana raspoređivanja mogu imati vlastiti izazov. Sjetite se slučaja kada se novi kôd postavlja u QA okruženje i tijekom testa ispravnosti tima utvrdi kvar blokera i testiranje mora biti zaustavljeno. Čeka li ispitni tim tjedan dana do sljedeće implementacije?

Da bi se riješile takve situacije, izvršavaju se hitna popravljanja i postavljanja tamo gdje tim za postavljanje ne treba čekati planirani dan raspoređivanja. Moraju slijediti i tražiti odobrenje čak i za hitne implementacije, ali ta se odobrenja obično događaju brzo, a nove promjene mogu se primijeniti na QA okruženje istog dana ili što je prije moguće.

# 5. Kontrolni popis za osiguranje kvalitete - prije i poslije primjene

Prije postavljanja -

Cijela faza izrade testa odvija se prije nego što se kôd stvarno premjesti u okruženje. Izvršenje testa ovisi o dostupnosti koda u QA okruženju, dok tim za implementaciju radi na postavljanju koda u QA, QA tim bi trebao osigurati da dovrši dolje navedene aktivnosti -

Nakon raspoređivanja -

Nakon implementacije, prvo što mi kao QA tim radimo je da započnemo s našim Sanity testom. Ali prije nego što započnemo test zdrave razumnosti, trebali bismo se pobrinuti za sljedeće:

što je mrežni sigurnosni ključ na usmjerivaču
  • QA tim trebao je primiti obavijest od tima za implementaciju o uspješnoj implementaciji i biti spreman za QA.
  • QA tim trebao bi voditi evidenciju o postavljenoj gradnji.
  • Provjerite ima li QA tim popis promjena koje su uspješno postavljene, kao i stavki koje nisu postavljene, čak i ako su planirane. Može se dogoditi da se tim za implementaciju nije mogao rasporediti zbog nedostajućih detalja itd.

Zaključak

Nadam se da vam je gornji članak dao ideju o ukupnom procesu upravljanja izdavanjem i implementacijom koji je slijedio kao dio ukupnog ciklusa razvoja softvera. Ovo je bio samo generički postupak koji se slijedio u većini organizacija, međutim mnogi kupci imaju različite protokole.

Autor : Ovaj sjajni članak napisala je članica STH tima Priya R.

Je li vam ovaj postupak bio koristan? Obavijestite nas o procesu implementacije koji slijedite u svojoj organizaciji.

Preporučena literatura

^