Menu

Hvordan beslutter du, hvilke mangler der kan accepteres for, at softwaren kan leveres live?

how do you decide which defects are acceptable

Prøv Vores Instrument Til At Fjerne Problemer

Software Go-Live er altid en stor begivenhed for ethvert softwareprodukt. Det er vigtigt absolut at sikre, at alt fungerer, og at vi er frigive kvalitetssoftware til brugerne .

Et dårligt eller for tidligt eller ustabilt eller vanskeligt at bruge produkt kan medføre store tab økonomisk og kan også få brugeren til at miste tilliden til selve mærket.

Ofte hører vi, at test skal udføres, indtil vi opfylder exitkriterierne. Vi hører også, at mangler skal løses til et acceptabelt niveau.

Mens disse er gode lydende retningslinjer, er de vage.

software-go-live-kriterier

For at være mere specifik:

  • Hvor stor en procentdel af mangler er acceptabelt for software at blive live-live?
  • Hvordan beslutter du de åbne fejl, som softwaren kan samle med?
  • Hvad slags fejl er mere seriøse end de andre?

Anbefalet læsning => Hvornår skal jeg stoppe med at teste?

Har du haft disse spørgsmål nogensinde? Derefter vil denne artikel hjælpe dig med at besvare dem. Læs videre…

Kompleks software er ikke fejlfri, og det er en kylling- og æghistorie om lukning af fejl i forhold til arbejdssoftware.

Jo mere du retter fejl, er der større sandsynlighed for, at en ny defekt er blevet injiceret, mens fejlen lukkes. Så,

  • Hvordan beslutter du dig for omfanget af mangler og den type fejl, du kan samle med?
  • Hvordan baserer du den software, der skal implementeres til live-live?
  • Hvordan foretager UAT-koordinatorer opkaldet til live-live eller ej?
  • Hvilke parametre skal software bedømmes efter?
  • Hvordan svarer vi - er softwaren egnet til brug, og vil den give værdi til interessenterne?

At gå live i produktion er en vigtig milepæl for kunden såvel som leverandøren, da det normalt er knyttet til betalingsmilepæle. Begge har lige ansvar for at sikre, at de store transformationsprojekter lykkes.

Min erfaring viser, at kunderne ønsker deres værdi for pengene og har en udgangskriterium for UAT at samle med.

De nævnte udgangskriterier vil mere eller mindre definere det acceptable omfang af problemer i alle områder af applikationen, såsom:

  1. Funktionel
  2. Ydeevne og belastning
  3. Anvendelighed
  4. Sikkerhed
  5. Integration med eksterne systemer
  6. Rapporter
  7. Datamigrering

Jeg mener, at hver eneste af disse typer fejl skal forklares nærmere. Og det er præcis, hvad vi vil gøre nu:

hvordan man læser en bin-fil

# 1. Funktionelle defekter:

Hvis softwaren oprettes i henhold til kundens specifikationer, skal den opfylde kravene. Eventuelle afvigelser registreres som funktionsfejl.

Funktionelle defekter klassificeres derefter i henhold til sværhedsgrad og prioritet .

Følgende er vigtige overvejelser:

  • Høj sværhedsgrad og prioritetsdefekter er normalt dem, der vil påvirke den daglige brug af softwaren. Disse typer af mangler er dem, der skal løses, før vi går live. Ingen undtagelser.
  • Nogle gange klassificeres funktionelle mangler som ændringsanmodninger, da de ikke var en del af de oprindeligt givne krav. Sådanne CR'er, der er et must for virksomheden at arbejde efter Go-live, er også et must, der skal implementeres.
  • Klassificering af mangler og prioritering af funktionelle mangler foretages af UAT-koordinatorerne i samarbejde med forretningsbrugere og forretningsanalytikere. Normalt har kunden et udgangskriterium for, hvor meget% af mangler der kan være åbne for live-live.

# 2. Ydeevne og belastningsfejl:

Ydelsesfejl er vigtigt at overveje for go-live og mere, hvis softwaren skal bruges af eksterne brugere.

