Meny

Hvordan bestemmer du hvilke mangler som kan aksepteres for at programvaren kan leveres live?

how do you decide which defects are acceptable

Prøv Instrumentet Vårt For Å Eliminere Problemer

Programvare Go-Live er alltid en stor begivenhet for ethvert programvareprodukt. Det er viktig å absolutt sørge for at alt fungerer, og at vi er det frigjøre kvalitetsprogramvare til brukerne .

Et dårlig eller for tidlig eller ustabilt eller vanskelig å bruke produkt kan føre til store tap økonomisk og kan også få brukeren til å miste tilliten til selve merkevaren.

Ofte hører vi at testing bør gjøres til vi oppfyller utgangskriteriene. Vi hører også at mangler må fikses til et akseptabelt nivå.

Selv om dette er gode retningslinjer, er de vage.

programvare-gå-live-kriterier

For å være mer presis:

  • Hvor stor prosentandel av feil er akseptabelt for programvare å bli live-live?
  • Hvordan bestemmer du deg for de åpne feilene som programvaren kan samle med?
  • Hva slags mangler er mer seriøse enn de andre?

Anbefalt lesing => Når skal jeg slutte å teste?

Har du hatt disse spørsmålene noen gang? Deretter vil denne artikkelen hjelpe deg med å svare på dem. Les videre…

Kompleks programvare er ikke feilfri, og det er en kylling- og egghistorie om lukking av mangler i forhold til arbeidsprogramvare.

Jo mer du fikser feil, er det større sannsynlighet for at en ny feil har blitt injisert mens du lukker feilen. Så,

  • Hvordan bestemmer du deg for omfanget av mangler og hvilken type feil du kan leve med?
  • Hvordan baserer du programvaren som skal distribueres til live-live?
  • Hvordan ringer UAT-koordinatorer til å gå live eller ikke?
  • Hvilke parametere skal programvare vurderes mot?
  • Hvordan svarer vi - Er programvaren egnet for bruk og vil den gi verdi til interessentene?

Å gå live i produksjon er en viktig milepæl for kunden så vel som leverandøren, ettersom det vanligvis er knyttet til betalingsmål. Begge har et likeverdig ansvar for å sikre at de store transformasjonsprosjektene lykkes.

Min erfaring viser at kundene vil ha sin verdi for pengene og har en utgangskriterium for UAT å leve med.

Nevnte utgangskriterier vil mer eller mindre definere akseptabel omfang av problemer i alle områder av applikasjonen, for eksempel:

  1. Funksjonell
  2. Ytelse og belastning
  3. Brukervennlighet
  4. Sikkerhet
  5. Integrasjon med eksterne systemer
  6. Rapporter
  7. Datamigrering

Jeg tror at hver eneste av disse typene mangler må forklares nærmere. Og det er akkurat det vi vil gjøre nå:

hva er den beste gratis brannmuren

#1. Funksjonelle feil:

Hvis programvaren er opprettet i henhold til spesifikasjonene gitt av kunden, må den oppfylle kravene. Eventuelle avvik registreres som funksjonsfeil.

Funksjonsfeil blir deretter klassifisert i henhold til alvorlighetsgrad og prioritet .

Følgende er viktige hensyn:

  • Høy alvorlighetsgrad og prioritetsdefekter er vanligvis de som vil påvirke den daglige bruken av programvaren. Disse typer feil er de som må løses før vi går live. Ingen unntak.
  • Noen ganger klassifiseres funksjonsfeil som endringsforespørsler, da de ikke var en del av de opprinnelig oppgitte kravene. Slike CR-er, som er et must for virksomheten å jobbe etter Go-live, er også et must som skal implementeres.
  • Klassifisering av mangler og prioritering av funksjonsfeil gjøres av UAT-koordinatorene i samarbeid med forretningsbrukere og forretningsanalytikere. Vanligvis har kunden et utgangskriterium for hvor mye% av manglene som kan være åpne for live-live.

# 2. Ytelses- og lastfeil:

