Menu

Hoe een applicatie testen zonder vereisten?

how test an application without requirements

Probeer Ons Instrument Voor Het Oplossen Van Problemen

Technisch gezien zijn er geen toepassingen zonder vereisten. Stel je software voor die niets specifieks doet, maar zich gewoon regel na regel code uitstrekt. Het wordt een trap die nergens heen leidt.

Alle software heeft vereisten en is gericht op een bepaalde taak; het is specifiek een oplossing voor een probleem. Zo behoefteloos software is geen mogelijkheid.

Software zonder gedocumenteerde vereisten is echter een realiteit waar de meesten van ons helaas vaker mee te maken hebben we houden van. Het enige dat erger kan zijn, is dat de documentatie onvoldoende, onnauwkeurig of vreselijk verouderd is. Helaas gebeurt dit ook.

test zonder vereisten

Eerlijk gezegd is er echt geen vervanging voor een goed gedocumenteerd document met functionele / systeemvereisten met uitgebreide gebruiksscenario's en mock-upschermen. Hoewel we moeten toegeven dat dit een zeldzaamheid wordt in de industrie vanwege snelle ontwikkelingscycli en een paradigmaverschuiving naar minimale of geen documentatie.

Daarom is dit artikel een poging tot enkele praktijken die we hebben gevolgd toen we ons in deze situaties bevonden.

Lees ook:

verschil tussen white box en black box testen

Laten we er eerst een paar bekijken redenen waarom er misschien geen documentatie is, om te beginnen:

  1. Opgeschort project wordt heropend
  2. Documentatie minder formaat van werkproces
  3. Er is mogelijk documentatie beschikbaar, maar deze is mogelijk niet gedetailleerd of volledig
  4. Doorlopende releases en de informatie over de oudere versie is niet gearchiveerd, wat resulteert in een lacune in het begrip van hoe de bestaande functionaliteit reageert op de nieuwe

Dit zijn allemaal belemmeringen die wij testers dapper moeten oversteken en met succes bovenkomen. Hoe precies, toch?

Hier zijn de drie beste methoden om een ​​applicatie zonder vereisten te testen:

Methode # 1:

Werk met de kleine documentatie die u in handen kunt krijgen. Het kan een simpele achterstand zijn (in agile projecten), een helpbestand, een e-mail, een oudere versie van de BRD / FRD, of oude testcases (controleer deze in je ALM-tools en misschien vind je ze), enz.

Onderzoek, vraag rond en er is altijd een gedocumenteerd proces, ook al is het een magere.

Als dit niet lukt, geef dan geen korting op uw ervaring als softwaregebruiker.Bijvoorbeeld, als u een overboeking voor een bankrekening moet testen, hoeft niemand ons te vertellen hoe u dit moet doen, nietwaar? Omdat we als klanten van internetbankieren allemaal weten dat we van en naar rekeningen nodig hebben met een aantal beschikbare fondsen om overgemaakt te worden.

Overeengekomen dat niet alle situaties even eenvoudig zullen zijn, maar nogmaals, ze kunnen dat ook zijn.

Methode # 2:

Gebruik de oudere / huidige versie van de applicatie als referentie om de toekomstige release van een softwareproduct te testen. Nu geef ik toe dat dit in tegenspraak is met de regel: 'Schrijf nooit testcases met de applicatie als referentie'. Als we echter in een niet perfecte situatie werken, moeten we de regels aanpassen aan onze behoeften.

Het helpt daarbij om de volgende aspecten in het juiste perspectief te zien:

  • De applicatie kan bugs bevatten - dus als het systeem u na registratie rechtstreeks naar Screen1 brengt (een bepaald hypothetisch scherm in het belang van ons voorbeeld) - Ga er nooit vanuit dat dit het juiste gedrag is. Ook als een veld alfanumerieke tekens moet bevatten en een telefoonnummer is, een vraag die en zorg ervoor dat u de toepassing niet als een verleend voorbeeld voor verwachte functionaliteit beschouwt.
  • Gebruik in de bovenstaande situaties uw beoordelingsvermogen en gebruik de hulp van de applicatie om u een vliegende start te geven, maar wees kritisch als u twijfelt of het werkt.

Methode # 3:

