Meny

Hur bestämmer du vilka brister som kan accepteras för att programvaran ska bli live-live?

how do you decide which defects are acceptable

Prova Vårt Instrument För Att Eliminera Problem

Programvara Go-Live är alltid en stor händelse för alla programvaruprodukter. Det är viktigt att se till att allt fungerar och att vi är det släppa kvalitetsprogramvara till användarna .

En dålig eller för tidig eller instabil eller svåranvänd produkt kan orsaka stora förluster ekonomiskt och kan också få användaren att förlora förtroendet för varumärket i sig.

Ofta hör vi att testning ska göras tills vi uppfyller utgångskriterierna. Vi hör också att fel måste fixas till en acceptabel nivå.

Även om det här är bra riktlinjer är de vaga.

programvara-gå-leva-kriterier

För att vara mer specifik:

  • Hur stor andel av bristerna är acceptabla för att programvara ska aktiveras?
  • Hur bestämmer du vilka öppna defekter som programvaran kan leva med?
  • Vad typer av defekter är allvarligare än de andra?

Rekommenderad läsning => När ska jag sluta testa?

Har du haft dessa frågor någonsin? Sedan kommer den här artikeln att hjälpa dig att svara på dem. Läs vidare…

Komplex programvara är inte felfri och det är en berättelse om kyckling och ägg om att stänga defekter gentemot arbetsprogramvaran.

Ju mer du åtgärdar defekter är det mer sannolikt att en ny defekt har injicerats när du stänger defekten. Så,

  • Hur bestämmer du om omfattningen av brister och vilken typ av brister du kan leva med?
  • Hur baslinjerar du programvaran som ska distribueras för att gå live?
  • Hur gör UAT-samordnare uppmaningen att gå live eller inte?
  • Vilka parametrar ska programvara bedömas mot?
  • Hur svarar vi - Är programvaran lämplig för användning och kommer den att ge värde för intressenterna?

Att gå live i produktion är en viktig milstolpe för såväl kunden som leverantören, eftersom det vanligtvis är kopplat till betalnings milstolpar. Båda har lika ansvar för att de stora transformationsprojekten ska lyckas.

Min erfarenhet visar att kunderna vill ha sitt värde för pengarna och har ett utgångskriterium för UAT att leva med.

Nämnda utgångskriterier skulle mer eller mindre definiera den acceptabla omfattningen av problem inom alla applikationsområden, såsom:

  1. Funktionell
  2. Prestanda och belastning
  3. Användbarhet
  4. säkerhet
  5. Integration med externa system
  6. Rapporter
  7. Datamigrering

Jag tror att varenda en av dessa typer av defekter måste förklaras ytterligare. Och det är precis vad vi kommer att göra nu:

hur man öppnar .dat-filen på mac

# 1. Funktionsfel:

Om programvaran skapas enligt specifikationerna från kunden måste den uppfylla kraven. Eventuella avvikelser loggas som funktionsfel.

Funktionsfel klassificeras sedan enligt svårighetsgrad och prioritet .

Följande är viktiga överväganden:

  • Hög svårighetsgrad och prioritetsfel är vanligtvis de som skulle påverka den dagliga användningen av programvaran. Dessa typer av defekter är de som måste åtgärdas innan vi går live. Inga undantag.
  • Ibland klassificeras funktionsfel som ändringsbegäranden eftersom de inte var en del av de ursprungligen givna kraven. Sådana CR: er, som är ett måste för att verksamheten ska fungera efter Go-live, är också ett måste som ska genomföras.
  • Klassificering av defekter och prioritering av funktionsfel görs av UAT-koordinatorerna i samarbete med affärsanvändare och affärsanalytiker. Vanligtvis har kunden ett utgångskriterium för hur mycket% av bristerna som kan vara öppna för live-live.

# 2. Prestanda och belastningsfel:

Prestationsfel är viktigt att tänka på för live-live och mer om programvaran ska användas av externa användare.

Om programvaran är långsam för ett visst antal användare, skulle användarna undvika att använda programvaran eftersom det tar mycket tid att ladda upp. Användare tenderar att flytta till konkurrentens webbplats om programvaran är mycket långsam och därmed förlorar affärer.

Ibland kan de delar av applikationen som inte är klientinriktade också påverka prestandan.

Till exempel: Om det finns en batchprocess som körs i slutet av varje dag och om applikationens svarstid försvinner medan detta fortsätter, är batchens prestanda också en faktor att tänka på.

  • Prestanda mäts vanligtvis i termer av skärmens responstid för att göra och bli tillgängliga för användarna medan det finns ett visst antal samtidiga användare på systemet.
  • Prestandatester görs med hjälp av verktyg som LoadRunner , WebLoad , Neoload etc.
  • Programvarans prestanda vid en viss belastning och vid en framtida förutspådd belastning dokumenteras vanligtvis i kontraktet och måste demonstreras innan den startas.
  • Skärmarna eller delar av applikationen som används mindre av användarna skjuts upp till utvärderingar efter live-live.
  • Prestanda beror också på vilken typ av hårdvara och nätverksförhållanden som programvaran distribueras på.
  • Prestandatester görs under UAT i den specificerade hårdvaran med hjälp av prestandaverktyg och deras defekter spåras på ett sätt som liknar funktionella defekter. De prioriteras också och man når enighet om att uppfylla utgångskriterierna för live-live.
  • Vanligtvis görs prestanda- och belastningstester i UAT efter att den funktionella UAT av affärsanvändarna har slutförts och ett acceptabelt utgångskriterium för funktionsfel har uppnåtts.

# 3. Användningsfel:

Programvaran skapad bör vara lätt att använda av slutanvändarna använder olika snabbtangenter, genvägar, minsta antal skärmnavigering, paginering etc. Programvaran måste vara smart och intuitiv.

