Menu

Hoe bepaalt u welke defecten aanvaardbaar zijn om de software live te laten gaan?

how do you decide which defects are acceptable

Probeer Ons Instrument Voor Het Oplossen Van Problemen

Software Go-Live is altijd een groot evenement voor elk softwareproduct. Het is belangrijk om er absoluut voor te zorgen dat alles werkt en dat we dat ook zijn kwaliteitssoftware vrijgeven aan de gebruikers ​

Een slecht of voortijdig of onstabiel of moeilijk te gebruiken product kan financieel veel schade veroorzaken en kan er ook voor zorgen dat de gebruiker het vertrouwen in het merk zelf verliest.

Vaak horen we dat er moet worden getest totdat we aan de exitcriteria voldoen. We horen ook dat defecten tot een acceptabel niveau moeten worden verholpen.

Hoewel dit geweldig klinkende richtlijnen zijn, zijn ze vaag.

software-go-live-criteria

Om specifieker te zijn:

  • Welk percentage defecten is acceptabel om software live te laten gaan?
  • Hoe bepaal je de openstaande defecten waarmee de software live kan gaan?
  • Wat soorten defecten zijn serieuzer dan de anderen?

Aanbevolen lezen => Wanneer moet u stoppen met testen?

Heeft u deze vragen ooit gehad? Dan helpt dit artikel je om ze te beantwoorden. Lees verder…

Complexe software is niet defectvrij en het is een kip-en-ei-verhaal over het dichten van defecten ten opzichte van werkende software.

Hoe meer u defecten herstelt, hoe groter de kans dat er een nieuw defect is geïnjecteerd terwijl het defect wordt verholpen. Zo,

  • Hoe bepaal je de omvang van de defecten en het soort defecten waarmee je live kunt gaan?
  • Hoe baseer je de software die moet worden geïmplementeerd om live te gaan?
  • Hoe maken UAT-coördinatoren de oproep om live te gaan of niet?
  • Op welke parameters moet software worden beoordeeld?
  • Hoe antwoorden we - Is de software geschikt voor gebruik en zal het waarde opleveren voor de belanghebbenden?

Live in productie gaan is een belangrijke mijlpaal voor zowel de klant als de leverancier, aangezien het meestal is gekoppeld aan betalingsmijlpalen. Beiden hebben een gelijke verantwoordelijkheid om ervoor te zorgen dat de grote transformationele projecten succesvol zijn.

Mijn ervaring leert dat klanten waar voor hun geld willen en een exit criterium waarmee UAT live kan gaan.

De genoemde exitcriteria zouden min of meer de aanvaardbare omvang van problemen op alle toepassingsgebieden definiëren, zoals:

  1. Functioneel
  2. Prestaties en belasting
  3. Bruikbaarheid
  4. Veiligheid
  5. Integratie met externe systemen
  6. Rapporten
  7. Data migratie

Ik geloof dat elk van deze soorten defecten verder moet worden uitgelegd. En dat is precies wat we nu gaan doen:

website om youtube-video's naar mp3 te converteren

# 1. Functionele gebreken:

Als de software is gemaakt volgens de specificaties van de klant, moet deze aan de vereisten voldoen. Eventuele afwijkingen worden geregistreerd als functionele defecten.

Functionele defecten worden vervolgens ingedeeld volgens ernst en prioriteit ​

De volgende zijn belangrijke overwegingen:

  • Zeer ernstige en prioritaire defecten zijn meestal de defecten die van invloed zijn op het dagelijkse gebruik van de software. Dit soort defecten moeten worden verholpen voordat we live gaan. Geen uitzonderingen.
  • Soms worden functionele defecten geclassificeerd als wijzigingsverzoeken omdat ze geen deel uitmaakten van de oorspronkelijk gegeven vereisten. Dergelijke CR's, die een must zijn voor bedrijven om te werken na Go-live, zijn ook een must om te worden geïmplementeerd.
  • Classificatie van defecten en prioritering van functionele defecten worden gedaan door de UAT-coördinatoren in samenwerking met zakelijke gebruikers en Businessanalisten. Meestal heeft de klant een exitcriterium van hoeveel% van de defecten open kunnen staan ​​voor go-live.

# 2. Prestatie- en belastingsfouten:

Prestatiefouten zijn belangrijk om te overwegen voor go-live en vooral als de software door externe gebruikers wordt gebruikt.