Praat met de projectteamleden:

  • Bied aan om hun vergaderingen bij te wonen.
  • Vraag of u kunt deelnemen aan de testfase van de eenheid en de integratie.
  • Als dit niet het geval is, vraag dan of het ontwikkelteam hun unit- en integratietestresultaten kan delen.
  • Maak een afspraak voor kennisoverdracht op een geschikt moment.

Laten we nu de methoden in een voorbeeld toepassen:

Laten we aannemen dat er een winkelsite is waar u artikelen aan de winkelwagen kunt toevoegen. Idealiter als er documentatie was, moet het ons vertellen hoe we er items aan kunnen toevoegen, hoeveel items er op een bepaald moment kunnen zijn, wat er gebeurt als het item dat u hebt toegevoegd plotseling niet meer op voorraad is, wat is het maximale aantal van dezelfde items die u tegelijkertijd kunt kopen, enz. Onze situatie is dat er op dit moment GEEN van deze items beschikbaar is.

Pas methode # 1 toe:

Zoek alle mogelijke documentatie. Vraag je ontwikkelaarsteam of ze mock-upschermen hebben / kijken in de ALM-tool of iets anders. Als je toch iets vindt, zou dat een goed uitgangspunt zijn. Maar als deze methode niets oplevert, kunt u uw oordeel / intuïtie van de tester.

We weten allemaal hoe winkelwagentjes werken, dus maak uw aannames en kom tot enkele basisscenario's, zoals:

  • Items kunnen aan de winkelwagen worden toegevoegd nadat ze zijn doorzocht of gezocht
  • Zodra ik artikelen aan het winkelwagentje heb toegevoegd, moet de lijst met artikelen worden vernieuwd
  • De gebruiker moet kunnen doorgaan met winkelen, zelfs nadat hij enkele items aan de winkelwagen heeft toegevoegd
  • Als u hetzelfde item twee keer toevoegt, wordt het aantal toegevoegde items verhoogd
  • De items kunnen worden bijgewerkt
  • De items kunnen worden verwijderd
  • Het totaal moet gelijk zijn aan de som van alle toegevoegde prijzen
  • Belastingen moeten worden berekend op basis van de ingevoerde postcode
  • Verzendkosten moeten dienovereenkomstig worden toegevoegd

We kunnen doorgaan, maar ik weet zeker dat u de foto begrijpt.

Pas methode # 2 toe:

Als er een oudere versie van de applicatie beschikbaar is, kan dit handig zijn bij het schrijven van je testcases, aangezien je de exacte stappen moet schrijven van waar je moet klikken, waar je invoer moet invoeren, wat je moet controleren, etc. Screenshots / mockups / wire- frames - indien beschikbaar, kunnen ook goede vervangers zijn.

Zoals u kunt zien op het onderstaande scherm, zijn deze dingen duidelijk: de veldnamen, de knoppen of andere aanwezige elementen enz. (klik op afbeelding voor vergrote weergave)

test zonder vereisten

Nu hebben testers op dit punt enkele vragen, zoals:

  1. Wat gebeurt er als ik een char in het bedragvak geef?
  2. Wanneer moet ik teveel items toevoegen?
  3. Wat is het maximale aantal. van items die dit kan duren? Enz.

Pas methode # 3 toe ​

Breng uw vragenlijst naar de BA, de ontwikkelaar of zelfs de klant en vraag om opheldering. Zodra methode 3 is voltooid, zou u vrijwel alle informatie moeten hebben die u nodig hebt om gedetailleerde testcases te schrijven en uw tests met evenveel vertrouwen uit te voeren als wanneer er uitgebreide documentatie beschikbaar was.

Overeengekomen dat het veel meer stappen en veel meer follow-up zijn, maar om kwaliteitstesten te garanderen, zijn deze stappen onvermijdelijk.

Ten slotte​ alles gaat niet verloren als documentatie niet bestaat of onvoldoende is. Er is nog steeds hoop! Deel alstublieft uw ervaringen in vergelijkbare situaties.

Over de auteur: Dit nuttige bericht is geschreven door ons STH-teamlid Swati S.

Zoals altijd zijn uw opmerkingen, vragen en suggesties van harte welkom.

Aanbevolen literatuur

^