Menu

6 grundlæggende færdigheder, som hver tester (hovedsagelig friskere) burde have

6 basic skills that every tester should have

Prøv Vores Instrument Til At Fjerne Problemer

Software Testing eller QA er den bedste platform for nybegyndere at komme ind i IT-branchen på trods af misforståelserne om, at det er et mindre eller mindre betalt job.

Den vigtigste færdighed, som en tester har brug for, er evne til at finde bugs . Og hvis du er den slags person, der elsker at finde bugs, vil du elske og vokse inden for dette felt.

Når det er sagt, er der få flere færdigheder, der kan hjælpe dig med at finde fejl og arbejde bedre med QA-processer.

Dette er den artikel, der viser QA-processen, som den følges i de fleste virksomheder, og som giver testere afklaringer om test.

I detaljer lærer du dokumentationsprocessen og standarderne, testets forarbejde, begrænsninger baseret test, test under delvis udvikling og endelig aflogningsprocessen.

grundlæggende testfærdigheder

Lad os begynde.

Hvad du vil lære:

# 1. Dokumentation

Dokumentation er afgørende for testning. De fleste virksomheder tildeler denne opgave til nytilkomne. For at få succes skal du have godt ordforråd fordi resten af ​​ting som dokumentationsstandarder osv. ikke er under din kontrol og afhænger af teamets og virksomhedens processer.

Sørg også for at se værdien af ​​dokumentationsprocessen. Fordelene er mange - de hjælper dig med at spore kravændringer, spore dine testtrin, logge dit arbejde osv.

Anbefalet læsning=> Hvorfor dokumentation er vigtig i softwaretest

# 2. Testforberedelse

Af alle tilgængelige dokumenter kan følgende ikke overses. Disse kaldes også som leverbare dokumenter, og de bygger bro mellem klient, udvikler og testere.

a) Testplan: Kortlægger teststrømmen fra start til slut .

Testplan viser omfanget og aktiviteterne i testfasen. Oprettet af QA-lederen, skal holdet bidrage og holde sig opdateret om alt, hvad der er skrevet i testplanen.

Nogle hold har flere niveauer af testplaner: Masterplan og fasevis planer.

En testplan skal have:

  • Projektnavn og version
  • Testplanidentifikatorer - Skaber, kladdenummer, oprettelsesdato osv.
  • Introduktion - Oversigt over projektet, mål og begrænsninger
  • Referencer - Liste over referencer, der bruges som input. (Sørg for at bruge de nøjagtige og nyeste versioner)
  • Testgenstande - Moduler, version, scope, out of scope osv.
  • Samlet testtilgang / teststrategi - værktøjer til brug, fejlsporingsproces, testniveauer, der skal udføres osv.
  • Kriterier for bestået / ikke bestået - Retningslinjer for testudførelse
  • Suspension & Genoptagelseskriterier
  • Testleverancer - Testcase, testrapporter, bugrapport, testmetrics osv.
  • Test miljøoplysninger
  • Teamliste med kontaktpunktinfo. for hvert modul eller testtype
  • Testestimater - Tid og kræfter. Budgetoplysninger er fortrolige, og du finder dem ikke her
  • Risici og afbødningsplaner
  • Godkendelser
  • Andre retningslinjer

Læs også=>

b) Testscenarier:

Én linje peger på 'hvad man skal teste' baseret på hvert krav og normalt dokumenteret og spores gennem regneark.

De fleste af dem indeholder:

  • Modul / komponent / funktionsnavn (login, admin, registrering osv.)
  • Scenarie-ID er til reference (F.eks .: TS_Login_001)
  • Scenariobeskrivelse - 'Hvad skal man teste' F.eks .: Valider, hvis login giver brugere med gyldige legitimationsoplysninger mulighed for at logge ind
  • Scenariobetydning - At prioritere i tilfælde af utilstrækkelig tid - Høj / Medium / Lav
  • Krav-id - for sporbarhed

Yderligere læsning=>

c) Test tilfælde:

Nøjagtige testsager giver nøjagtige testresultater. Regneark er stadig det populære medium til test case skrivning, især for begyndere, selvom nogle virksomheder tilpasser testadministrationsværktøjer. Grundlaget for skrivning af testsag er SRS / FRD / Req-dokumentet. Men det er ikke ofte tilstrækkeligt, så du bliver nødt til at bruge en masse antagelse og diskussion med BA / Dev-hold.

Skrivning af effektive testsager er den vigtigste kvalifikation, som en tester skal have. Normalt er alle testsager kategoriseret som positive / negative. Positiv test sag giver gyldige input og får positive resultater. Negativ test sag giver ugyldige input og får den nøjagtige fejlmeddelelse.