Hvis softwaren er langsom for et givet antal brugere, undgår brugerne at bruge softwaren, da det tager meget tid at indlæse. Brugere har tendens til at flytte til konkurrentens websted, hvis softwaren er meget langsom og derved mister forretning.

Nogle gange kan de dele af applikationen, som ikke er klientvendende, også påvirke ydeevnen.

For eksempel: Hvis der er en batchproces, der kører i slutningen af ​​hver dag, og hvis applikationens svartid lider, mens dette fortsætter, er batchens ydeevne også en faktor, der skal overvejes.

  • Ydeevne måles normalt med hensyn til responstid på skærme, der skal gengives og bliver tilgængelige for brugerne, mens der er et vist antal samtidige brugere på systemet.
  • Ydelsestest udføres ved hjælp af værktøjer som f.eks LoadRunner , WebLoad , Neoload osv.
  • Udførelsen af ​​softwaren ved en given belastning og ved en fremtidig forudsagt belastning er normalt dokumenteret i kontrakten og skal demonstreres, før den bliver live-live.
  • Skærmene eller dele af applikationen, der bruges mindre af brugerne, udsættes til evalueringer efter go-live.
  • Ydeevne afhænger også af typen af ​​hardware og netværksforhold, som softwaren er implementeret på.
  • Ydelsestest udføres under UAT i den specificerede hardware ved hjælp af ydeevneværktøjer, og deres mangler spores på en måde svarende til funktionsdefekter. De prioriteres også, og der opnås enighed om at opfylde exitkriterierne for go-live.
  • Normalt udføres ydeevne- og belastningstest i UAT, efter at den funktionelle UAT af forretningsbrugere er afsluttet, og et acceptabelt udgangskriterium for funktionsfejl er nået.

# 3. Usability defekter:

Den oprettede software skal være let anvendelig af slutbrugerne ved hjælp af forskellige genvejstaster, genveje, det mindste antal skærmnavigation, paginering osv. Softwaren skal være smart og intuitiv.

Hvis der er for mange bevægelser på siden, før de flytter til den relevante skærm, viser brugerne normalt mindre interesse for at bruge softwaren.

  • Retningslinjer for brugervenlighed oprettes, før softwaren bygges. Softwaren skal overholde disse retningslinjer.
  • Der kan også være værktøjsbegrænsninger, når du opretter softwaren, som skal overvindes smart, før softwaren kan bruges af slutbrugerne.
  • Med meget anvendelig software kan en slutbruger indtaste data så meget som 5 gange den almindelige software.
  • Softwarens udseende og fornemmelse skal være skarpt, og også juridiske problemer skal ordnes, inden de bliver live-live.
  • Mange gange udpeges en brugervenlighedskonsulent for at sikre en jævn brugervenlighed for brugerne.
  • Dokumentationen, der skal ud med softwareapplikationen, skal også overholde strenge retningslinjer for brugervenlighed, da de kan bruges lovligt.
  • Usability-defekter, der er logget af UAT-testere / eksterne testere, prioriteres også som funktions- og ydeevnedefekter og skal opfylde udgangskriterierne for go-live.

# 4. Sikkerhedsfejl:

Sikkerhed af softwaren er et varmt problem, da softwareapplikationen kan hackes, og kundefølsomme data kan stjæles på ingen tid.

Derfor skal pålidelig software ikke tillade selv en meget kompetent hacker at komme ind i applikationen uden passende privilegier.

  • Sikkerhedstest udføres i UAT med specifikke input i softwaren for at sikre, at den ikke kan hackes.
  • Sikkerhedstest udføres af lovlige hackere, der prøver at hacke softwaren for at kontrollere, om den er sårbar.
  • Alle sikkerhedsfejl skal lukkes, før systemet tændes.
  • Sikkerhed betyder også login og roller og privilegier for forskellige brugere (eksterne og interne) til at bruge forskellige sektioner af applikationerne og også til oprettelse og godkendelse af data.

