Meny

Praktisk programvaretesting av QA-prosessflyt (krav til utgivelse)

practical software testing qa process flow

Prøv Instrumentet Vårt For Å Eliminere Problemer

En komplett oversikt over end-to-end QA-programvaretestprosessflyt:

Merk - Vi publiserer dette nyttige innlegget på nytt med oppdatert innhold.

Jobben med profesjonell programvaretesting er ikke lett. Den er fylt med utfordringer, som også er krevende. Testere skal være våken og entusiastiske i hver eneste fase av applikasjonens livssyklus.

Selv om det er utfordringer, er det flere enorme muligheter for å lære og utforske de forskjellige aspektene ved testmetoder, prosesser og selvfølgelig programvaren i detalj.

Rollen som testingeniør begynner veldig tidlig. Og rett fra konseptualiseringen av prosjektet er testere involvert i diskusjoner med produkteier, prosjektleder og ulike interessenter.

Krav til frigjøring

Denne opplæringen om “Software Testing Process flow” gir deg en fullstendig oversikt over de forskjellige fasene i STLC sammen med utfordringene som er involvert, og den beste fremgangsmåten for å løse disse utfordringene på en lett forståelig måte.

Hva du vil lære:

Krav om frigjøring - En komplett oversikt

Programvare Testing livssyklus

Rett fra krav til frigjøring blir hver fase tydelig forklart. La oss se nærmere på dem.

# 1) Krav

Et prosjekt kan ikke ta av uten å ha et klart krav. Dette er den mest avgjørende fasen hvor ideer trenger å bli skrevet i et godt forståelig og formatert dokument. Hvis du er en del av prosjektet der du deltar i kravinnsamlingsfasen, så vær så heldig.

youtube video downloader app for pc

Lurer du på hvorfor? Det er fordi du er vitne til et prosjekt i å lage fra bunnen av. Selv om det er stolthet å være siden oppstarten, kommer det også med noen ansvar og utfordringer.

Utfordringer

Man kan ikke forestille seg alle kravene for å samles i en enkelt sitting. Vær tålmodig nok.

Mange diskusjoner vil skje, hvorav noen ganske enkelt er irrelevante for prosjektet ditt, men selv da kan de inneholde viktig informasjon for prosjektet ditt. Noen ganger kan hastigheten på diskusjonene overstige dine forståelsesevner, ellers vil du rett og slett ikke ta hensyn til produktseieren.

Bildet nedenfor viser de viktige trinnene som er involvert i kravinnsamlingen:

Krav LifeCycle

Hver informasjon du savner har stor innvirkning på den samlede forståelsen og testingen av prosjektet. For å få bukt med dette, er det noen gode fremgangsmåter som bør følges i løpet av denne fasen.

Beste praksis

  • Hold tankene åpne og vær oppmerksom på hvert ord fra produkteieren.
  • Ikke bare lytt, fjern tvilen din, uansett hvor liten den ser ut til å være.
  • Bruk alltid notatbøker for rask notatføring. Du bør bruke en bærbar datamaskin, bare hvis du virkelig kan skrive i en rimelig hastighet.
  • Gjenta setningene og få dem avklart fra PO som du tror er det du forsto.
  • Tegn blokkdiagrammer, lenketekst osv. For å gjøre kravene tydeligere senere.
  • Hvis lagene er forskjellige steder, kan du prøve å gjøre det til et WebEx eller lignende opptak. Det vil alltid hjelpe når du er i tvil etter at diskusjonene er over.

Selv om det ikke er noen egen vegg som sådan for hver eneste fase, endres kravene til og med veldig sent i utviklingen. Så ideen er å ta tak i mesteparten av kravet og dokumentere dette ordentlig.

Når det er dokumentert med alle nødvendige punkter, distribuer og diskuter alle interessentene slik at eventuelle forslag eller endringer blir fanget tidlig, og før du går videre, er alle på samme side.

# 2) Teststrategi

Testere skal ut med en teststrategi som ikke bare er tilstrekkelig til å teste programvaren bedre, men som også skal gi tillit til alle interessenter når det gjelder kvaliteten på produktet.

Teststrategi

Utfordringer

Det mest avgjørende ved denne fasen er å lage en strategi som når det jobbes med skal levere et programvareprodukt som er feilfritt, bærekraftig og akseptert av sluttbrukerne.

Teststrategier er noe du ikke vil endre annenhver dag. I noen tilfeller må du også diskutere teststrategiene dine med kundene. Så denne delen skal behandles med stor betydning.