For mere information om disse, se:

Nogle af de almindelige attributter, som alle testsager har, er:

  • Scenarie-id - taget fra testscenariedokument
  • Test case ID - Til unik identifikation og sporing. F.eks .: TC_login_001
  • Testbeskrivelse - Kort forklaring af testet test test
  • Trin til udførelse - Detaljerede trinvise instruktioner om, hvordan man tester
  • Testdata - Data leveret til testtrinnene
  • Forventet resultat - Resultat som forventet
  • Faktisk resultat - Svar fra AUT, når testen køres
  • Status - Pass / Fail / No Run / Incomplete / Block - Beskriver resultatet af testen
  • Kommentarer - til yderligere detaljer
  • Udført af - Testers navn
  • Udført dato - Dato, hvor testen køres
  • Defekt-id - Fejl logget mod testsagen i tilfælde af testfejl
  • Konfigurationsoplysninger - OS, browser, platform, enhedsoplysninger (valgfri)

Anbefalet læsning=>

# 3. Testproces - Hvilke tests skal udføres?

Der er et stort antal testtyper, men ikke alle kan udføres på den AUT. Tid, budget, virksomhedens art, applikationens art og kundens interesse er nøgleaktørerne i valget af, hvilke tests der skal udføres på applikationen.

For eksempel: Hvis det er en online-handelsportal, er stresstest og belastningstest obligatorisk. Nogle af de testtyper, der ikke bør gå glip af, er dog:

# 4. Testning på det delvise udviklingsstadium

Generelt med mellemstore virksomheder og opstartsvirksomheder er der begrænset tid og ressourcer. Testere her starter muligvis deres testproces inden modulintegration, hvilket betyder, at vi muligvis laver enhedstest og mellemliggende integrationstest.

Det er vigtigt at bemærke, at resultaterne fra disse faser ikke kan tælles som nøjagtige, så du bliver muligvis nødt til at planlægge en samlet black box-test, når alt er klar til brug. Overblik over den del kan vise sig at være dyr og testning, ineffektiv.

# 5. Fejlrapportdokument

Hands on, dette er det mest kritiske QA-dokument, du nogensinde vil lave.

Følgende er de felter, en god fejlrapport skal have:

  • Defekt-id - Normalt et serienummer
  • Fejlbeskrivelse - En linjeforklaring af problemet
  • Placering - modul / område af AUT, hvor problemet findes
  • Bygningsnummer - Version og kode build nr.
  • Trin til reproduktion - Liste over trin, der fører dig til problemet
  • Sværhedsgrad - Indstil et niveau for at beskrive problemets alvor - Lav, medium, høj, blokering osv.
  • Prioritet - Indstillet af udviklere for at bestemme rækkefølgen, i hvilken fejlen skal rettes (P1, P2, P3 osv. P1 - højest)
  • Tildelt til - Ejer af manglen på det tidspunkt
  • Rapporteret af - Testers navn
  • Status - Forskellig status til at repræsentere bugens livscyklusfase
    • Ny - Bug findes og rapporteres bare
    • Åben - Valideret af ledelsen i QA
    • Tildelt - sendt til dev-leadet for tildeling til den respektive udvikler
    • I gang / Work in Progress - Dev begyndte at arbejde på det
    • Fast / løst - Udvikler er færdig med at arbejde på det
    • Bekræftet / lukket - QA Team har testet igen og fundet fejlen rettet
    • Retest - QA-teamet er ikke enig i Devs opløsning og videreudvikler bugten til omarbejdning
    • Duplikat - Der findes allerede en lignende fejl
    • Udskudt - Gyldig fejl, men løses i senere udgivelser
    • Ugyldig - Ikke en fejl eller er ikke reproducerbar, eller der er ikke nok information

Yderligere læsning=>

# 6. Afmeldingsproces

Log af og at sende endelig dokumentation er QA-lederens / lederens opgave. Teamet skal dog indsende ovennævnte dokumenter (testscenarie, testsag og defektlogdokument) til endelig gennemgang og revision.

Sørg for, at du korrekturlæser dem alle og sender de endelige versioner.

Læs også=>

Konklusion

Dette er den proces, som jeg har været vidne til og oplevet på førstehånd, da jeg var tester, og jeg håber, at dette har givet dig nogle nyttige tip.

hvordan man laver din egen firewall

Endelig har en karriere inden for test været en absolut glæde for mig, og jeg håber, det er også for dig.

Alt det bedste for din karriere!

Anbefalet læsning

^