Menu

Hoe om te gaan met slechte vereisten als tester

how deal with bad requirements

Probeer Ons Instrument Voor Het Oplossen Van Problemen

De stille vergaderruimte was verstikkend en iedereen erin was in de war. Hoe konden we het missen , was de vraag die ieders gezicht weerspiegelde.

Het niet verschijnen met een relevante fout wanneer de gebruiker het bestaande record probeert te dupliceren en hem dat toestaan, was tenslotte geen kleine fout - ook dat voor een verzekeringsmaatschappij.

Nadat ze besloten hadden het probleem op te lossen, ging iedereen uiteen. En tijdens het uitgraven werd opgemerkt dat de klant nooit iets zei over dupliciteit van records in het behoeftedocument en daarom stelde niemand relevante vragen of dacht erover na.

slechte eisen

Dit was slechts een voorbeeld.

In een carrière van meer dan 10 jaar , Heb ik veel gevallen waargenomen waarin projecten te lijden hadden onder slechte of slechte eisen.

Maar zoals ze zeggen, niets is perfect in deze wereld en je zult ermee te maken krijgen en het omgaan met projecten die geen of slechte eisen stellen, is een soort nachtmerrie.

Laat het me uitleggen -

Wat je leert:

Hoe slechte, slechte en tegenstrijdige vereisten problemen veroorzaken:

# 1) Geen vereisten - Geen vereisten impliceren aannames en gissingen en daarom is er geen vertrouwen. Het is erg moeilijk om een ​​product / applicatie te testen zonder enige basislijn. En dit resulteert in meer werk, meer bugs van de klant en meer leed voor het project.

  • Hoe zou jij een probleem melden over systeemcrash wanneer er geen definitie is van hoe het gedrag moet worden afgehandeld, is beschikbaar?
  • Hoe zou u overbrengen dat een laadtijd van 100 seconden voor de startpagina onaanvaardbaar is als er geen relevante prestatievereisten zijn?

Meer informatie over Geen vereisten en hoe met de situatie om te gaan tijdens het testen is te vinden in eerder gepubliceerd artikel - Hoe een applicatie testen zonder vereisten?

# 2) Slechte vereisten - De Quote, Iets onvolledig weten is gevaarlijk dan het helemaal niet te weten , is zeer waar als het gaat om het omgaan met een slechte behoefte.

Het interpreteren van een slechte eis en het implementeren ervan is een groot risico.

  • Hoe zou u bevestigen dat de pop-up met zoekresultaten wel of niet geldig is als de enige vereiste was: zoekresultaten moeten correct zijn en u weet niet zeker met welke criteria tijdens het zoeken rekening moet worden gehouden.
  • Hoe zou u dit interpreteren - Wachtwoord vergeten moet worden geïmplementeerd om de gebruiker te helpen het vergeten wachtwoord opnieuw te genereren / opnieuw in te stellen. Onbekend over welke werkstroom de klant wil om het wachtwoord te vergeten, de ontwikkelaar implementeert wat hij / zij het beste vindt en de conflicten beginnen.

# 3) Tegenstrijdige vereisten - Iemand vragen om twee verschillende dingen tegelijkertijd te doen, brengt hem / haar alleen maar in de war en ook het systeem is geen uitzondering.

  • Hoe zou u een applicatie testen met de genoemde vereisten, zoals hieronder:
    • De toepassing moet altijd op de startpagina worden geopend.
    • Van gebruikers wordt verwacht dat ze inloggen om toegang te krijgen tot de applicatie.
  • Wat zou u de prioriteit bepalen als het vereiste document als volgt is:
    • De game-applicatie moet de gebruiker naar het volgende niveau promoveren als de gebruiker 1000 scoort.
    • De gebruiker moet worden omgeleid naar de gratis abonnementspagina zodra hij 1000 scoort.

En zo zorgen de slechte, slechte en tegenstrijdige vereisten voor gedoe.

Omdat het in de software-industrie zit, zou het deel moeten uitmaken van een project, omdat zelfs de klant soms niet zeker weet wat ze precies willen en hoe ze het moeten verwoorden.

Vanuit testoogpunt is het, hoewel het moeilijk is om met die dubbelzinnige of vage vereisten om te gaan, niet helemaal onmogelijk.

Laten we eens kijken naar de mogelijke oplossingen:

Slechte vereisten en hoe je ze als tester moet behandelen:

Methode # 1)Ontdek en leer:

Andere toepassingen verkennen, leren over algemeen verwacht gedrag, de werkstroom begrijpen, nadenken over gebruikersgemak en logica toepassen is een manier om met de situatie om te gaan. Ook, vertrouwend op verkennend testen zou nuttig zijn in dit soort situaties waarin de vereisten niet duidelijk zijn.

Meestal is het een goede gok om prioriteit te geven aan gebruikerservaring en gemak wanneer de vereisten niet duidelijk zijn.

Methode # 2)Maak gebruik van ervaring:

Maak gebruik van ervaring

Domeinervaring kunnen algemene testervaring, problemen in het verleden en persoonlijke inzichten helpen bij het aanpakken van verwarrende situaties en vereisten.

Methode # 3)Verwijs wireframes:

Wireframes zijn een soort visuele vereiste waar u kleine details kunt vinden en die details kunnen zeer nuttig zijn bij het creëren van het verwachte beeld van het product of de toepassing en helpen bij het op een betere manier behandelen van testaspecten.

Lees verder ​ Wireframes - Moeten ze echt worden getest? En zo ja, hoe?

Methode # 4)Peer discussie:

hoe je een array van een andere methode in java aanroept

Peer discussie

Wat de verwarring ook is, als het met de juiste groep mensen wordt besproken, worden de dingen verduidelijkt. Iedereen heeft verschillende ervaringen, verwachtingen, gebruikersoog en analyseweergave en het bespreken van die slechte vereisten met collega's zal het begrip kristalliseren en het zelfvertrouwen vergroten.

Methode # 5)Verduidelijking van klant:

Klant is de eigenaar van het product / de applicatie en het is altijd verstandig om hem te benaderen als het gaat om duidelijkheid van eisen. Maar vergeet niet dat het niet raadzaam is om de klant aan te vallen met honderden vragen. Voordat u dit doet, is wat huiswerk vereist.

Probeer de beschikbare best practices te achterhalen, begrijp de voordelen van implementatie en neem vervolgens contact op met de klant met vragen en mogelijke oplossingen.

Gevolgtrekking

Ten slotte maken losjes gedefinieerde of ongedefinieerde vereisten deel uit van het leven van de tester en we moeten ze accepteren, maar laten we proberen optimistisch te zijn en er oplossingen voor te bedenken. We zijn tenslotte testers, helpen de applicaties op schema te houden en voorkomen dat ze plat vallen. YAY voor ons :)

Over de auteur: Deze inspirerende post is geschreven door STH-teamlid Bhumika M. Ze is een projectleider en heeft meer dan 10 jaar ervaring in het testen van software.

Veel plezier met testen, zoals gewoonlijk… .. in afwachting van uw mening, opmerkingen en meningen.

Aanbevolen literatuur

^