Meny

Hvordan teste en søknad uten krav?

how test an application without requirements

Prøv Instrumentet Vårt For Å Eliminere Problemer

Teknisk sett er det ingen applikasjoner uten krav. Tenk deg programvare som ikke gjør noe spesifikt, men som rett og slett strekker seg linje etter kode. Det blir en trapp som ikke fører noen vei.

All programvare har krav og er rettet mot en bestemt oppgave; spesifikt er det en løsning på et problem. Så krav-mindre programvare er ikke en mulighet.

Imidlertid er programvare uten dokumenterte krav en realitet som dessverre de fleste av oss ofte møter vi liker. Det eneste som er verre kan være at dokumentasjonen er utilstrekkelig, unøyaktig eller veldig utdatert. Dessverre skjer dette også.

test uten krav

Ærlig talt, det er egentlig ingen erstatning for et veldokumentert funksjonelt / systemkravdokument med forseggjorte brukssaker og mock up-skjermer. Selv om vi må innrømme at dette blir en sjeldenhet i bransjen på grunn av raske utviklingssykluser og et paradigmeskifte mot minimum eller ingen dokumentasjon.

Derfor er denne artikkelen et forsøk på noen fremgangsmåter vi har fulgt da vi befant oss i disse situasjonene.

Les også:

teknisk support analytiker intervju spørsmål og svar

La oss først se på noen få grunner til at det kanskje ikke er dokumentasjon, til å begynne med:

  1. Hylleprosjekt åpnes igjen
  2. Dokumentasjon mindre format for arbeidsprosess
  3. Dokumentasjon kan eksistere - men er kanskje ikke detaljert eller fullstendig
  4. Kontinuerlige utgivelser og eldre versjonsrelatert informasjon har ikke blitt arkivert, noe som resulterer i et gap i forståelsen av hvordan den eksisterende funksjonaliteten reagerer med den nye

Dette er alle hindringer som vi testere må modig krysse og komme frem med suksess. Hvordan akkurat, ikke sant?

Her er de tre beste metodene for å teste en applikasjon uten krav:

Metode nr. 1:

Arbeid med den lille dokumentasjonen du kan få tak i. Det kan være en grunnleggende enkel forsinkelse (i smidige prosjekter), en hjelpefil, en e-post, en eldre versjon av BRD / FRD eller gamle testtilfeller (se etter disse i ALM-verktøyene dine, og du kan finne dem), etc.

Undersøk, spør rundt, og det er alltid noe dokumentert rettssak, selv om det er tynt.

Når dette ikke ordner seg, må du ikke redusere opplevelsen din som programvarebruker.For eksempel, hvis du må teste en overføring for en bankkonto, trenger ingen å fortelle oss hvordan vi gjør dette, ikke sant? For som nettbankkunder vet vi alle at vi trenger fra og til kontoer med en rekke tilgjengelige midler som skal overføres.

Enig om at ikke alle situasjoner kommer til å være like greie, men igjen, de kan også være det.

Metode nr.2:

Bruk den eldre / gjeldende versjonen av applikasjonen som referanse for å teste den fremtidige utgivelsen av et programvareprodukt. Nå innrømmer jeg at dette er i strid med regelen, 'Skriv aldri testsaker med applikasjonen som referanse'. Men når vi jobber i en mindre enn perfekt situasjon, må vi forme reglene for å passe våre behov.

Det hjelper å holde følgende aspekter i perspektiv når du gjør det:

  • Applikasjonen kan inneholde feil, så hvis systemet etter registrering tar deg direkte til Skjerm1 (en viss hypotetisk skjerm for eksempelets skyld) - Anta aldri at det er riktig oppførsel. Også hvis et felt tar alfanumeriske tegn og er et telefonnummer - et spørsmål som og sørg for at du ikke tar applikasjonen som et gitt eksempel for forventet funksjonalitet.
  • I de ovennevnte situasjonene, bruk din vurdering og ta hjelp av applikasjonen for å gi deg en start, men vær kritisk til den for å stille spørsmål ved at den fungerer.

