Meny

Hva QA Tester bør vite om prosess for frigjøring og distribusjon

what qa tester should know about release

Prøv Instrumentet Vårt For Å Eliminere Problemer

På teammøtet vårt i dag sjekket lederen med alle på deres beredskap for testutførelse . Han nevnte at 'koden vil være klar for kvalitetssikring i morgen morgen'. Hva mente han da han sa 'code will be ready', betyr det at utviklerne skal skrive koden i QA-miljø i kveld?

Han mente faktisk at distribusjonen er planlagt å bli gjort om natten, og den nye koden vil bli distribuert til QA-miljøet for testing.

Mange av dere kan nå spørre, hva distribusjon er og hva gjør de egentlig i det?

frigjørings- og distribusjonsadministrasjonsprosess for qa

Hva du vil lære:

Overordnet frigjørings- og distribusjonsstyringsprosess og viktighet for QA-teamet

  • Hvorfor opprettholder vi virkelig forskjellige miljøer?
  • Hvordan migrerer koden fra et miljø til et annet?

Jeg vil dekke følgende emner i denne artikkelen

  1. Hvorfor er det viktig for testere å være klar over frigjørings- og distribusjonsprosessen?
  2. Ulike miljøer
  3. Hva mener du med Bygg og distribusjon?
  4. Planlagt mot nødutplassering
  5. QA Sjekkliste - Før og etter distribusjon

#1. Hvorfor er det viktig for testere å være klar over distribusjonsprosessen?

Vår viktigste jobb med testutførelse avhenger av hvor vellykket distribusjonen var. Hvis distribusjonsteamet møtte utfordringer og opplevde flere problemer og ikke kunne distribuere koden ordentlig, vil det helt sikkert indikere at QA-teamet kommer til å identifisere mange feil som kan være knyttet til miljøet eller distribusjonsprosessen.

manuelle tester intervju spørsmål for erfarne
  • Hvis testere er klar over distribusjonsprosessen, vil de forstå viktigheten av å fullføre oppgavene sine innen den planlagte tidsrammen.
  • Testere vil få en ide om problemet egentlig er en funksjonalitetsfeil eller noe som er forårsaket under distribusjonen, si at en tester er tildelt for å teste rapportfunksjonen, men når han prøver å logge på nettstedet, ser han en feil som betyr at miljøet er nede , slike problemer kan ikke betraktes som funksjonelle spørsmål, men som miljømessige. Hvis testeren er klar over distribusjonen, kan han forholde seg til problemet som et distribusjonsproblem.
  • Mange ikke-problemer kan unngås hvis testerne virkelig er klar over listen som ble distribuert. Noen ganger skjer det at du tester og rapporterer et problem for områder som aldri ble distribuert.

# 2. Ulike miljøer

Ulike miljøer

I ovennevnte klassifisering har jeg dekket de 4 viktigste miljøene som de fleste organisasjoner følger, men mange klienter opprettholder mange flere miljøer som iscenesettelse, forhåndsinnsetting osv. Også navnekonvensjonen kan variere.

  • DEV - Utviklingsmiljø er det som er opprettet og vedlikeholdt av utviklingsteamet for å skrive koden. Tilgangen for dette miljøet gis kun til utviklingsteamet. Vanligvis har ikke QA-teamet tilgang til dette miljøet. Dette miljøet brukes mest av Dev-teamet for enhetstesting.
  • QA - QA-miljø er det der testingen faktisk finner sted. Dette miljøet eies av QA-teamet. DEV-teamet har ikke tilgang til dette miljøet. Etter at design og koding er fullført, flyttes koden til QA-miljø for at QA-teamet skal kunne utføre test.
  • UAT - Test av brukeraksept er et miljø der testingen utføres av forretningsbrukerne. Dette gjøres etter at systemtesten er fullført. Hovedintensjonen er å teste systemet fra forretningsmessig synspunkt. Tilgang til dette miljøet gis kun til forretningsbrukerne. Imidlertid, ved noen anledninger søker de QA-hjelp, i slike tilfeller får QA-teamet midlertidig tilgang til miljøet.
  • PROD - PROD-miljøet er det faktiske live-miljøet som blir utsatt for de virkelige brukerne, og ingen av DEV- og QA-teamene har lese- / skrivetilgang til dette miljøet. Prod support support team blir vedlikeholdt for å løse problemer relatert til produksjonsmiljøet.

Les også=> Slik klargjør du effektivt “Test Bed” og minimerer testmiljøfeilene

# 3. Hva mener du med Bygg og distribusjon

En build inneholder hovedsakelig den kompilerte pakken som kan inkludere den kjørbare bat, exe, bibliotekene som dll, lib og arkiver som zip-filer. Utviklingsteam oppretter bygningen og leverer den til distribusjonsteamet for installasjon.

Kompilering av kildekoden ivaretas hovedsakelig av utviklingsteamet, og etter at de har generert bygningen, plasserer de den på et bestemt sted som er tilgjengelig for distribusjonsteamet for distribusjon til et annet miljø.

Når bygningen er distribuert, får QA-teamet beskjed om å gjøre det bygge verifiseringstesting (BVT), og hvis det lykkes, utfører teamet resten av funksjonstesting .

I noen organisasjoner der de ikke har et eget distribusjonsteam, gir utviklingsteamet bygningen til QA, og QA-teamet fullfører distribusjonen. Det er en stor risiko involvert. I slike tilfeller bør kvalitetsressurser være teknisk sunne for å forstå den generelle distribusjonsprosessen for byggingen, og de bør også vite hvordan de kan rette opp hvis et problem oppstår.

