Meny

Wireframes - Bør de virkelig testes? Og i så fall, hvordan?

wireframes should they really be tested

Prøv Instrumentet Vårt For Å Eliminere Problemer

Nye traineer kom om bord, og vi hadde en treningskurs å lære programvaretestingskonsepter . Etter å ha sett de entusiastiske ansiktene med sine nesten blanke tanker (profesjonelt), bestemte jeg meg for å ta en avstikker til min rutinemessige trening.

Etter en kort introduksjon, i stedet for å snakke om programvaretesting som jeg vanligvis gjør, kastet jeg et spørsmål til de friske hodene - ‘ Kan noen forklare meg hva til trådramme er? '

Svaret var en pause, og derfor bestemte vi oss for å diskutere det. Og slik startet det - Wireframe / Prototype Testing :)

wireframe prototypetesting

Så, hva er en trådramme? La meg forklare det med noen enkle analogier:

  1. Interiørarkitekten begynner ikke å legge inn møblene og dekorere huset tilfeldig. Han legger på planen sin på papir (eller designprogramvare), diskuterer den med kunden, prøver og endrer planen på en best praktisk måte og implementerer den deretter.
  2. For å forstå hvor alvorlig en kroppsdel ​​er skadet, ser legene på en røntgen. Røntgen er i utgangspunktet et skjelett i kroppen vår og gir riktig informasjon om bein og ledd.
  3. En skredder forbereder papirduken (en slags prototype igjen), gjør hva som helst endringer som kreves og bruker den som basismåling til alt er nøyaktig og han er trygg på å fortsette med den faktiske delen han / hun syr.

Jeg tror disse eksemplene var nok til at noen kunne forstå konseptet med trådramme.

Wireframes er typer prototyper:

De er av begrenset art, noe som betyr at de kan inneholde tomme HTML-sider uten elementer som fungerer eller statiske skjermbilder som er representative for en side / funksjon / element i applikasjonen, og som kanskje mangler farge, grafikk og andre elementer i den faktiske visuelle designen.

For å bygge en solid applikasjon / nettside, er det nødvendig med et solid rammeverk, og trådrammer hjelper med å gi rammeverket ved å gi en skildring av sideoppsettet, det generelle grensesnittet, navigering og funksjonalitet.

Her er noen eksempler på trådrammer:

trådrammeeksempel 2

trådrammeeksempel 1

Hvorfor lager programvareselskaper trådrammer?

Av nøyaktig samme grunn bestemmer skredderen / interiørdesigneren / doktoren seg for å prøve ting først - for å unngå feil, eliminere gjetting, ta kundegodkjenning før de setter alt i stein. Det hjelper med å identifisere problemer tidlig og å gi et glimt av programvaren slik den ser ut når den er ferdig.

Hva du vil lære:

Viktigheten av wireframes / prototypetesting:

Så hvorfor teste noe som er et skjelett og som ikke vil bli sett av brukeren slik det er nå? Med andre ord - Hvorfor bry seg med mellomleddet når det ennå er en dummy?

Bare for å hjelpe til med forebygging av mangler - som er den overordnede agendaen for QA-team (kvalitetssikring = defektforebygging + Feilidentifikasjon ).

Viktigheten av trådrammetesting

Wireframes testing kan hjelpe i følgende:

# 1) Identifisere manglende krav:

La oss si om kravene sier at i a påloggingsside det skal være to inntastingsfelt, påloggings-ID og passord henholdsvis og de 3 knappene, OK-Avbryt- Tilbakestill. Hvis trådrammen er som følger, kan vi lett finne den manglende tilbakestillingsknappen tidlig og innlemme den i applikasjonen.

Hun er prosjektleder, med 10+ års erfaring med programvaretesting.

# 2) Identifisere ekstra krav:

Det motsatte av ovennevnte situasjon kan være at kravet sier at det på en påloggingsside skal være 2 inntastingsfelt, påloggings-ID og passord henholdsvis og 2-knappene, OK & Avbryt. Hvis trådrammen er som følger, kan vi enkelt finne at den har en ekstra tilbakestillingsknapp og søke bekreftelse på om det virkelig er nødvendig.

wireframe testing 2

# 3) Brukervennlighet:

Wireframes er et av de beste alternativene for å teste bruken av produktet / applikasjonen før den utvikles.

Her er trådrammen for en av skjemaene:

wireframe testing 3

Ved første øyekast virker det ok.