Beste praksis

  • Her er noen av de beste metodene, som når de følges kan gi deg stor lettelse og resultere i jevn testing.
  • Gå gjennom kravdokumentet igjen. Fremhev importpunktene med hensyn til miljøet til målprogramvaren.
  • Lag en liste over miljøer der programvaren faktisk blir distribuert.
  • Miljøer kan forstås som en type operativsystemer eller mobile enheter.
  • Hvis Windows er operativsystemet, kan du liste opp alle versjonene av vinduet der du skal teste programvaren. Hvis versjonene nemlig. Windows 7, Windows 10 eller Windows Server (er) er fremdeles ikke definert i kravdokumentet, da er det på høy tid når disse skal diskuteres.
  • På et lignende notat, få målleserne med versjonene diskutert og dokumentert hvis AUT er et nettbasert system.
  • Lag en liste over alle tredjepartsprogramvarene som applikasjonen trenger (hvis nødvendig / støttet). Disse kan omfatte Adobe Acrobat, Microsoft Office, eventuelle tilleggsprogrammer, etc.

Her er tanken bak å holde alle nødvendige og nødvendige plattformer, enheter og programvare som applikasjonen vår trenger å fungere foran oss slik at en omfattende strategi kan formuleres.

Figuren nedenfor hjelper deg med å forstå oversikten over teststrategi hvis du jobber med et smidig prosjekt:

Testing Strategi

# 3) Testplanlegging

Etter at testerne er bevæpnet med all informasjon om AUT, er planleggingsfasen der strategien implementeres.

Som en teststrategi er også testplanlegging en avgjørende fase.

Testplan

Utfordringer

Siden suksessen (eller feilen) til AUT i stor grad avhenger av hvordan testene ble utført, blir denne fasen et viktig aspekt av hele testens livssyklus. Hvorfor? Fordi en del av testingen er definert i denne fasen.

For å overvinne noen utfordringer kan disse beste metodene virkelig være nyttige.

Beste praksis

  • Husk alltid, ikke la noen stein være upåvirket når det gjelder å teste søknaden din.
  • Det er på tide å formulere en teststrategi.
  • Lag en matrise av miljøet slik at programvaren blir testet på alle plattformer.
  • Som, Windows 10 + Internet Explorer 11+ Windows Office 2010+.
  • Som Android 4.2.2+ Chrome-nettleser.
  • Hvis applikasjonen din fungerer med flere databaser (hvis dokumentert), hold databasene (MySQL, Oracle, SQLServer) i testmatrisen på en slik måte at de er for integrerte med noen tester.
  • Konfigurer testmaskiner deretter og navngi dem som SetUp1, SetUp2, etc.
  • SetUp1 vil ha Windows 7+ IE 10+ Office 2007+.
  • SetUp2 kan ha Windows 10+ IE Edge + Office 2013+.
  • SetUp3 kan ha en Android-telefon med .apk-filen din installert.
  • Gratulerer! Testoppsettet ditt er klart, og du har også tatt med alle mulige kombinasjoner av plattformer som applikasjonen din vil jobbe med.

# 4) Testing

Finne bugs

Endelig er applikasjonsbyggingen ute, og du er klar til å finne feil! Nå er det på tide å jobbe med testplanlegging og finne så mange feil som mulig. Det vil være noen faser i mellom hvis du jobber i et smidig miljø, så følg bare disse scrummetodene.

Diagrammet nedenfor viser kategoriseringen av forskjellige testtyper:

Typer testing

Utfordringer

Testing er en tungvint prosess som i seg selv er utsatt for feil! Man finner mange utfordringer mens man tester en applikasjon. Nedenfor er noen gode fremgangsmåter for å redde.

Beste praksis

Opp med humøret! Du prøver å finne feil i koden. Du må ta hensyn til den generelle bruken av programvaren.

  • Det er alltid tilrådelig å se på applikasjonen med et nytt utseende, UTEN Å GJENNOM TESTSAKER.
  • Følg navigasjonsstien til programvaren din (AUT).
  • Gjør deg kjent med AUT.
  • Les nå testtilfellene (Alle) til en bestemt modul (kanskje etter eget valg).
  • Gå nå til AUT og matche funnene med de som er nevnt i den forventede delen av testsakene.
  • Ideen bak dette er å teste alle nevnte funksjoner på alle støttede plattformer.
  • Noter hvert avvik, uansett hvor trivielt det ser ut til å være.
  • Skriv ned trinnene for hvordan du når et eventuelt avvik, tar skjermbilder, fanger feillogger, serverlogger og annen støttedokumentasjon som kan bevise at det er feil.
  • Ikke nøl med å spørre. Selv om du har kravdokumentet, vil det være tider når du er i tvil.
  • Ta kontakt med utviklerne (hvis de sitter ved siden av deg eller hvis de er tilgjengelige) i tvil før du tar kontakt med produkteieren. Forstå utviklerens perspektiv på hvordan programvaren fungerer. Forstå dem. Hvis du føler at denne implementeringen ikke er i samsvar med kravet, så informer testlederen.

