Menu

Hvordan testes en ansøgning uden krav?

how test an application without requirements

Prøv Vores Instrument Til At Fjerne Problemer

Teknisk set er der ingen applikationer uden krav. Forestil dig software, der ikke gør noget specifikt, men simpelthen linje efter linje kode, der strækker sig videre. Det bliver en trappe, der ikke fører nogen steder.

Al software har krav og er målrettet mod en bestemt opgave; specifikt er det en løsning på et problem. Så krav-mindre software er ikke en mulighed.

Imidlertid er software uden dokumenterede krav en realitet, som desværre de fleste af os ofte møder vi kan lide. Det eneste, der var værre, kunne være, at dokumentationen er utilstrækkelig, unøjagtig eller frygtelig forældet. Desværre sker dette også.

test uden krav

Ærligt talt er der virkelig ingen erstatning for et veldokumenteret funktionelt / systemkravdokument med detaljerede brugssager og mock up-skærme. Selvom vi må indrømme, at dette er ved at blive en sjældenhed i branchen på grund af hurtige udviklingscyklusser og et paradigmeskift mod minimum eller ingen dokumentation.

Derfor er denne artikel et forsøg på nogle fremgangsmåder, vi har fulgt, da vi befandt os i disse situationer.

Læs også:

gratis youtube til mp4 video downloader

Lad os først se på nogle få grunde til, at der måske ikke er dokumentation til at begynde med:

  1. Hyldeprojekt genåbnes
  2. Dokumentation mindre format på arbejdsprocessen
  3. Dokumentation findes muligvis - men er muligvis ikke detaljeret eller komplet
  4. Kontinuerlige udgivelser og den ældre versionrelaterede information er ikke arkiveret, hvilket resulterer i et hul i forståelsen af, hvordan den eksisterende funktionalitet reagerer med den nye

Dette er alle forhindringer, som vi testere er nødt til modigt at krydse og komme frem med succes. Hvordan præcist dog, ikke?

Her er top 3 metoder til at teste en applikation uden krav:

Metode nr. 1:

Arbejd med den lille dokumentation, du kan få fat i. Det kan være et grundlæggende simpelt efterslæb (i agile projekter), en hjælpefil, en e-mail, en ældre version af BRD / FRD eller gamle testtilfælde (tjek for disse i dine ALM-værktøjer, og du finder dem muligvis) osv.

Undersøg, spørg rundt, og der er altid noget dokumenteret forsøg, selvom det er tyndt.

Når dette ikke fungerer, skal du ikke nedsætte din oplevelse som softwarebruger.For eksempel, hvis du skal teste en overførselshandling for en bankkonto, behøver ingen at fortælle os, hvordan vi gør dette, er det ikke? For som netbankkunder ved vi alle, at vi har brug for fra og til konti med et antal disponible midler, der kan overføres.

Enig om, at ikke alle situationer vil være lige så enkle, men igen, de kan også være.

Metode nr.2:

Brug den ældre / aktuelle version af applikationen som en reference til at teste den fremtidige frigivelse af et softwareprodukt. Nu indrømmer jeg, at dette er i strid med reglen, 'Skriv aldrig testsager med applikationen som reference'. Men når vi arbejder i en mindre end perfekt situation, er vi nødt til at forme reglerne, så de passer til vores behov.

Det hjælper med at holde følgende aspekter i perspektiv, når du gør det:

  • Applikationen kan indeholde bugs - så hvis systemet efter registrering fører dig direkte til Screen1 (en bestemt hypotetisk skærm af hensyn til vores eksempel) - Antag aldrig, at det er den rigtige adfærd. Også hvis et felt tager alfanumeriske tegn og er et telefonnummer - et spørgsmål der og sørg for at du ikke tager applikationen som et givet eksempel for forventet funktionalitet.
  • I ovenstående situationer skal du bruge din vurdering og tage hjælp fra applikationen til at give dig en start, men vær kritisk over for det for at stille spørgsmålstegn ved, at det fungerer.