Bygninger vedlikeholdes ved hjelp av tallene si 1.0.01 eller 1.0.03. Så det er mulig at build 1.0.01 kan kjøre DLL v0.2 og build 1.0.03 kan kjøre DLL v0.5. Det blir viktig for QA-teamet å sikre at riktig bygging blir distribuert i miljøet før testingen starter. Det er alltid en god ide å holde oversikt over endringene som blir gitt som en del av hver versjon.

Det er alltid en god praksis å opprettholde et eget distribusjonsteam, da det hjelper til jevn bevegelse av kode fra et miljø til et annet.

Distribusjon er en prosess der koden / bygningen flyttes fra ett miljø til et annet. Det meste av organisasjonen i disse dager følger en skikkelig kanal for distribusjonen, og har et eget team som tar seg av alle disse.

Bygg og distribusjon

fase av livssyklus for programvareutvikling

Før dagen for distribusjonen møtes et team bestående av utvikler, utviklingsleder, distribusjonsingeniør, testleder og andre interessenter. I møtet blir utvikleren vanligvis bedt om å beskrive endringen sin. De må vanligvis fylle ut et bestemt skjema med detaljer om endringene og tilbakeføringsplanen.

Hvis noen detaljer blir savnet, blir ikke endringene godkjent for distribusjon. Teamet bestemmer deretter om endringen kan være en del av distribusjonen neste dag. QA Test Lead blir bedt om godkjenning for å sikre at endring ikke vil påvirke noen av de eksisterende testene. I møtet planlegges de endelige distribusjonselementene.

Den godkjente listen blir arbeidet med av distribusjonsteamet på dagen for distribusjonen. Teamet kjører et sett med programmer som definert i hvert av endringsskjemaet (levert av utviklere) og sender deretter ut kommunikasjonen når distribusjonen er fullført.

Meldingen Deployment Complete gir en indikasjon til QA-teamet om at endringene / den nye koden er klar til å bli testet.

Det er distribusjonsteamets ansvar å flytte endringene fra DEV til QA. Etter at QA-testen er fullført, flyttes koden til UAT. PROD-dataflytting er den viktigste delen, og det må gjøres i stengt tid, fordi miljøet må bringes ned under utrullingen, og det må gjøres med største forsiktighet, siden dette kan ha alvorlig innvirkning på virksomheten.

De fleste av Prod-distribusjonene blir gjort sent på kvelden når sjansen for at miljøet blir rammet av sluttbrukerne er mindre.

# 4. Planlagt mot nødutplassering

Hver organisasjon har en distribusjonskalender. Mange kunder følger distribusjonen en gang i uken, og mange går to ganger i uken, og sier at den planlagte distribusjonen bare skal skje på tirsdager, ellers kan det skje på tirsdag og fredag. Dagene for distribusjon kan endres hvis den planlagte dagen for distribusjon faller på ferie.

I avsnittet ovenfor har jeg dekket prosessen som følges for alle planlagt utplassering .

De planlagte distribusjonene kan ha sin egen utfordring. Tenk på et tilfelle der ny kode distribueres til QA-miljøet og under fornuftstest, identifiserer teamet en blokkeringsfeil, og testing må stoppes. Venter testteamet i en uke til neste distribusjon?

For å håndtere slike situasjoner gjøres beredskap og distribusjoner der distribusjonsteamet ikke trenger å vente til den planlagte distribusjonsdagen. De trenger å følge og søke godkjenning selv for nødutplasseringer, men disse godkjenningene skjer vanligvis raskt, og de nye endringene kan distribueres til QA-miljø samme dag eller så snart som mulig.

# 5. QA Sjekkliste - Før og etter distribusjon

Før distribusjon -

Hele testdesignfase finner sted før koden faktisk flyttes til miljøet. Det er testutførelsen som avhenger av tilgjengeligheten av koden i QA-miljøet mens distribusjonsteamet jobber med å få koden distribuert i QA, og QA-teamet bør sørge for å ha fullført aktivitetene nedenfor -

  • Forsikre deg om at testtilfellene blir gjennomgått og godkjent
  • Sørg for at testteamet er tilgjengelig og ressursplanleggingen er fullført
  • Sørg for at testdata behov er identifisert

Etter distribusjon -

nettverksingeniør intervju spørsmål 250 + spørsmål og svar forklart pdf

Etter distribusjon er det aller første vi som QA-team gjør, å komme i gang med Sanity-testen. Men før vi begynner vår sunnhetsprøve, bør vi forsikre oss om at følgende er ivaretatt -

  • QA-teamet burde ha mottatt varsel fra distribusjonsteamet om vellykket distribusjon og klar for QA.
  • QA-teamet bør holde oversikt over den distribuerte bygningen.
  • Forsikre deg om at QA-teamet har listen over endringer som er vellykket distribuert, og også av gjenstander som ikke er distribuert selv om de var planlagt. Det kan hende at distribusjonsteamet ikke kunne distribuere på grunn av manglende detaljer etc.

Konklusjon

Håper artikkelen ovenfor ga deg en ide om den totale frigjørings- og distribusjonsadministrasjonsprosessen som ble fulgt som en del av den samlede programvareutviklingssyklusen. Dette var bare en generell prosedyre som ble fulgt i de fleste organisasjoner, men mange kunder har forskjellige protokoller.

Forfatter : Denne fantastiske artikkelen er skrevet av STH-teammedlem Priya R.

Fant du denne prosessen nyttig? Gi oss beskjed om distribusjonsprosessen du følger i organisasjonen din.

Anbefalt lesing

^