Meny

6 grunnleggende ferdigheter som hver tester (hovedsakelig ferskere) burde ha

6 basic skills that every tester should have

Prøv Instrumentet Vårt For Å Eliminere Problemer

Software Testing eller QA er den beste plattformen for nykommere å gå inn i IT-bransjen til tross for misforståelsene om at det er en mindre eller mindre betalt jobb.

Den viktigste ferdigheten en tester trenger er evne til å finne feil . Og hvis du er den typen person som elsker å finne insekter, så kommer du til å elske og vokse i dette feltet.

Når det er sagt, er det få flere ferdigheter som kan hjelpe deg med å finne feil og jobbe med QA-prosesser bedre.

Dette er artikkelen som viser QA-prosessen slik den følges i de fleste selskaper, og som vil gi nye testere avklaringer om testing.

I detalj lærer du dokumentasjonsprosessen og standardene, testarbeidets forarbeid, begrensningsbasert testing, testing under delvis utvikling og til slutt avloggingsprosessen.

grunnleggende testferdigheter

La oss begynne.

Hva du vil lære:

#1. Dokumentasjon

Dokumentasjon er viktig for testing. De fleste selskaper tilordner denne oppgaven til nykommere. For å lykkes, bør du ha godt ordforråd fordi resten av ting som dokumentasjonsstandarder osv. ikke er i din kontroll og avhenger av teamets og selskapets prosesser.

Sørg også for at du ser verdien av dokumentasjonsprosessen. Fordelene er mange - de hjelper deg med å spore kravendringer, spore teststrinnene, logge arbeidet osv.

Anbefalt lesing=> Hvorfor dokumentasjon er viktig i programvaretesting

# 2. Testforberedelse

Av alle tilgjengelige dokumenter kan følgende ikke overses. Disse kalles også som leverbare dokumenter, og de bygger bro over klient, utvikler og testerforståelse.

a) Testplan: Kartlegger testflyten fra start til slutt .

Testplan viser omfanget og aktivitetene i testfasen. Laget av QA-lederen, må teamet bidra og holde seg oppdatert om alt som er skrevet i testplanen.

Noen lag har flere nivåer av testplaner: Masterplan og fasemessige planer.

En testplan må ha:

  • Prosjektnavn og versjon
  • Testplanidentifikatorer - Skaper, utkast nr., Dato opprettet osv.
  • Innledning - Oversikt over prosjektet, mål og begrensninger
  • Referanser - Liste over referanser som brukes som input. (Pass på at du bruker de nøyaktige og siste versjonene)
  • Testelementer - moduler, versjon, omfang, utenfor omfang osv.
  • Overordnet testtilnærming / teststrategi - Verktøy å bruke, feilsporingsprosess, testnivåer å utføre osv.
  • Bestått / ikke bestått elementkriterier - Retningslinjer for testutførelse
  • Suspensjon og gjenopptakelseskriterier
  • Testleveranser - Testtilfelle, testrapporter, feilrapport, testberegninger osv.
  • Test miljødetaljer
  • Teamliste med kontaktinformasjon. for hver modul eller testtype
  • Testestimater - Tid og krefter. Budsjettdetaljer er konfidensielle, og du finner dem ikke her
  • Risiko og avbøtende planer
  • Godkjenninger
  • Andre retningslinjer

Les også=>

b) Testscenarier:

Én linje peker på 'hva du skal teste' basert på hvert krav, og blir vanligvis dokumentert og sporet gjennom regneark.

De fleste av dem inneholder:

  • Modul / komponent / funksjonsnavn (innlogging, admin, registrering osv.)
  • Scenario-ID er som referanse (F.eks .: TS_Login_001)
  • Scenariobeskrivelse - ‘Hva du skal teste’ F.eks .: Valider hvis pålogging tillater brukere med gyldig legitimasjon å logge inn
  • Scenario Viktighet - Å prioritere i tilfelle utilstrekkelig tid - Høy / Middels / Lav
  • Krav-ID - For sporbarhet

Videre lesning=>

c) Prøvesaker:

Nøyaktige testtilfeller gir nøyaktige testresultater. Regneark er fremdeles det populære mediet for prøveskriving, spesielt for nybegynnere, selv om noen selskaper tilpasser testadministrasjonsverktøy. Grunnlaget for prøveskriving er SRS / FRD / Req-dokumentet. Men det er ikke ofte tilstrekkelig, så du må bruke mye antagelse og diskusjon med BA / Dev-team.

Skrive effektive testsaker er den viktigste kvalifikasjonen en tester må ha. Vanligvis er alle testtilfeller kategorisert som positive / negative. Positiv prøvesak gir gyldige innspill og får positive resultater. Negativ prøvesak gir ugyldige innganger og får den eksakte feilmeldingen.