Metode nr.3:

Tal med projektmedlemmerne:

  • Tilbyd at deltage i deres møder.
  • Spørg, om du kan deltage i enhedens og integrationstests faser.
  • Hvis ikke, spørg om dev-teamet kan dele deres enheds- og integrationstestresultater.
  • Arranger et tidspunkt for videnoverførsel på et passende tidspunkt.

Lad os nu anvende metoderne i et eksempel:

Lad os antage, at der er et shoppingsted, hvor du kan tilføje varer til indkøbskurven. Ideelt set hvis der var dokumentation, skal den fortælle os, hvordan vi tilføjer varer til den, hvor mange varer den kan have på et givet tidspunkt, hvad sker der, når den vare, du har tilføjet, pludselig er udsolgt, hvad er det maksimale antal af de samme varer, du kan købe på samme tid osv. Vores situation er, at INGEN deraf er tilgængelig på dette tidspunkt.

Anvend metode nr. 1:

Find enhver dokumentation, du kunne. Spørg dit dev-team, hvis de har mock-up-skærme / ser i ALM-værktøjet eller noget overhovedet. Hvis du finder noget, ville det være et godt udgangspunkt. Men hvis denne metode ikke viser noget, kan du bruge din testers vurdering / intuition.

Vi ved alle, hvordan indkøbsvogne fungerer, så tag dine antagelser, og kom frem til få grundlæggende scenarier, såsom:

  • Varer kan føjes til indkøbskurven efter gennemsyn eller søgning
  • Når jeg tilføjer varer til indkøbskurven, skal listen over varer opdateres
  • Brugeren skal være i stand til at fortsætte med at shoppe, selv efter at have tilføjet nogle få varer i indkøbskurven
  • Hvis du tilføjer det samme element to gange, øges antallet af tilføjede varer
  • Varerne kan opdateres
  • Varerne kan fjernes
  • Det samlede beløb skal svare til summen af ​​alle de tilføjede priser
  • Skatter skal beregnes ud fra det indtastede postnummer
  • Forsendelsesomkostninger skal tilføjes tilsvarende

Vi kan fortsætte, men jeg er sikker på, at du får billedet.

Anvend metode nr. 2:

Hvis der er en ældre version af applikationen tilgængelig, kan dette være nyttigt at skrive dine testcases, da du bliver nødt til at skrive de nøjagtige trin, hvor du skal klikke, hvor du skal indtaste input, hvad du skal kontrollere osv. Screenshots / mockups / wire- rammer - hvis de er tilgængelige, kan det også være gode erstatninger.

Som du kan se fra nedenstående skærmbillede, er disse ting tydelige - feltnavne, knapper eller andre tilstedeværende elementer osv. (klik på billedet for at se det større)

test uden krav

På dette tidspunkt har testere nogle spørgsmål som:

  1. Hvad sker der, når jeg giver en char i mængdefeltet?
  2. Hvornår tilføjer jeg for mange varer?
  3. Hvad er det maksimale nr. af ting, dette kan tage? Etc.

Anvend metode nr. 3 :

Tag din liste med spørgsmål til BA, udvikleren eller endda klienten og søg en afklaring. Når metode 3 er færdig, skal du stort set være udstyret med alle de oplysninger, du har brug for til at skrive detaljerede testsager og udføre din test med så meget selvtillid, som du ville, når udførlig dokumentation var tilgængelig.

Enig om, at det er mange flere trin og meget mere opfølgning, men for at sikre kvalitetstest er disse trin uundgåelige.

Afslutningsvis, alt går ikke tabt, når dokumentation ikke findes eller er utilstrækkelig. Der er stadig håb! Del venligst dine oplevelser i lignende situationer.

Om forfatteren: Dette nyttige indlæg er skrevet af vores STH-teammedlem Swati S.

Som altid er dine kommentarer, spørgsmål og forslag meget velkomne.

Anbefalet læsning

^