Meny

Dokumentasjonsveiledning for programvaretesting (hvorfor det er viktig)

software testing documentation guide

Prøv Instrumentet Vårt For Å Eliminere Problemer

I programvaretesterkarrieren min har jeg aldri hørt folk snakke mye om dokumentasjon for programvaretesting. Den generelle oppfatningen om testdokumentasjon er at alle som har ledig tid kan gjøre dokumentasjonen som en testsak, testplan, statusrapport, feilrapport, prosjektforslag osv.

Selv stresset jeg ikke mer med dokumentasjonen, men jeg kan si at det er min vane å plassere alle dataene i svart-hvitt og å oppdatere andre om det også.

Dokumentasjonsveiledning for programvaretesting (hvorfor det

Hva du vil lære:

Min erfaring

Vil bare dele min erfaring med deg:

Vi hadde levert et prosjekt (med et ukjent problem i det) til en av våre klienter (sint klient). Og de fant problemet på en klientside, noe som var en veldig dårlig situasjon for oss, og som vanlig var all skyld QA.

Problemet var noe angående kompatibiliteten til ett nettsted. Når det gjaldt meg, hadde jeg bevis på at jeg ikke fikk et slikt kravdokument som sier at jeg også må sjekke kompatibiliteten til nettstedet. Takk gud for at jeg var trygg.

Det var leksjonen for meg, jeg innså viktigheten av dokumentasjon og fra den dagen begynte jeg å jobbe med dokumenter og opprettet testdokumenter som testplan, testtilfeller, sjekkliste for fornuftstest, feilrapport og mange.

“Blekk er bedre enn det beste minnet” - kinesisk ordtak

Testdokumentasjon: Hva er det?

Vi har alle lest forskjellige artikler om testing av teknologier og metoder, men hvor mange av oss har sett artikler om dokumentasjon? Det er utvilsomt få. Er det ikke dokumentene som er viktige? Nei, men det er fordi vi ennå ikke har innsett viktigheten av dokumenter.

Men hvis vi observerer, er faktum, prosjekter som har alle dokumentene har høy modenhet.

De fleste selskaper legger ikke engang litt vekt på dokumentasjonen like mye de gir til programvareutviklingsprosessen. Hvis vi søker på nettet, kan vi finne forskjellige maler for hvordan du lager forskjellige typer dokumenter. Men hvor mange av dem brukes egentlig av organisasjoner eller enkeltpersoner?

Faktum er at nøye dokumentasjon kan spare organisasjonens tid, krefter og penger.

Mens du går for alle typer sertifiseringer, hvorfor det blir lagt vekt på dokumentasjon, er det bare fordi det viser viktigheten av klient og prosesser for individ og organisasjon. Med mindre du er i stand til å produsere et dokument som er behagelig for brukeren, uansett hvor godt produktet ditt er, kommer ingen til å godta det.

Det er min erfaring, vi eier ett produkt som har litt forvirrende funksjonalitet.

Da jeg begynte å jobbe med det, ba jeg om noen hjelpedokumenter til Manager, og jeg fikk svaret 'Nei, vi har ingen dokumenter'. Da gjorde jeg et spørsmål om det, for som en kvalitetssikring visste jeg at ingen kan forstå hvordan bruk produktet uten dokumenter eller opplæring. Og hvis brukeren ikke er fornøyd, hvordan skal vi tjene penger på det produktet?

“Mangel på dokumentasjon blir et problem for aksept” - Wietse Venema

Selv det samme gjelder bruksanvisninger. Ta et eksempel på Microsoft, de lanserer hvert produkt med riktige dokumenter, selv for Office 2007 har vi slike dokumenter, som er veldig forklarende og enkle å forstå for alle brukere. Det er en av grunnene til at alle produktene deres lykkes.

hvordan du konfigurerer en brannmur i et nettverk

I små selskaper har vi alltid hørt 'prosjekt avviser i forslags- eller kickoff-fase', det er bare fordi dokumentasjonen i forslaget mangler kortfattet og uttrykksfullt språk, og å vise organisasjonens evner.

Det er ikke det at små bedrifter ikke kan levere prosjekter av god kvalitet, men det er deres manglende evne til å uttrykke sin evne. (Jeg jobbet også med en liten organisasjon på 80 ansatte, og jeg hørte dette mange ganger)

Jeg føler personlig at kvalitet er den eneste avdelingen som kan gjøre det mulig. Vi er den eneste avdelingen som kan argumentere for dette og kan gi en vellykket fremtid for våre organisasjoner.

La oss organisere alle diskusjoner i få punkter i kvalitetsperspektiv:

- Avklare kvalitetsmål og metoder
- Sikre klarhet om oppgaver og konsistens i ytelsen
- Sikre intern koordinering i klientarbeidet
- Gi tilbakemelding på forebyggende handlinger
- Gi tilbakemelding for planleggingssyklusen din
- Lag objektive bevis for ytelsen til kvalitetsstyringssystemet ditt

10 tips som hjelper deg med å oppnå testdokumentasjonsmål

Som jeg nevnte i mitt tidligere innlegg, er forståelsen av dokumentasjon for programvaretesting generelt 'Det kan bare gjøres av den som har ledig tid'. Vi trenger å endre dette tankesettet, og da er det bare vi som kan bruke dokumentasjonskraft på prosjektene våre.

Det er ikke det at vi ikke vet hvordan vi skal gjøre dokumentasjonen riktig. Vi synes ikke det er viktig.

Alle må ha standardmaler for alle slags dokumenter som starter fra teststrategi, testplan, testtilfeller og testdata til feilrapporten.

Dette er bare for å følge noen standarder (CMMI, ISO, etc.), men når det gjelder den faktiske implementeringen, hvor mange av disse dokumentene brukes egentlig av oss? Vi trenger bare å synkronisere kvalitetsprosessen vår med dokumentasjonsstandarder og en annen prosess i en organisasjon.

Det enkleste å følge med på all slags dokumentasjon er å involvere en person i prosjektet fra startfasen som forstår prosjektdynamikken, domenet, målet og teknologien. Og hvem som er bedre enn en QA-person for dette (selvfølgelig er det tekniske forfattere til stede for å gjøre dette - men med tanke på et generelt scenario med små selskaper der tekniske forfattere ikke er til stede).

For å oppnå dette målet med testing og dokumentasjon, føler jeg at vi trenger å fokusere på noen punkter.

Her er de ti beste tipsene for å hjelpe deg med å nå testdokumentasjonsmålet:

#1) QA bør involvere seg i den aller første fasen av prosjektet, slik at QA og Documentation fungerer hånd i hånd.

#to) Prosessen som er definert av QA, bør følges av tekniske personer, dette hjelper med å fjerne de fleste feilene på et veldig innledende stadium.

# 3) Bare å skape og vedlikeholde Maler for testing av programvare er ikke nok, tving folk til å bruke dem.

# 4) Ikke bare lag og la dokumentet, oppdater når det er nødvendig.

# 5) Endringskrav er en viktig fase i prosjektet. Ikke glem å legge dem til listen.

# 6) Bruk versjonskontroll for alt. Dette vil hjelpe deg med å administrere og spore dokumentene dine enkelt.

# 7) Gjør reparasjonsprosessen enklere ved å dokumentere alle feil. Sørg for å ta med en klar beskrivelse av feilen, reprodusere trinn, berørt område og detaljer om forfatteren mens du dokumenterer feil.

# 8) Prøv å dokumentere hva som kreves for at du skal forstå arbeidet ditt og hva du trenger å produsere til interessentene dine når det er nødvendig.

# 9) Bruk standardmalen for dokumentasjon. Som en hvilken som helst excel arkmal eller doc-filmal, og hold deg til den for alle dine dokumentbehov.

# 10) Del alle prosjektrelaterte dokumenter på ett sted, tilgjengelig for alle teammedlemmer for referanse, og oppdater dem når det er nødvendig.

Jeg sier ikke at ved å bruke trinn vil du få plutselige resultater. Jeg vet at denne endringen ikke vil skje om en dag eller to, men i det minste kan vi begynne slik at disse endringene begynner sakte.

Tross alt 'trenger dokumentasjonen dokumentasjon'. Er det ikke?

Det er hundrevis av dokumenter som brukes i programvaren utvikling og testing livssyklus.

Viktige programvaretestdokumenter

Her lister jeg opp noen viktige programvaretestedokumenter som vi trenger å bruke / vedlikeholde regelmessig:

1) Testplan
2) Testdesign og Test Case Spesifikasjon
3) Teststrategi
4) Testoversiktsrapporter
5) Ukentlig statusrapport
6) Brukerdokumenter / håndbøker
7) Brukerakseptrapport
8) Risikovurdering
9) Testlogg
10) Feilrapporter
elleve) Testdata
12) Testanalyse

Programvaretestere må også regelmessig henvise til følgende dokumenter:
1) Spesifikasjoner for programvarekrav
2) Funksjonelle dokumenter

Konklusjon

Programvaretestdokumenter spiller alltid en viktig rolle i prosjektutviklings- / testfasen. Så hold alltid ting dokumentert når det er mulig. Ikke stol på verbal kommunikasjon. Vær alltid på den sikre siden.

Dokumentasjon vil ikke bare redde deg, men også hjelpe organisasjonen i det lange løp og spare tusenvis av dollar på opplæring og enda viktigere på å løse problemer forårsaket av mangel på utviklings- og testdokumenter.

Ikke dokumenter bare for å unngå å peke med fingrene på deg, men vanen med dokumentasjon vil absolutt gi en systematisk tilnærming til testprosessen din, og etterlate ad hoc-testingen.

Om forfatter: Denne artikkelen er skrevet av STH-teammedlem Tejaswini. Hun jobber som QA-leder i en organisasjon.

Hvilke andre dokumenter opprettholder du i de daglige testaktivitetene dine?

Anbefalt lesing

^