For mer informasjon om disse, sjekk:

Noen av de vanlige egenskapene som alle testtilfeller har, er:

  • Scenario-ID - hentet fra testscenariedokumentet
  • Test case ID - For unik identifikasjon og sporing. F.eks .: TC_login_001
  • Testbeskrivelse - Kort forklaring av testet tilstand testet
  • Fremgangsmåte - Detaljerte trinnvise instruksjoner om hvordan du tester
  • Testdata - Data levert til teststrinnene
  • Forventet resultat - Resultat som forventet
  • Faktisk resultat - Svar fra AUT når testen kjøres
  • Status - Bestått / Mislykket / Ingen kjøring / Ufullstendig / Blokkert - Beskriver resultatet av testen
  • Kommentarer - Til ytterligere detaljer
  • Utført av - Testers navn
  • Utført dato - Dato da testen kjøres
  • Defekt-ID - Feil logget mot testsaken, i tilfelle testfeil
  • Konfigurasjonsdetaljer - OS, nettleser, plattform, enhetsinformasjon (valgfritt)

Anbefalt lesing=>

# 3. Testprosess - Hvilke tester skal du utføre?

Det er et stort antall testtyper, men ikke alle kan utføres på den AUT. Tid, budsjett, virksomhetens art, applikasjonens natur og kundens interesse er nøkkelaktørene i valget av hvilke tester som skal gjøres på applikasjonen.

For eksempel: Hvis det er en online handelsportal, er stresstesting og belastningstest obligatorisk. Imidlertid er noen av testtypene som ikke bør gå glipp av:

# 4. Testing på delvis utviklingsstadium

Vanligvis er det begrenset tid og ressurser med mellomstore selskaper og oppstartsbedrifter. Testere her kan starte testprosessen før modulintegrering, noe som betyr at vi kan gjøre integrasjons- og mellomtest.

Det er viktig å merke seg at resultatene fra disse trinnene ikke kan telles som nøyaktige, så du må kanskje planlegge en samlet svart bokstest når alt er klart til bruk. Å overse den delen kan vise seg å være kostbar og testing, ineffektiv.

# 5. Feilrapportdokument

Dette er det mest kritiske QA-dokumentet du noensinne vil lage.

hva slags e-postmeldinger er der

Følgende er feltene en god feilrapport må ha:

  • Defekt ID - Vanligvis et serienummer
  • Feilbeskrivelse - En linje forklaring av problemet
  • Plassering - Modul / område av AUT der problemet er funnet
  • Byggnummer - Versjons- og kodenummer nr.
  • Fremgangsmåte for å reprodusere - Liste over trinn som fører deg til problemet
  • Alvorlighetsgrad - Sett et nivå for å beskrive alvoret i problemet - Lav, middels, høy, blokkering, etc.
  • Prioritet - Angis av utviklere for å bestemme rekkefølgen som feilen skal fikses i (P1, P2, P3, etc. P1- høyest)
  • Tildelt til - Eier av mangelen på det tidspunktet
  • Rapportert av - Testers navn
  • Status - Ulike status for å representere bug livssyklusstadiet
    • Ny - Bug er funnet og rapporteres bare
    • Åpen - Validert av QA-ledelsen
    • Tildelt - Sendt til utviklingsledningen for tildeling til den respektive utvikleren
    • In Progress / Work in Progress - Dev begynte å jobbe med det
    • Fast / løst - Utvikler er ferdig med å jobbe med det
    • Bekreftet / lukket - QA Team har testet på nytt og funnet feilen løst
    • Test på nytt - QA-teamet er ikke enig i Devs oppløsning og videreutvikler feilen for omarbeiding
    • Dupliser - Lignende feil eksisterer allerede
    • Utsatt - Gyldig feil, men vil bli løst i senere utgivelser
    • Ugyldig - Ikke en feil eller er ikke reproduserbar eller det er ikke nok informasjon

Videre lesning=>

# 6. Avloggingsprosess

Logg av og å sende sluttdokumentasjon er QA-lederens / lederens oppgave. Teamet må imidlertid sende inn ovennevnte dokumenter (testscenario, testsak og mangelloggdokument) for endelig gjennomgang og revisjon.

Forsikre deg om at du korrekturleser dem alle og sender de endelige versjonene.

Les også=>

Konklusjon

Dette er prosessen som jeg har vært vitne til og opplevd på førstehånd da jeg var tester, og jeg håper dette har gitt deg noen nyttige tips.

Endelig har en karriere i testing vært en absolutt glede for meg, og jeg håper det er for deg også.

Alt det beste for karrieren din!

Anbefalt lesing

^