Prosjektrisikoanalyse og -redusering i programvaretesting
Thomas Hamilton
⚡ Smart oppsummering
Prosjektrisikoanalyse i teststyring identifiserer, evaluerer og reduserer trusler som kan forstyrre tidsplan, budsjett eller kvalitet. Lessdekker arbeidsflyten for risikoanalyse i tre trinn, prosjekt- og produktrisikoer, en konsekvens-sannsynlighetsmatrise, tiltak for å redusere risikoen og en Guru99 Casestudie av banker.
Hva er risikoanalyse?
Risiko er sannsynligheten for at en uønsket hendelse inntreffer.
Risikoanalyse i programvareteknikk er prosessen med å analysere risikoene forbundet med din Testing Prosjekt.
For å lykkes med prosjektet ditt, bør risiko identifiseres og tilsvarende løsninger bestemmes før prosjektet starter. Risikoidentifikasjon i programvareteknikk hjelper deg med å identifisere sannsynlige risikoer i de tidlige stadiene.
I denne opplæringen vil vi oppdage det første trinnet i Test Management-prosessen: Risikoanalyse og løsning ved hjelp av en casestudie.
I dette emnet vil vi oppdage det første trinnet i Test Management-prosessen: Risikoanalyse i programvaretesting og løsning ved hjelp av en casestudie.
Søknaden som testes er https://demo.guru99.com/V4/, kan du se programvarekravsspesifikasjonen her..
Ocuco Guru99 Bank vil ha to roller
- Leder
- Kunde-
Følgende funksjoner/moduler vil være tilgjengelige for disse to forskjellige rollene
Her er en liten omvisning på nettsiden
Etter å ha lest kravdokumentene har du kanskje innsett at nettsiden har for mange funksjonelle og komplekse scenarier.
Her er situasjonen -
- Ocuco GuruNettstedet til 99 banker har allerede fullført utviklingsfasen. Nå starter testfasen. Dessverre var dere ikke involvert tidlig i kravfasen.
- Sjefen din trenger at du fullfører testingen en måned bare med et begrenset budsjett, men forventer flott kvalitet.
- Et teammedlem som er en erfaren ingeniør, forteller deg
- I så fall, hva bør du gjøre?
A) Det ser ut til å være et stort problem. Vi må forholde oss til ASAP!!!
B) Jeg bryr meg ikke. Vi må begynne å jobbe nå.
- Prosjektet er et rot og tok alle ressurser og tid. Arbeidstakerens arbeidsmengde økte drastisk og de føler seg stresset og overbelastet
- – Prosjektet ditt er forsinket slik at du ikke kunne frigi produktet på den bestemte fristen som du lovet sjefen din. Som teammedlemmet ditt sa, er tidsplanen for dette prosjektet for stram sammenlignet med gjeldende ressursallokering.
Eksemplet ovenfor illustrerer betydning av risikoanalyse i testledelse.
Risikoredusering hjelper deg med –
Risikoen, som ble nevnt i eksempelet ovenfor, er bare en av mange potensielle risikoer som kan oppstå i prosjektet ditt. Du bør identifisere dem og ta avgjørelsen om å håndtere dem ASAP!!! Så den riktige handlingen i det eksemplet er handling A.
Derfor er risikoanalyse i testing viktig
Hvordan utføre risikoanalyse?
Det er en 3-trinns prosess
- Identifiser risikoene
- Analyser virkningen av hver identifisert risiko
- Ta mottiltak for den identifiserte og analyserte risikoen
Trinn 1) Identifiser risiko
Risiko kan identifiseres og klassifiseres i 2 typer i programvareprodukt
Prosjektrisiko
Prosjektrisiko kan defineres som en usikker hendelse eller aktivitet som kan påvirke prosjektets fremdrift. Virkningen har en positiv or negativ effekt på mulighetene for å nå prosjektmålene.
Det er primært 3 kategorier av prosjektrisiko
Organisasjonsrisiko
Det er en risiko knyttet til din human resource eller testteamet ditt. For eksempel i ditt prosjekt er mangel på teknisk dyktige medlemmer en risiko. Å ikke ha nok arbeidskraft til å fullføre prosjektet i tide er en annen risiko.
For å identifisere den organisatoriske risikoen bør du lage en liste med noen få spørsmål og svare på dem som selvøvelse. Her er noen anbefalte spørsmål.
A) Ja
B) Nei
A) Ja
B) Nei
A) Ja
B) Nei
Hvis du svarer på alle spørsmålene ovenfor, vil du enkelt identifisere potensielle risikoer som kan påvirke prosjektet ditt.
Teknisk risiko
Teknisk risiko er sannsynligheten for tap som oppstår under utførelsen av en teknisk prosess som uprøvd engineering, feil testprosedyre ... osv. Her er et eksempel på teknisk risiko
- Din oppgave i dette prosjektet er å teste et banknettsted. Du må sette opp skikkelige testmiljøer som speiler ekte forretningsmiljøer. Hvis Test miljø ikke er riktig konfigurert, vil produktet være det ikke testes riktig og mange defekter vil ikke bli oppdaget.
Forretningsrisiko
Risikoen innebærer en utvendig enhet. Det er risikoen som kan komme fra din bedrift, din kunde men ikke fra prosjektet ditt.
Følgende bilde viser deg et eksempel på forretningsrisiko.
I slike tilfeller må testlederen finne ut løsningene for å håndtere risikoen som:
- Sett prioritet for testfasene, fokus på å teste hovedfunksjonene til nettstedet
- Bruke et testverktøy for å øke produktiviteten ved testing
- Påfør prosessforbedring å redusere forvaltningsinnsatsen.
Produktrisiko
Produktrisiko er muligheten for at systemet eller programvaren ikke vil tilfredsstille eller oppfylle forventningene til kunden, brukeren eller interessenten. Denne risikoen i testplanen er relatert til funksjonalitet av produktet som ytelsesproblemer, sikkerhetsproblemer, krasjscenarier osv.
Følgende er eksempler på noen få produktrisikoer –
- Programvaren hopper over noen nøkkel funksjon som kundene spesifiserte i brukernes
behov - Programvaren er upålitelig og ofte mislykkes å arbeide.
- Programvare feiler på måter som forårsaker økonomisk eller annen skade på en bruker eller selskapet som bruker programvaren.
- Programvaren har problemer knyttet til en bestemt kvalitetsegenskap som sikkerhet, pålitelighet, brukervennlighet, vedlikeholdsevne eller ytelse.
Nå tilbake til prosjektet ditt, er det noen produktrisiko i Guru Nettstedet til 99 Bank? For å svare på dette spørsmålet, bør du følge disse trinnene
Når du er ferdig med de tre trinnene ovenfor, ta en liten quiz nedenfor for å identifisere produktrisikoer
A) Ja
B) Nei
C) Jeg er ikke sikker
A) Ja
B) Nei
A) Sikker overføring av midler
B) Bruker kan registrere ny konto
C) Trenger ikke flere funksjoner
Trinn 2) Analyser virkningen av at risikoen oppstår
I forrige emne har vi allerede identifisert risikoene som kan hemme prosjektet ditt. Her er listen over identifiserte risikoer:
- Du har kanskje ikke nok human resource å fullføre prosjektet innen fristen
- Testingen miljø er kanskje ikke riktig konfigurert som et ekte forretningsmiljø.
- Prosjektet ditt budsjett kan halveres på grunn av forretningssituasjonen
- Denne nettsiden kan mangel sikkerhetsfunksjoner
Deretter bør du analysere disse risikoene.
Hver risiko bør klassifiseres på grunnlag av følgende to parametere
- Ocuco sannsynlighet forekomst
- Ocuco innvirkning på prosjektet
Ved å bruke matrisen nedenfor kan du kategorisere risikoen i fire kategorier som Høy, Middels, og Lav eller verdier 3,2, 1
|
Sannsynlighet |
|
|---|---|
|
Høy (3) |
Har svært høy sannsynlighet for å skje, kan påvirke hele prosjektet |
|
Middels (2) |
50 % sjanse for å skje |
|
Lav (1) |
Lav sannsynlighet for forekomst |
|
Impact |
|
|---|---|
|
Høy (3) |
Kan ikke fortsette med prosjektaktivitet hvis det ikke løses umiddelbart |
|
Middels (2) |
Kan ikke fortsette prosjektaktiviteten hvis den ikke løses |
|
Lav (1) |
Trenger å løse det, men det er mulig å ta alternativ løsning for en stund |
Vurder følgende risikoer
|
Risiko |
Sannsynlighet |
Impact |
Prioritet = Sannsynlighet* Virkning |
|---|---|---|---|
|
Prosjektfristen er ikke overholdt |
3 |
3 |
9 |
|
Strømsvikt |
1 |
2 |
2 |
Basert på prioriteringen ovenfor kan du ta risikoreduserende testing eller mottiltak nevnt i tabellen nedenfor
|
Prioritet |
Risikostyringsmetode |
|
|---|---|---|
|
Høyt |
6-9 |
Ta avbøtende tiltak umiddelbart og overvåk risikoen hver dag til statusen er stengt. |
|
Middle |
3-5 |
Overvåk risikoen hver uke på internt fremdriftsmøte |
|
Lav |
1-2 |
Aksepter risikoen og overvåk risikoen på milepælsbasis. |
Det er nå tid for en øvelse, vi har identifisert fire risikoer i Guru99 Bankprosjekt. Klassifiser dem selv
| Risiko | Høyt | Medium | Lav | status |
|
|
|
|
|
Riktig.
Stemmer ikke.
|
|
|
|
|
|
Riktig.
stemmer ikke
|
|
|
|
|
Riktig.
stemmer ikke
|
|
|
|
|
|
|
Riktig.
Stemmer ikke.
|
Trinn 3) Ta mottiltak for å redusere risikoen
Denne aktiviteten er delt inn i 3 deler
Risikorespons
Prosjektlederen må velge strategier som reduserer risikoen til minimal. Prosjektledere kan velge mellom følgende fire risikoresponsstrategier
Tilbake til de fire risikoene som ble identifisert tidligere, må vi finne risikoreduserende tiltak i testing eller mottiltak for å unngå eller eliminere dem.
B) Testingen miljø er kanskje ikke riktig konfigurert som et ekte forretningsmiljø
C) Ditt prosjekt budsjett kan halveres på grunn av forretningssituasjonen
D) Denne nettsiden kan mangel sikkerhetsfunksjoner
Denne risikoen kan ikke unngås på grunn av selskapets situasjon; du kan ikke be om mer menneskelig ressurs for prosjektet. I slike tilfeller kan du redusere virkningen av risiko ved å velge noen alternativer nedenfor
- Velg det talentfulle og erfarne medlemmet til å bli med i prosjektteamet
- Lag opplæringskurset for å dyktiggjøre medlemmet, hjelpe dem med å forbedre produktiviteten
B. Testmiljøet er kanskje ikke riktig konfigurert som et ekte forretningsmiljø
Denne risikoen kan unngås hvis du gjør følgende aktiviteter
- Be utviklingsteamet om hjelp til å bygge opp testmiljøet
- Forbered alt utstyr eller materiell (server, database, PC..) som trengs for å sette opp miljøet
C. Prosjektet ditt kan halveres på grunn av forretningssituasjonen
Denne risikoen er kritisk; det kan hindre hele prosjektet i å fortsette. I så fall bør du gjøre det
- Redefiner prosjektets omfang, identifiser hva som skal testes og hva som vil bli ignorert i slike tilfeller
- Forhandle med kunden om prosjektperioden for å passe til prosjektbudsjettet
- Forbedre produktiviteten til hver prosjektfase, for eksempel testing, lage testspesifikasjoner, ... Hvis du kan spare tid, kan du spare kostnader
D. Denne nettsiden kan mangle sikkerhetsfunksjoner
Denne risikoen anses som middels prioritet, fordi den ikke påvirker hele prosjektet og kan unngås. Du kan be utviklingsteamet sjekke og legge til disse funksjonene på nettstedet.
Registrer risiko
All risiko skal registreres, dokumenteres og erkjennes av prosjektledere, interessenter og prosjektmedlemmet. Risikoregisteret bør være fritt tilgjengelig for alle medlemmene i prosjektgruppen.
Det er noen nyttige å registrere risiko som f.eks Redmine, MITRE… Etc.
Overvåke og kontrollere risiko
Risikoer kan overvåkes kontinuerlig for å sjekke om det er gjort endringer. Ny risiko kan identifiseres gjennom de konstante overvåkings- og vurderingsmekanismene.
For bedre risikostyring kan du henvise Risk Management mal inkludere i denne artikkelen