# 5) Før løslatelse

Før vi slipper noe produkt på markedet, må kvaliteten på produktet sikres. Programvare er utviklet en gang, men de er faktisk testet til de byttes ut eller fjernes.

Utfordringer

Programvaren må testes grundig for mange av parametrene.

Parametrene er kanskje ikke begrenset til:

  • Funksjonalitet / atferdsmessig.
  • Opptreden.
  • Skalerbarhet.
  • Kompatibel med de nevnte plattformene.

Utfordring er også å forutsi suksessraten for en applikasjon, som avhenger av mange iterasjoner av utførte tester.

Beste praksis

  • Forsikre deg om at alle funksjonene på alle plattformene er testet.
  • Fremhev områdene som ikke er testet, eller det som trenger mer testing.
  • Hold en matrise av alle testresultatene før utgivelsen. Testmatrisen vil gi et samlet bilde av produktets stabilitet. Det vil også hjelpe ledelsen å ringe på utgivelsesdatoene.
  • Gi dine innspill / forslag til teamet om dine erfaringer mens du tester produktet.
  • Innspillene dine som vurderer deg selv som sluttbruker, vil være til fordel for programvaren.
  • På grunn av tidsklemme eller andre situasjoner, går vi enten glipp av noen tester eller går ikke dypt inn i dette. Ikke nøl med å fortelle teststatusen til lederen din.
  • Presentere helsekortet for søknaden til interessentene. Helsekort skal ha et antall av alle loggede, åpne, lukkede, intermitterende feil med alvorlighetsgrad og prioritet.
  • Lag et utgivelsesdokument og del dette på tvers av teamet.
  • Arbeid med utgivelsesdokumentet utarbeidet.
  • Forbedre områdene som er foreslått av ledelsen / teamet.

Bildet nedenfor viser livssykluskart for programvareutgivelse:

Før løslatelse

# 6) Slipp

Til slutt kommer tiden da vi må levere produktet til de tiltenkte brukerne. Vi som team har alle jobbet hardt for å logge av produktet og la programvaren hjelpe brukerne.

Utfordringer

Programvaretestingeniører er primært ansvarlige for utgivelsen av programvare. Denne aktiviteten krever en prosessorientert arbeidsflyt. Her er noen av de beste metodene som er involvert i denne fasen.

Beste praksis

  • Husk alltid at du ikke jobber med utgivelsesdokumentet på datoen for FAKTISK RELEASE.
  • Planlegg alltid utgivelsesaktiviteten før den faktiske utgivelsesdatoen.
  • Standardiser dokumentet i henhold til selskapets policyer.
  • Utgivelsesdokumentet ditt bør prøve å etablere positive forventninger fra programvaren.
  • Nevn alle programvare- og maskinvarekrav som er spesifikke for versjonene tydelig i dokumentet.
  • Inkluder alle åpne feil og alvorlighetsgraden.
  • Ikke skjul større påvirkede områder på grunn av åpne feil. Gi dem en plass i utgivelsesdokumentet.
  • Få dokumentet gjennomgått og digitalt signert (kan variere i henhold til selskapets policy).
  • Vær trygg og send utgivelsesdokumentet sammen med programvaren.

QA-testprosess på et ekte prosjekt - Fossemetode

Jeg fikk et interessant spørsmål fra en leser, Hvordan utføres testing i et selskap, dvs. i et praktisk miljø?

De som bare går ut av college og begynner å søke etter jobber, har denne nysgjerrigheten - hvordan ville det faktiske arbeidsmiljøet i et selskap være?

Her har jeg fokusert på selve arbeidsprosessen til Programvaretesting i selskapene .

Faktisk testprosess i selskaper

Hver gang vi får et nytt prosjekt, er det et første prosjektfamiliemøte. I dette møtet diskuterer vi i utgangspunktet hvem som er klienten? hva er prosjektets varighet, og når leveres det? Hvem er alle involvert i prosjektet, dvs. leder, Tech leads, QA leads, utviklere, testere, etc.?

Fra SRS (programvarekravspesifikasjon) utvikles prosjektplanen. Testernes ansvar er å lage en programvaretestplan fra denne SRS og prosjektplanen. Utviklere begynner å kode fra designet. Prosjektarbeidet er delt inn i forskjellige moduler, og disse prosjektmodulene fordeles mellom utviklerne.