Als de software traag is voor een bepaald aantal gebruikers, zouden de gebruikers het gebruik van de software vermijden omdat het veel tijd kost om te laden. Gebruikers hebben de neiging om naar de site van de concurrent te gaan als de software erg traag is en daardoor omzet verliest.

Soms kunnen de delen van de applicatie die niet met de klant te maken hebben, ook de prestaties beïnvloeden.

Bijvoorbeeld: Als er een batchproces is dat aan het einde van elke dag wordt uitgevoerd en als de responstijd van de applicatie eronder lijdt terwijl dit voortduurt, dan is de prestatie van de batch ook een factor om te overwegen.

  • Prestaties worden meestal gemeten in termen van reactietijd van schermen om weer te geven en beschikbaar te komen voor de gebruikers terwijl er een bepaald aantal gelijktijdige gebruikers op het systeem is.
  • Prestatietests worden gedaan met behulp van tools zoals LoadRunner ​ WebLoad , Neoload etc.
  • De prestaties van de software bij een bepaalde belasting en bij een toekomstige voorspelde belasting worden meestal gedocumenteerd in het contract en moeten worden aangetoond voordat deze in gebruik wordt genomen.
  • De schermen of delen van de applicatie die door de gebruikers minder worden gebruikt, worden na de go-live uitgesteld tot evaluaties.
  • De prestaties zijn ook afhankelijk van het type hardware en netwerkcondities waarop de software wordt geïmplementeerd.
  • Prestatietests worden gedaan tijdens UAT in de gespecificeerde hardware met behulp van prestatietools en hun defecten worden op dezelfde manier gevolgd als functionele defecten. Ze krijgen ook prioriteit en er wordt een consensus bereikt over het voldoen aan de exitcriteria voor go-live.
  • Gewoonlijk worden prestatie- en belastingtests in UAT uitgevoerd nadat de functionele UAT door de zakelijke gebruikers is voltooid en een aanvaardbaar uitgangscriterium voor functionele defecten is bereikt.

# 3. Gebruiksfouten:

De software gemaakt moet gemakkelijk bruikbaar zijn door de eindgebruikers het gebruik van verschillende sneltoetsen, snelkoppelingen, het minimum aantal schermnavigatie, paginering enz. De software moet slim en intuïtief zijn.

Als er te veel bewegingen van de pagina zijn voordat ze naar het juiste scherm gaan, tonen de gebruikers meestal minder interesse in het gebruik van de software.

  • Gebruiksrichtlijnen worden opgesteld voordat de software wordt gebouwd. De software moet zich aan deze richtlijnen houden.
  • Er kunnen ook toolbeperkingen zijn bij het maken van de software die slim moet worden overwonnen voordat de software door de eindgebruikers kan worden gebruikt.
  • Met zeer bruikbare software kan een eindgebruiker gegevens invoeren tot wel 5 keer de reguliere software.
  • De look en feel van de software moet helder zijn en ook juridische kwesties moeten worden opgelost voordat ze live gaan.
  • Vaak wordt een usability-adviseur aangesteld om de gebruikers een soepele gebruikerservaring te bieden.
  • De documentatie die met de softwareapplicatie mee moet, moet ook voldoen aan strenge gebruiksrichtlijnen, aangezien deze legaal kunnen worden gebruikt.
  • De bruikbaarheidsfouten die worden geregistreerd door UAT-testers / externe testers krijgen ook prioriteit als functionele en prestatiedefecten en moeten voldoen aan de exitcriteria voor go-live.

# 4. Beveiligingsfouten:

Veiligheid van de software is een hot issue, aangezien de softwareapplicatie kan worden gehackt en gevoelige klantgegevens binnen de kortste keren kunnen worden gestolen.

Daarom zou betrouwbare software zelfs een zeer bekwame hacker niet in staat moeten stellen om zonder de juiste rechten in de applicatie te komen.

  • Beveiligingstests worden uitgevoerd in UAT met specifieke invoer in de software om ervoor te zorgen dat deze niet hackbaar is.
  • Beveiligingstests worden uitgevoerd door legale hackers die de software proberen te hacken om te controleren of deze kwetsbaar is.
  • Alle beveiligingsfouten moeten worden afgesloten voordat het systeem live gaat.
  • Beveiliging betekent ook Login en rollen en privileges voor verschillende gebruikers (extern en intern) om verschillende secties van de applicaties te gebruiken en ook voor het maken en goedkeuren van gegevens.

# 5. Integratie met externe softwaresystemen:

Gewoonlijk moet een softwareapplicatie die op de locatie van de klant wordt geïmplementeerd, worden gekoppeld aan bestaande software die daar mogelijk al bestaat.

Bijvoorbeeld: Met het printsysteem hebben ze in gebruik of het kunnen externe systemen zijn zoals een factureringstoepassing of dataschermsystemen. De softwareapplicatie die wordt geïmplementeerd, moet naadloos integreren met deze externe systemen. Alle invoer en uitvoer naar deze systemen zouden synchroon moeten werken. Technologie omvat tegenwoordig mobiele apps en verschillende softwareplatforms die de applicatie moet zijn compatibel met ​

Het controleren op externe systeeminterfaces moet uitgebreid worden uitgevoerd tijdens systeem- en UAT-fasen. Het zou een must moeten zijn op de exitcriteria waaraan moet worden voldaan voordat de livegang wordt bereikt.

# 6. Rapporten:

Rapporten van de softwareapplicatie zijn een cruciale manier om aan te tonen dat de gegevens in de applicatie kloppen.

Bijvoorbeeld: alle factureringsgerelateerde gegevens moeten overeenkomen met de credit- en debetsaldi.

  • Alle gegevens in de software moeten met elkaar overeenstemmen. Deze afstemming van gegevens binnen de software wordt weergegeven door middel van rapporten en ze moeten werken zoals bedoeld.
  • Dit geldt met name als datamigratie van een oud systeem naar een nieuw systeem de primaire bedoeling is van de huidige release.

# 7. Data migratie:

Als een oud systeem wordt vervangen door een nieuw, worden gegevens uit het oude systeem verplaatst naar het nieuwe (nadat een afsluitdatum is bereikt door het nieuwe systeem te gebruiken). De gemigreerde gegevens moeten worden ondersteund door het nieuwe systeem zoals gedefinieerd tijdens het verzamelen van vereisten.

Mogelijk zijn niet alle oude gegevens beschikbaar in het nieuwe systeem; er kan echter een momentopname van de oude gegevens beschikbaar zijn in het nieuwe systeem. Deze gegevens moeten beschikbaar zijn zoals overeengekomen.

Opmerking : De bovenstaande lijst is niet uitputtend. Afhankelijk van het type toepassing, zijn er mogelijk meer dingen die u moet valideren of is mogelijk niet alles hierboven van toepassing. Een grondig begrip van de software, het zakelijke doel, de gebruikersverwachtingen en architecturale of hardware-afhankelijkheden is dus een must om uitgebreide exitcriteria te ontwikkelen.

Een voorbeeld van een exitcriterium voor go-live:

Dit is slechts een voorbeeld. Het kan variëren van project tot project.

  • 100% van de defecten met prioriteit 1 zijn gesloten (prioriteitskritiek en prioriteit 1)
  • 90% van de defecten met prioriteit 2 wordt gesloten (ernst hoog en prioriteit 2) en er is een logische oplossing beschikbaar voor de rest van de 10% van de defecten. En er is een plan beschikbaar om de rest van de 10% van de defecten te verhelpen.
  • De checklist voor productie-implementatie en gezond verstand is klaar.
  • Het productie-ondersteuningsteam is gevormd en klaar voor het sluiten van tickets.
  • 70% van de defecten met prioriteit 3 ​​is gesloten en er is een plan voor het sluiten van de rest van de 30% van de lage defecten.

Enkele aandachtspunten:

  • Alle definities van ernst en prioriteit worden bepaald tijdens de zakelijke bijeenkomsten tussen de klant en de leverancier aan het begin van het programma.
  • Nadat alle UAT-defecten zijn geregistreerd en alle andere defecten zijn gesloten, komen UAT-coördinatoren en Business-sponsors bijeen om de balans op te maken van lopende en openstaande defecten. Als alle defecten die nodig zijn voor de ingebruikname van dag 1 zijn gesloten, zien de bedrijfssponsors dat ze klaar zijn om live te gaan en krijgen ze de software in productie.

Ten slotte

We hopen dat dit artikel je wat inzicht heeft gegeven in enkele van de belangrijke overwegingen die nodig zijn bij het creëren van solide exit-criteria die de software beschermen tegen mogelijke mislukkingen in producties.

Over de auteur: Dit is een gastartikel van Krishnan Venkatraman. Hij heeft bijna 18 jaar ervaring in het testen van software. Hij heeft aan veel grote en complexe softwaretestprojecten gewerkt.

Stel gerust uw vragen / opmerkingen hieronder.

Aanbevolen literatuur

^