what is impact analysis software testing
Denne opplæringen forklarer hva som er konsekvensanalyse, fordelene, hvordan du gjennomfører den og hvordan du forbereder dokument for konsekvensanalyse:
Som vi vet har teknologi både positive og negative påvirkninger på samfunnet. Alle enkle endringer kan påvirke systemet. Selv en veldig liten endring kan ha stor innvirkning på systemet.
I denne opplæringen vil vi forstå konsekvensanalysen i detalj, og vil også se noen trinn for å utarbeide konsekvensanalysedokumenter.
La oss forstå viktigheten av denne analysen ved hjelp av et ER-diagram (Entity Relationship).
Hva du vil lære:
Betydningen av konsekvensanalyse
Vurder ER-diagrammet til Department Shop Management System. Vi ønsker å redigere dette datamodelldiagrammet ved å gi nytt navn til 'Item' -modulen til 'Product' -modulen. Fra fig. Nr. 01 kan vi se at 'Item' modulen er i forhold til mange andre moduler. Så hvis vi endrer navnet på 'Element'-modulen, vil det uunngåelig påvirke andre moduler.
Fig. Nr. 01: Management Shop System
Så før vi gjør slike endringer, må vi analysere godt om datamodellen og effekten av endringene. I tilfeller der de berørte ikke tenker nøye over konsekvensene av endringene de skal gjøre i modulene, kan det påvirke riktig bruk av selve applikasjonen. Dette er grunnen til at konsekvensanalyse er veldig viktig.
Merk: Denne analysen viser den uventede oppførselen og alle bivirkningene av applikasjonen.
Hva er konsekvensanalyse?
Det innebærer å analysere virkningen av endringer gjort i funksjoner / moduler i applikasjonen. Det kan gjøres på nesten alle trinn i livssyklusen for programvareutvikling, for eksempel prosjektkrav, systemdesign, koding, testing osv.
- Analysere moduler ved hjelp av konsekvensanalysedokumenter. Den vil finne risikoen forbundet med alle slags endringer i en modul / et produkt.
- Det hjelper i estimeringen av teaminnsats som er nødvendig for å produsere endringer i systemet.
- Det hjelper også å implementere en prototype for utviklere og testere for å oppleve effektene i systemet.
Hvordan gjennomføre en effektiv konsekvensanalyse?
Nedenfor er trinnene som er utført for å gjennomføre analysen for et prosjekt:
- Forbered et team.
- Inspiser moduler på høyt nivå.
- Inspiser moduler på lavt nivå.
- Evaluer innvirkningen.
- Administrer negative konsekvenser.
Trinn 1Forbered et team
Før vi gjør endringer i modulene i applikasjonen, må vi ha et team. Teammedlemmer skal ha tilgang til alle modulene i applikasjonen og må ha grundig kunnskap om de foreslåtte endringene.
Noen teammedlemmer vil ikke være klar over alle modulene. Men etter implementering av konsekvensanalyse vil alle medlemmene ha grundig kunnskap om systemet.
Steg 2Inspiser moduler på høyt nivå
Teammedlemmer analyserer først modulene på høyt nivå i applikasjonen, som kan bli berørt av de foreslåtte endringene. På dette tidspunktet må de ha bedre kunnskap om strategien og arbeidsflytreglene i modulene.
Trinn 3Inspiser moduler på lavt nivå
Etter å ha inspisert modulene på høyt nivå, vil teammedlemmer inspisere lavnivåmodulene og identifisere virkningen av endringene i den. Teammedlemmer kan utarbeide et dokument som viser virkningen av endringer i hver modul. De kan enten bruke et excel-ark eller orddokument.
Trinn 4Evaluer innvirkningen
Dokumentet utarbeidet av teammedlemmene vil avsløre listen over både positive og negative konsekvenser av endringene som er gjort. Ved hjelp av dokumentet vil teammedlemmene få en klar ide om fordelen som kan oppstå på grunn av endringen og problemene de vil møte på grunn av endringen.
Trinn 5Administrer negative konsekvenser
Akkurat nå vil teammedlemmene ha en presis ide om fordeler og ulemper med endringene. Som et resultat kan de enten godta eller nekte endringene, etter å ha diskutert det med teammedlemmene og interessentene.
Testere kan utføre regresjonstesting. Regresjonstesting hjelper deg med å gjenkjenne problemene blant modulene, som har oppstått på grunn av virkningen av endringer i dem.
Hvordan er virkningsanalysemetoden nyttig for utviklere?
I et prosjekt kan noen ganger kravet som klienten fremfører endres, selv etter at utviklingsprosessene er startet. Utviklere kan ha gjort noe koding. Senere, på grunn av endringene i kravet, må de endre kodene sine. Så utviklere redigerer kodene i henhold til kravene og foretar endringene.
Det kan være mer enn én utvikler involvert i utviklingsprosessen. I noen situasjoner er det ekstremt vanskelig å spore virkningen av endringer i forskjellige moduler, siden mer enn én utvikler forplikter kodene.
Utvikler ‘A’ kan være uvitende om arbeidsflyten i en annen modul, som håndteres av utvikler ‘B’. Så selv om testing utføres av utviklere, vil noen moduler og funksjoner forbli 'Ikke testet'. Utviklere trengte også en god sporing av delte ressurser.
I slike situasjoner kan vi gjennomføre analysemøter for programvareeffekt før vi gjør endringer i modulene. Etter møtet vil teammedlemmene utarbeide Impact Analysis-dokumentet. Den må gjenspeile de siste endringene og all risikobasert informasjon.
Etter møtet vil utviklerne være klar over alle modulene i applikasjonen. I slike møter blir hvert teammedlems meninger tatt i betraktning.
Utviklere vil vurdere hele applikasjonen / sluttproduktet før de gjør noen endringer. Testing gjort av utviklere vil være bedre. Så risikoen for å få feil i den siste fasen av utviklingen vil bli redusert.
Merk: Dokumentet om konsekvensanalyse bør holdes oppdatert.
Hvordan er virkningsanalysemetoden nyttig for testere?
Kommunikasjonen mellom utviklerne og testerne er veldig viktig. Noen ganger vil ikke testere motta varsler om endringene i kravet, og de vil fortsette testprosessen uten informasjon om endringer. Dette er bortkastet tid og ressurser.
Uten Impact Analysis-metoden vil de nye funksjonene i applikasjonen forbli ‘ikke testet’. Hvis testerne vet om de nye funksjonene som er lagt til i applikasjonen, kan de starte regresjonstesting.
Etter analysen vil testerne begynne å lage eller endre testtilfellene i henhold til endringene i kravet eller nye funksjoner som er lagt til systemet.
Merk: Denne analysen vil hjelpe testerne å bestemme områdene de skal fokusere på testing, og de kan prioritere testsakene. Dermed kan effektiviteten i testing forbedres .
Hvordan klargjøre konsekvensanalysedokument?
Alle deltakere i konsekvensmøtet vil bidra til å lage et dokument for konsekvensanalyse. Generelt er det en excel-fil. Det kan også være et orddokument.
Malen til dette dokumentet er som en matrise. Det er veldig lett å forstå. Den har høy lesbarhet. Se tabell 02 for mer informasjon.
La oss lære å utarbeide dokument for konsekvensanalyse. Et prosjekt kan inneholde mange moduler, funksjoner og funksjoner.
Tenk på et lite prosjekt som har 5 funksjoner:
youtube til mp3 converter med tag editor
- Logg Inn
- Profil
- Postkasse
- Legg til i favoritter
- Logg ut
Nedenfor (Tabell 02) er den tilsvarende Impact Analysis-tabellen for dette prosjektet.
Her representerer kolonnene modulene / funksjonene som har endret seg, og radene i matrisen representerer modulene / funksjonene som har blitt påvirket av endringene. Utviklerne vil markere () i tabellen når en endring i Feature ‘A’ påvirker Feature ‘B’; før dette dokumentet blir gitt til testere.
Egenskaper | Logg Inn | Profil | Postkasse | Legg til i favoritter | Logg ut | ||||
---|---|---|---|---|---|---|---|---|---|
............. | |||||||||
Logg Inn | | ||||||||
Profil | | ||||||||
Postkasse | | ||||||||
Legg til i favoritter | | ||||||||
Logg ut | |
Tabell nr.02
For å vise sterk innflytelse har vi brukt den RØDE fargen. Den GUL fargen brukes til å vise moderat innflytelse, GRØNN farge viser en svak innflytelse. Se tabell nr.03 for mer informasjon.
Ved å gjøre dette kan testere enkelt forstå endringene i modulene ved å se på de forskjellige fargekodene i dokumentet. Dokumentet fungerer som en sjekkliste for utviklerne, og de kan verifisere om han har gått glipp av noen modul og avhengighet.
Farger | Beskrivelse |
---|---|
Nett | Høy innflytelse |
Gul | Moderat innflytelse |
Grønn | Ukes innflytelse |
Tabell nr.03
Hvis det er en endring i innloggingsfunksjonen, vil den for det meste påvirke selve ‘påloggings’-funksjonen. Endringene i påloggingsfunksjonen kan påvirke funksjonen ‘Profil’ og ‘Logout’ litt. Dette er merket i dokumentet Impact Analysis ved hjelp av fargekoder. Så, dokumentet vil se ut som tabell nr.04
Egenskaper | Logg Inn | Profil | Postkasse | Legg til i favoritter | Logg ut |
---|---|---|---|---|---|
Logg Inn | |||||
Profil | |||||
Postkasse | |||||
Legg til i favoritter | |||||
Logg ut |
Tabell nr.04
Vi kan bruke tall for å indikere innflytelsesnivået nettopp vist i tabell nr. 05. Så, tabell nr. 04 kan tegnes på nytt som tabell nr. 06.
I tabell nr. 06 blir innloggingsfunksjonen (innflytelsesnivå: 03) gitt høyeste prioritet. Profilfunksjon (innflytelsesnivå: 02) prioriteres moderat. Avloggingsfunksjon (innflytelsesnivå: 01) blir gitt lavest prioritet.
Innflytelsesnivå | Beskrivelse |
---|---|
3. Nettverk | Sterk innflytelse |
2. Gul | Medium |
1. Grønn | Lav |
Tabell nr.05
Egenskaper | Logg Inn | Profil | Postkasse | Legg til i favoritter | Logg ut |
---|---|---|---|---|---|
Logg Inn | 3. Nettverk | 1. Grønn | 2. Gul | ||
Profil | |||||
Postkasse | |||||
Legg til i favoritter | |||||
Logg ut |
Tabell nr. 06
Merk:
hvordan du skriver en programvaretestplan
- Tallene som vises i tabellen er veldig nyttige for QA-teamet. De kan prioritere testsakene basert på tallene enkelt.
- Noen store prosjekter vil ha mer innflytelsesnivå. Det er spesifisert i tabellen nedenfor. (Sjekk tabell nr. 07 for din referanse.)
Innflytelsesnivå | Beskrivelse |
---|---|
5 | Veldig sterk |
4 | Sterk |
3 | Medium |
to | Svak |
1 | Meget svak |
Tabell nr. 07
Hvordan forbereder jeg Impact Analysis-dokumentet for et prosjekt med mange funksjoner og underfunksjoner?
Tenk på et prosjekt som har 20 funksjoner, og hvert hovedtrekk i prosjektet har fem underfunksjoner hver. Matrisen som representerer Impact Analysis-dokumentet er veldig stor og vil være vanskelig å vedlikeholde. Den tilsvarende tabellen vil se ut som tabell nr.08.
Modul | Modul 1 | Undermodul 1 | Undermodul2 | Undermodul3 | ........ | Modul 2 | Undermodul 1 | Undermodul2 | .............. |
Modul 1 | |||||||||
Undermodul 1 | |||||||||
Undermodul2 | |||||||||
............. | |||||||||
Modul 2 | |||||||||
Undermodul 1 |
Tabell nr
Så, for å løse dette problemet, kan vi bruke en spesiell tabell for å representere modulene og undermodulene i konsekvensanalysedokumentet. Se tabell nr. 09, radene representerer hovedfunksjonene, og kolonnene representerer underfunksjoner.
Undermodul 1 | Undermodul2 | Undermodul3 | Undermodul4 | Undermodul5 | |
---|---|---|---|---|---|
Modul 7 | |||||
Modul 1 | |||||
Modul 2 | |||||
Modul 3 | |||||
Modul 4 | |||||
Modul 5 |
Tabell nr.09
Ved å bruke dette dokumentet til store prosjekter, kan utviklerne enkelt merke underfunksjonene som har innvirkning på grunn av endringen i hovedfunksjonen. Lesbarheten til dette dokumentet er bedre sammenlignet medTabell nr.09.
Merk: Alle underfunksjoner vil ikke ha innvirkning på grunn av endringer i hovedfunksjonen.
Vurder nå et annet prosjekt som har 50 hovedmoduler. Prosjektet har en gruppe utviklere. Ulike utviklere jobber med forskjellige oppgaver på prosjektet (legge til nye funksjoner, feilretting, refactoring, etc.).
Vi kan vise endringene i et prosjekt ved hjelp av et Impact Analysis-dokument. Utvikleren vil skrive informasjonen om den tilsvarende endringen i tabellen. Se tabell nr. 10 og tabell nr. 11
Konfigurasjonsendringer | Kommentarer fra utvikler | Prioritet | Fremtidsplaner | |
---|---|---|---|---|
Modul 1 | Chrome-nettleser | Test ved hjelp av Chrome-nettleseren. | Feilrapport nr. 001 | |
Modul 2 | ||||
Modul 3 | ||||
Modul 4 | ||||
Modul 5 | ||||
Modul 6 |
Tabell nr.10
Varer | Beskrivelse |
---|---|
Konfigurasjonsendringer | Endringer i noen moduler / funksjoner i et prosjekt vil avhenge av hvilke enheter / miljø som brukes. Utviklere må spesifisere konfigurasjonsendringene i dokumentet slik at det blir enkelt for testerne å forstå endringene bedre. |
Kommentarer fra utviklere | Det er en av de viktigste opplysningene som trengs for testerne mens de utfører testing |
Prioritet | Testere kan enkelt prioritere testoppgaven ved hjelp av fargekoder eller tall i dokumentet |
Fremtidsplaner | Testere må være klar over utviklerens fremtidige planer. Hvis utviklerne planlegger å endre kodene etter noen uker, trenger ikke testerne å måtte teste funksjonaliteten og kaste bort tiden. Testere kan vente til utviklerne fullfører kodingsprosessen. |
Tabell nr. 11
Fordeler med konsekvensanalyse ved testing
- Korrekt: Dette dokumentet vil alltid gi nøyaktige data om endringene i moduler / funksjoner i applikasjonen.
- Økt effektivitet i testing: Ved hjelp av dette dokumentet kan testerne planlegge testsaker mer effektivt, ettersom dokumentet gir klar informasjon om endringene i modulene.
- Synkronisert arbeid: Alle teammedlemmer er ansvarlige for oppdatering av Impact Analysis-dokumentet. Dette dokumentet må være oppdatert.
- Nøyaktig: Siden dokumentet er lett lesbart, vil testere ha en klar ide om endringene i en applikasjon ved å se på dokumentet.
- Redusert testtid: Bortsett fra å teste hele systemet, kan testerne utføre testing i modulene og undermodulene som er endret. Testere kan prioritere og planlegge testtilfeller. Dermed kan de redusere testtiden.
- Dekning økt: Ved hjelp av dette dokumentet vil testere sørge for at de har sjekket undermodulene som er påvirket av endringene i modulene. Ved å gjøre det vil testdekningen for prosjektet øke.
- Standardisering av testresultat: Utviklere og testere vil bruke et felles Impact Analysis-dokument, som representerer hver eneste endring i modulen.
- Teamets ansvar øker: Teammedlemmer må holde dette dokumentet oppdatert. Hvert teammedlem er ansvarlig for å oppdatere informasjonen om endringene han har gjort i systemet.
- Prioriter oppgaven tidlig og enkelt: Siden dokumentet gir et klart bilde av endringene, kan testerne prioritere testing i henhold til det.
- Tydelig kunnskap om produktet: Ved hjelp av dette dokumentet vil både utviklere og testere få en idé om alle modulene som er tilstede i systemet.
- Enkel feiloppdagelse: Feiloppdagelse er mye bedre. Et konsekvensanalysedokument er nyttig for integrasjonstesting.
Konklusjon
Et prosjekt kan gjøres med eller uten konsekvensanalyse. Men vi har sett fordelene med Impact Analysis-dokumentet fra artikkelen ovenfor. Testtiden er sterkt redusert med introduksjonen av dette dokumentet. Testere trenger ikke å kaste bort tid ved å teste funksjonene som ikke endres.
Med introduksjonen av dette dokumentet blir kommunikasjonen mellom utviklerne og testerne forbedret mye, og dette fører til effektivitet i testingen. Testere vil få en bedre ide om hele systemet.
Vi håper du har en klar forståelse av konsekvensanalyse i testing. Del gjerne dine kommentarer.
Anbefalt lesing
- Programvaretesting QA Assistant Job
- Programvare Testing Course: Hvilket programvare Testing Institute skal jeg delta?
- Programvaretesting Teknisk innhold Writer Freelancer Jobb
- Velge programvaretesting som din karriere
- Test dine analysefunksjoner og tenkekraft - Øvelser i programvaretest (del 2)
- Programvaretestkurs Tilbakemelding og anmeldelser
- Noen interessante intervjusspørsmål om programvaretesting
- Er programvaretesting en emosjonell oppgave?