Metode nr.3:

Snakk med prosjektmedlemmene:

  • Tilbyr å delta på møtene.
  • Spør om du kan delta i enhets- og integrasjonstestingsfasen.
  • Hvis ikke, spør om dev-teamet kan dele resultatene av enhetene og integrasjonstestene sine.
  • Legg til rette for en tid for kunnskapsoverføring på et passende tidspunkt.

La oss nå bruke metodene i et eksempel:

La oss anta at det er et shoppingsted hvor du kan legge til varer i handlekurven. Ideelt sett hvis det var dokumentasjon, trenger den å fortelle oss hvordan vi legger til varer i den, hvor mange varer den kan ha på et gitt tidspunkt, hva som skjer når varen du har lagt til plutselig blir utsolgt, hva er det maksimale antallet av samme varer du kan kjøpe samtidig, etc. Situasjonen vår er at INGEN av det er tilgjengelig på dette tidspunktet.

Bruk metode nr. 1:

Finn all dokumentasjon du kan. Spør dev-teamet ditt om de har mock-up-skjermer / ser i ALM-verktøyet eller noe i det hele tatt. Hvis du finner noe, vil det være et godt utgangspunkt. Men hvis denne metoden ikke viser noe, kan du bruke din testers dom / intuisjon.

Vi vet alle hvordan handlekurver fungerer, så legg til grunn antagelsene dine og kom til noen få grunnleggende scenarier som:

  • Varer kan legges til i handlekurven etter at de er blitt gjennomsøkt eller søkt
  • Når jeg legger til varer i handlekurven, bør listen over varer oppdateres
  • Brukeren skal kunne fortsette å handle selv etter å ha lagt til få varer i handlekurven
  • Hvis du legger til det samme elementet to ganger, økes antallet av elementene som legges til
  • Varene kan oppdateres
  • Elementene kan fjernes
  • Totalen skal være ekvivalent med summen av alle prisene som er lagt til
  • Skatt bør beregnes ut fra postnummeret som er oppgitt
  • Fraktkostnader må legges til tilsvarende

Vi kan fortsette, men jeg er sikker på at du får bildet.

Bruk metode 2:

Hvis det er en eldre versjon av applikasjonen tilgjengelig, kan dette være nyttig når du skriver testtilfellene dine, siden du må skrive de nøyaktige trinnene for hvor du skal klikke, hvor du skal legge inn input, hva du skal sjekke osv. Skjermbilder / mockups / wire- rammer - hvis tilgjengelig kan det også være gode erstatninger.

Som du kan se fra skjermen nedenfor, er disse tingene tydelige - feltnavnene, knappene eller andre elementer som er tilstede osv. (klikk på bildet for forstørret visning)

test uten krav

Nå har testere noen spørsmål som:

  1. Hva skjer når jeg gir en røye i mengdeboksen?
  2. Når legger jeg til for mange ting?
  3. Hva er maksimalt nei. av ting dette kan ta? Etc.

Bruk metode 3 :

Ta listen over spørsmål til BA, utvikleren eller til og med klienten og søk avklaring. Når metode 3 er ferdig, bør du stort sett være utstyrt med all informasjonen du trenger for å skrive detaljerte testtilfeller og utføre testene dine med like stor selvtillit som du ville gjort når omfattende dokumentasjon var tilgjengelig.

Enig om at det er mange flere trinn og mye mer oppfølging, men for å sikre kvalitetstesting er disse trinnene uunngåelige.

For å konkludere, alt går ikke tapt når dokumentasjon ikke eksisterer eller er utilstrekkelig. Det er fortsatt håp! Del dine erfaringer i lignende situasjoner.

Om forfatteren: Dette nyttige innlegget er skrevet av vårt STH-teammedlem Swati S.

Som alltid er dine kommentarer, spørsmål og forslag hjertelig velkomne.

Anbefalt lesing

^