Ytelsesfeil er viktig å ta i betraktning for live-live og mer, hvis programvaren skal brukes av eksterne brukere.

Hvis programvaren er treg for et gitt antall brukere, vil brukerne unngå å bruke programvaren, da det tar mye tid å laste opp. Brukere har en tendens til å flytte til konkurrentens nettsted hvis programvaren er veldig treg og dermed miste virksomheten.

Noen ganger kan delene av applikasjonen som ikke er klientvendt, også påvirke ytelsen.

For eksempel: Hvis det er en batchprosess som kjører på slutten av hver dag, og hvis applikasjonens responstid lider mens dette fortsetter, er batchens ytelse også en faktor å vurdere.

  • Ytelse måles vanligvis når det gjelder responstid på skjermene for å gjengis og bli tilgjengelig for brukerne mens det er et visst antall samtidige brukere på systemet.
  • Ytelsestester gjøres ved hjelp av verktøy som LoadRunner , WebLoad , Neoload etc.
  • Ytelsen til programvaren ved en gitt belastning og ved en fremtidig forventet belastning er vanligvis dokumentert i kontrakten og må demonstreres før den blir live-live.
  • Skjermene eller delene av applikasjonen som brukes mindre av brukerne, blir utsatt til evalueringer etter live-live.
  • Ytelsen er også avhengig av typen maskinvare og nettverksforhold som programvaren er distribuert på.
  • Ytelsestester utføres under UAT i spesifisert maskinvare ved hjelp av ytelsesverktøy, og deres mangler blir sporet på en måte som ligner på funksjonelle feil. De prioriteres også, og det oppnås enighet om å oppfylle utgangskriteriene for live-live.
  • Vanligvis blir ytelse og belastningstester i UAT utført etter at den funksjonelle UAT av forretningsbrukerne er fullført og et akseptabelt utgangskriterium for funksjonsfeil er nådd.

# 3. Bruksfeil:

Programvaren opprettet bør være lett brukbare av sluttbrukerne ved hjelp av forskjellige hurtigtaster, snarveier, minimum antall skjermnavigasjon, paginering osv. Programvaren må være smart og intuitiv.

Hvis det er for mange bevegelser på siden før du går til riktig skjerm, viser brukerne vanligvis mindre interesse for å bruke programvaren.

  • Retningslinjer for brukervennlighet opprettes før programvaren bygges. Programvaren må følge disse retningslinjene.
  • Det kan også være verktøybegrensninger når du lager programvaren som må overvinnes på en smart måte før programvaren kan brukes av sluttbrukerne.
  • Med svært brukbar programvare kan en sluttbruker legge inn data så mye som 5 ganger vanlig programvare.
  • Programvarens utseende og følelse må være skarpt, og også juridiske problemer må ordnes før de går live.
  • Mange ganger blir det utnevnt en brukervennlighetskonsulent for å sikre en jevn brukeropplevelse for brukerne.
  • Dokumentasjonen som må ut med programvaren, må også overholde strenge retningslinjer for brukervennlighet, ettersom de kan brukes lovlig.
  • Usability defekter logget av UAT testere / eksterne testere prioriteres også som funksjons- og ytelsesfeil og må oppfylle utgangskriteriene for live-live.

# 4. Sikkerhetsfeil:

Sikkerhet av programvaren er et veldig problem, da programvaren kan bli hacket og kundesensitive data kan bli stjålet på kort tid.

Derfor bør pålitelig programvare ikke tillate at en veldig kompetent hacker kommer inn i applikasjonen uten tilstrekkelige privilegier.

  • Sikkerhetstesting utføres i UAT med spesifikke innganger i programvaren for å sikre at den ikke kan hackes.
  • Sikkerhetstesting utføres av lovlige hackere som prøver å hacke programvaren for å sjekke om den er sårbar.
  • Alle sikkerhetsfeil må lukkes før systemet settes i drift.
  • Sikkerhet betyr også pålogging og roller og privilegier til forskjellige brukere (eksterne og interne) for å bruke forskjellige deler av applikasjonene og også for å opprette og godkjenne data.