# 5. Integration med eksterne softwaresystemer:

Normalt skal en softwareapplikation, der skal implementeres på kundens websted, grænseflade med al eksisterende software, der muligvis allerede findes der.

For eksempel: Med udskrivningssystemet har de brugt, eller det kan være eksterne systemer såsom et faktureringsapplikation eller dataskærmsystemer. Softwareapplikationen, der implementeres, skal problemfrit integreres med disse eksterne systemer. Al input og output til disse systemer skal fungere synkront. Teknologi i dag omfatter mobilapps og forskellige softwareplatforme, som applikationen skal være kompatibel med .

Kontrol af ekstern systemgrænseflade skal udføres grundigt under system- og UAT-faser. Det skal være et must på udgangskriterierne, der skal være opfyldt, før de bliver live-live.

# 6. Rapporter:

Rapporter fra softwareapplikationen er en kritisk måde at vise, at dataene i applikationen stemmer overens.

For eksempel: alle faktureringsrelaterede data skal stemme overens med kredit- og debet-saldoen.

  • Alle data i softwaren skal forene sig. Denne afstemning af data i softwaren vises gennem rapporter, og de skal fungere som tilsigtet.
  • Dette gælder især hvis datamigrering fra et gammelt system til et nyt system er den primære hensigt med den aktuelle udgivelse.

# 7. Datamigrering:

Hvis et gammelt system udskiftes med et nyt, flyttes data fra det gamle system til det nye (efter en afskæringsdato er nået ved hjælp af det nye system). De migrerede data skal understøttes af det nye system som defineret under kravindsamling.

Alle gamle data er muligvis ikke tilgængelige i det nye system; dog kunne et øjebliksbillede af de gamle data være tilgængeligt i det nye system. Disse data skal være tilgængelige som aftalt.

Bemærk : Ovenstående liste er ikke udtømmende. Afhængigt af applikationstypen kan der være flere ting, du skal validere, eller ikke alt ovenfor kan være relevant. Så en grundig forståelse af softwaren, forretningsformålet, brugernes forventninger og arkitektoniske eller hardwareafhængigheder er et must for at udvikle omfattende exitkriterier.

Et eksempel på udgangskriterier for go-live:

Dette er blot et eksempel. Det kan variere fra projekt til projekt.

  • 100% af prioritet 1-fejl er lukket (Severity Critical og prioritet 1)
  • 90% af prioritet 2-fejl er lukket (alvorlighedsgrad høj og prioritet 2) med en logisk løsning, der er tilgængelig for resten af ​​de 10% af manglerne. Og en plan er tilgængelig til lukning af resten af ​​de 10% af manglerne.
  • Tjekliste til produktion og tilregnelighed er klar.
  • Produktionssupport team er dannet og klar til at lukke billetter.
  • 70% af prioritet 3-mangler er lukket, og der er en plan for lukning af resten af ​​de 30% af lave mangler.

Et par punkter at bemærke:

  • Alle sværhedsgrader og prioritetsdefinitioner bestemmes under forretningsmøderne mellem kunden og leverandøren i starten af ​​programmet.
  • Når alle UAT-mangler er logget, og alle andre mangler er lukket, mødes UAT-koordinatorer og forretningssponsorer for at gøre status over ventende og åbne mangler. Hvis alle mangler, der kræves til dag 1-go-live, er lukket, ser forretningssponsorerne deres beredskab til go-live og får softwaren i produktion.

Afslutningsvis

Vi håber, at denne artikel har givet dig nogle indblik i nogle af de vigtige overvejelser, der går i at skabe bunnsolide udgangskriterier, der beskytter softwaren mod potentielle fejl i produktioner.

Om forfatteren: Dette er en gæsteartikel af Krishnan Venkatraman. Han har næsten 18 års erfaring inden for softwaretest. Han har arbejdet på mange store og komplekse softwaretestprojekter.

Du er velkommen til at sende dine forespørgsler / kommentarer nedenfor.

Anbefalet læsning

^