I mellomtiden er det en testers ansvar å lage et testscenario og skrive testsaker i henhold til de tildelte modulene. Vi prøver å dekke nesten alle funksjonelle testtilfeller fra SRS. Dataene kan opprettholdes manuelt i noen excel test case maler eller bug tracking verktøy.

Når utviklere er ferdige med de enkelte modulene, tildeles disse modulene testerne. Røykprøving utføres på disse modulene, og hvis de ikke klarer denne testen, tildeles modulene til de respektive utviklerne for å fikse.

For beståtte moduler utføres manuell testing fra de skriftlige prøvesakene. Hvis det blir funnet en feil som blir tildelt modulutvikleren og blir logget inn i feilsporingsverktøy . Ved feilretting utfører en tester feilbekreftelse og regresjonstesting av alle relaterte moduler. Hvis feilen godkjennes, er den merket som bekreftet og merket som lukket. Ellers blir ovennevnte bugsyklus gjentatt. (Jeg vil dekke feilens livssyklus i et annet innlegg)

Ulike tester utføres på individuelle moduler og integrasjonstesting på modulintegrasjon. Disse testene inkluderer kompatibilitetstesting, dvs. testing av applikasjoner på forskjellige maskinvare, OS-versjoner, programvareplattformer, forskjellige nettlesere osv.

Belastning og stresstesting utføres også i henhold til SRS. Til slutt utføres systemtesting ved å skape et virtuelt klientmiljø. Når alle testtilfellene er utført, utarbeides en testrapport og beslutningen om å frigjøre produktet!

Fremgangsmåte for å frigjøre

Nedenfor er detaljene i hvert testtrinn som utføres i hver programvarekvalitet og testlivssyklus spesifisert av IEEE og ISO-standarder.

#1) SRS gjennomgang : Gjennomgang av spesifikasjonene for programvarekrav.

# 2) Mål er satt for store utgivelser.

# 3) måldato planlagt for utgivelsene.

# 4) Detaljert prosjektplan er bygd. Dette inkluderer beslutningen om designspesifikasjoner.

# 5) Utvik testplan er basert på designspesifikasjoner.

# 6) Testplan: Dette inkluderer mål, metodikken som er benyttet under testing, funksjoner som skal testes og ikke skal testes, risikokriterier, testplan, støtte for flere plattformer og ressurstildeling for testing.

# 7) Testspesifikasjoner: Dette dokumentet inneholder tekniske detaljer (programvarekrav) som kreves før testing.

# 8) Skriving av testsaker

# 9) Utvikling: Moduler er utviklet en etter en.

# 10) Binding av installatører: Installatører er bygget rundt det enkelte produkt.

hvordan åpner jeg en eps-fil

#elleve) Bygg prosedyre : En build inkluderer installatører av tilgjengelige produkter - flere plattformer.

# 12) Testing: Smoke Test (BVT): Grunnleggende applikasjonstest for å ta en beslutning om videre testing.

  • Testing av nye funksjoner
  • Tverrleser og testing på tvers av plattformer
  • Stresstesting og minnelekkasjetesting.

# 1. 3) Testoversiktsrapport

# 14) Kode frysing

  • Ingen flere nye funksjoner er lagt til på dette tidspunktet.

# 15) Testing: Testing av bygg og regresjon.

# 16) Beslutning om å frigjøre produktet.

# 17) Scenario etter utgivelsen for ytterligere mål.

Dette var et sammendrag av en faktisk testprosess i et bedriftsmiljø.

Konklusjon

Jobben til en programvaretester er full av utfordringer, men likevel en hyggelig. Dette er for noen som er like lidenskapelige, motiverte og full av entusiasme. Å finne feil hos noen er ikke alltid en enkel jobb! Dette krever mange ferdigheter og et øye med manglene.

Foruten alle kvalitetene, bør en tester også være prosessorientert. I likhet med alle andre næringer er prosjekter innen IT forarbeidet i faser, der hver fase har noen veldefinerte mål. Og hvert mål har et veldefinert akseptkriterium. En testingeniør må bære mange mengder programvarekvalitet på skuldrene.

Mens de arbeider i en hvilken som helst fase av programvaren, skal testere følge de beste fremgangsmåtene og bør tilpasse seg prosessen som er involvert i de respektive fasene. Ved å følge den beste fremgangsmåten og den velformulerte prosessen, hjelper det ikke bare å lette testernes arbeid, det hjelper også med å sikre kvaliteten på programvaren.

Har du vært en del av noen av de ovennevnte fasene? Del gjerne dine erfaringer nedenfor.

Anbefalt lesing

^