# 5. Integrasjon med eksterne programvaresystemer:

Vanligvis må et program som skal distribueres på kundens nettsted grensesnitt med eksisterende programvare som allerede finnes der.

For eksempel: Med utskriftssystemet har de i bruk, eller det kan være eksterne systemer, for eksempel et faktureringsprogram eller dataskjermsystemer. Programvaren som distribueres, skal sømløst integreres med disse eksterne systemene. All inngang og utgang til disse systemene skal fungere synkront. Teknologi i dag omfatter mobilapper og forskjellige programvareplattformer som applikasjonen må være kompatibel med .

Kontroll av ekstern systemgrensesnitt bør utføres grundig under system- og UAT-trinn. Det bør være et must på utgangskriteriene som skal oppfylles før live-live.

# 6. Rapporter:

Rapporter fra programvaren er en kritisk måte å vise at dataene i applikasjonen stemmer overens.

For eksempel: alle faktureringsrelaterte data må stemme overens med kreditt- og belastningsbalansen.

  • Alle data i programvaren må avstemmes. Denne avstemmingen av data i programvaren vises gjennom rapporter og de må fungere som forutsatt.
  • Dette gjelder spesielt hvis datamigrering fra et gammelt system til et nytt system er den primære hensikten med den nåværende utgivelsen.

# 7. Datamigrering:

Hvis et gammelt system byttes ut med et nytt, flyttes data fra det gamle systemet til det nye (etter at en avskjæringsdato er nådd ved å bruke det nye systemet). Dataene som migreres, bør støttes av det nye systemet som definert under kravinnsamling.

Alle gamle data er kanskje ikke tilgjengelig i det nye systemet; Imidlertid kan et øyeblikksbilde av de gamle dataene være tilgjengelig i det nye systemet. Disse dataene skal være tilgjengelige som avtalt.

Merk : Listen over er ikke uttømmende. Avhengig av applikasjonstypen, kan det være flere ting du må validere, eller ikke kan alt ovenfor være aktuelt. Så en grundig forståelse av programvaren, forretningsformålet, brukerens forventninger og arkitektoniske eller maskinvareavhengige er et must for å utvikle omfattende utgangskriterier.

Et eksempel på utgangskriterier for live-live:

Dette er bare et eksempel. Det kan variere fra prosjekt til prosjekt.

  • 100% av prioritet 1-feil er lukket (alvorlighetsgrad og prioritet 1)
  • 90% av prioritet 2-feil er lukket (alvorlighetsgrad høy og prioritet 2) med en logisk løsning som er tilgjengelig for resten av de 10% av feilene. Og en plan er tilgjengelig for å lukke resten av de 10% av manglene.
  • Sjekkliste for produksjon og sunn fornuft er klar.
  • Produksjonssupportteamet er dannet og klart for lukking av billetter.
  • 70% av prioritet 3 mangler er stengt, og en plan er på plass for å lukke resten av de 30% av lave mangler.

Noen få punkter å merke seg:

  • Alle definisjoner av alvorlighetsgrad og prioritet avgjøres under forretningsmøtene mellom kunden og leverandøren ved starten av programmet.
  • Etter at alle UAT-manglene er logget og alle de andre feilene er lukket, møtes UAT-koordinatorer og forretningssponsorer for å gjøre status over ventende og åpne mangler. Hvis alle feil som er påkrevd for Day-1 go-live er lukket, ser virksomhetssponsorene deres beredskap for go-live og får programvaren i produksjon.

For å konkludere

Vi håper denne artikkelen har gitt deg litt innsikt i noe av det viktige hensynet som ligger i å lage bunnsolide utgangskriterier som beskytter programvaren mot potensielle feil i produksjoner.

Om forfatteren: Dette er en gjesteartikkel av Krishnan Venkatraman. Han har nesten 18 års erfaring med testing av programvare. Han har jobbet med mange store og komplekse programvaretestprosjekter.

Legg gjerne inn spørsmål / kommentarer nedenfor.

Anbefalt lesing

^