Tenk nå som sluttbruker, brukeren som skal fylle ut informasjon i skjemaet. Tror du, det er en måte, dette skjemaet kan være mer brukervennlig? Vel, det tror jeg absolutt.

  • Gi kalendersymbol og begrense brukeren til å velge dato fra kalenderen. Dette vil være nyttig for brukeren, da han ikke trenger å forvirre hvilket datoformat han skal følge, og å velge dato fra kalenderen vil være noe, hver bruker foretrekker.
  • En verktøytips som forklarer hva hvert felt betyr, vil være bra.
  • Sidenavn som tittel kreves for å forstå trådrammen og samkoble feltene.
  • Nødvendige felt skal merkes med * -tegn eller et notat som sier “ Alle felt må fylles ut ”Skal være synlig.
  • Etiketten for det første feltet skal være 'Kampanjenavn', i stedet for 'Navn', for å unngå forvirring for brukerne.

# 4) Tidlig funksjonstesting:

hvilket verktøy kan du bruke til å visuelt representere og analysere en database?

I selve eksemplet ovenfor, fra diagrammet, kan vi muligens gjette hvordan funksjonaliteten kan fungere. Hvis ikke, vil det i det minste føre til videre graving og bedre forståelse av applikasjonen.

  • For eksempel : Hva om brukeren vil legge til flere bestillings-ID-er? Vil applikasjonen overskrive den forrige oppføringen, eller vil den tillate flere oppføringer? Hvordan vil den håndtere og håndtere det?

Som det fremgår av eksemplene ovenfor, hjelper testing av wireframes virkelig til tidlig identifisering av problemer gjennom en statisk wireframe og forhindrer at manglene siver inn i selve applikasjonen. Dette er veldig gunstig ettersom vi vet at feil som ble identifisert tidlig i utviklingsprosessen er billigere å fikse enn de som ble funnet senere.

Verktøy for wireframing:

Det er mange verktøy tilgjengelig i markedet, men man bør bruke verktøyet i henhold til kontekstens egnethet. Mens de fleste verktøyene som Axure, Power mockup, Simulify, Balsamiq etc er betalt, er det noen nyttige gratis wireframing verktøy også:

  1. Cacoo : Cacoo er et brukervennlig tegneverktøy på nettet som lar brukeren lage en rekke diagrammer som nettstedskart, trådrammer, UML og nettverksdiagrammer.
  1. MockupBuilder : MockupBuilder hjelper brukeren med raskt å få ideene sine på skjermen. Det er en GRATIS Silverlight-drevet webapp.
  1. Blyantprosjekt : Pencil Project er gratis og lett å lære. Det kan kjøres som et Firefox-tillegg eller alene.

Når kan (eller skjer) Wireframes-testing forekomme:

  • Før produktutvikling: Dette kan bidra til å identifisere hull eller manglende krav, designfeil, brukervennlighet etc. - Forebygging av feil
  • Innleggsutvikling: I dette tilfellet kan trådrammene brukes som referanser for å validere applikasjonen. - Identifikasjon av feil.

I tilfelle Wireframe-testing for brukervennlighet gjøres det vanligvis manuelt, og det er ofte sanntidsbrukere som er involvert. De blir spurt enten en rekke spørsmål for å forstå deres erfaring eller tilbakemelding, eller de har interaktive trådrammer for å fange tilbakemeldingen.

For å ha detaljert analyse av trådrammer, er noen ganger fageksperter også involvert.

Tjenester som brukertesting kan være veldig nyttig, der man kan legge ut en lenke med trådrammer og etter testing av trådrammer, blir resultatene generert sammen med følgende tilbakemeldingspoeng:

  • En video av hver brukers skjerm som tester trådrammen din.
  • Lyd av brukeren som snakker gjennom hvordan han fullfører oppgavene.
  • Verdifulle tilbakemeldinger om hvordan du kan forbedre nettstedet ditt.

Produksjon av prototypetesting:

Resultatene av wireframes testing er veldig nyttige når det gjelder forståelse av design, navigering, brukervennlighet, generell arbeidsflyt og funksjonalitet. I utgangspunktet, etter wireframes testing, blir wireframes klarere og implementerbare.

Konklusjon:

For å oppsummere fungerer wireframes testing som en proaktiv handling og kan være svært nyttig for å finne brukervennlighet og utforming av smutthull i applikasjonen før utviklingsfasen.

Med dette pakker jeg inn emnet, i et håp om at leserne vil friste meg til å skrive et nytt innlegg om dette ved å stille spørsmål og gi tilbakemelding.

Om forfatteren: Denne artikkelen er skrevet av STH-teammedlem Bhumika. Hun er prosjektleder, med 10+ års erfaring med programvaretesting.

Glad test, som vanlig :)

Anbefalt lesing

^