Om det finns för många rörelser på sidan innan de går till lämplig skärm visar användarna vanligtvis mindre intresse för att använda programvaran.

  • Användarriktlinjer skapas innan programvaran byggs. Programvaran måste följa dessa riktlinjer.
  • Det kan också finnas verktygsbegränsningar när du skapar programvaran som måste övervinnas på ett smart sätt innan programvaran kan användas av slutanvändarna.
  • Med mycket användbar programvara kan en slutanvändare mata in data så mycket som 5 gånger den vanliga programvaran.
  • Programvarans utseende och känsla måste vara skarpt och även juridiska frågor måste ordnas innan de tas i bruk igen.
  • Många gånger utnämns en användbarhetskonsult för att säkerställa en smidig användarupplevelse för användarna.
  • Dokumentationen som måste gå ut med programvaran måste också följa strikta användarriktlinjer eftersom de kan användas lagligt.
  • Användbarhetsdefekterna som loggas av UAT-testare / externa testare prioriteras också som funktions- och prestandafel och måste uppfylla utgångskriterierna för go-live.

# 4. Säkerhetsfel:

säkerhet av programvaran är en het fråga eftersom programvaran kan hackas och kundkänslig data kan stulas på nolltid.

Därför bör tillförlitlig programvara inte tillåta ens en mycket kompetent hackare att komma in i applikationen utan behöriga behörigheter.

  • Säkerhetstestning görs i UAT med specifika ingångar i programvaran för att säkerställa att den inte är hackbar.
  • Säkerhetstestning görs av lagliga hackare som försöker hacka programvaran för att kontrollera om den är sårbar.
  • Alla säkerhetsfel måste stängas innan systemet startas.
  • Säkerhet betyder också inloggning och roller och privilegier för olika användare (externa och interna) för att använda olika delar av applikationerna och även för att skapa och godkänna data.

# 5. Integration med externa programvarusystem:

Vanligtvis måste en programvara som ska distribueras på kundens webbplats ha gränssnitt med all befintlig programvara som redan finns där.

Till exempel: Med utskriftssystemet har de använts eller det kan vara externa system som en faktureringsapplikation eller dataskärmsystem. Programvaran som distribueras bör sömlöst integreras med dessa externa system. All in- och utgång till dessa system ska fungera synkront. Teknik idag omfattar mobilappar och olika programvaruplattformar som applikationen måste vara kompatibel med .

Kontroll av extern systemgränssnitt bör utföras utförligt under system- och UAT-steg. Det bör vara ett måste på utgångskriterierna som ska uppfyllas innan du går live.

# 6. Rapporter:

Rapporter från programvaran är ett kritiskt sätt att visa att data i applikationen stämmer överens.

Till exempel: all faktureringsrelaterad data måste överensstämma med kredit- och debiteringssaldot.

  • All data i programvaran måste stämma överens. Denna avstämning av data i programvaran visas genom rapporter och de måste fungera som avsett.
  • Detta gäller särskilt om datamigrering från ett gammalt system till ett nytt system är den primära avsikten med den aktuella versionen.

# 7. Datamigrering:

Om ett gammalt system byts ut mot ett nytt flyttas data från det gamla systemet till det nya (efter att ett slutdatum har uppnåtts med hjälp av det nya systemet). Data som migreras bör stödjas av det nya systemet som definierats under kravuppsamlingen.

Alla gamla data kanske inte är tillgängliga i det nya systemet. dock kan en ögonblicksbild av den gamla informationen finnas tillgänglig i det nya systemet. Dessa uppgifter bör finnas tillgängliga enligt överenskommelse.

Notera : Listan ovan är inte uttömmande. Beroende på applikationstyp kan det finnas fler saker du måste validera eller inte kan allt ovan vara tillämpligt. Så, en grundlig förståelse av programvaran, affärsändamålet, användarnas förväntningar och arkitektoniska eller hårdvaruberoenden är ett måste för att utveckla omfattande utgångskriterier.

Ett exempel på utgångskriterier för go-live:

Detta är bara ett exempel. Det kan variera från projekt till projekt.

  • 100% av prioritet 1-defekter är stängda (svårighetsgraden och prioritet 1)
  • 90% av prioritet 2-bristerna är stängda (svårighetsgrad hög och prioritet 2) med en logisk lösning som är tillgänglig för resten av de 10% av bristerna. Och en plan finns tillgänglig för att stänga resten av de 10% av bristerna.
  • Checklista för produktion och sanity är klar.
  • Produktionssupportgruppen har bildats och är redo för stängning av biljetter.
  • 70% av prioriterade 3 brister är stängda och en plan finns för att stänga resten av de 30% av låga brister.

Några punkter att notera:

  • Alla svårighetsgrader och prioritetsdefinitioner bestäms under affärsmötena mellan kunden och säljaren i början av programmet.
  • När alla UAT-defekter har loggats och alla andra defekter har stängts, möts UAT-koordinatorer och affärssponsorer för att göra en översikt över pågående och öppna defekter. Om alla defekter som krävs för Day-1 go-live är stängda ser affärssponsorerna deras beredskap för go-live och får programvaran i produktion.

Sammanfattningsvis

Vi hoppas att den här artikeln har gett dig insikter om några av de viktiga överväganden som går in på att skapa grundläggande utgångskriterier som skyddar programvaran från potentiella produktionsfel.

Om författaren: Detta är en gästartikel av Krishnan Venkatraman. Han har nästan 18 års erfarenhet av programvarutestning. Han har arbetat med många stora och komplexa programvarutestprojekt.

Skicka gärna dina frågor / kommentarer nedan.

Rekommenderad läsning

^