Meni

6 osnovnih vještina koje bi svaki ispitivač (uglavnom svježiji) trebao imati

6 basic skills that every tester should have

Isprobajte Naš Instrument Za Uklanjanje Problema

Softversko testiranje ili QA najbolja je platforma za novopridošlice koji mogu ući u IT industriju unatoč zabludama da je riječ o manje ili manje plaćenom poslu.

Najvažnija vještina koja treba testeru je sposobnost pronalaženja bugova . A ako ste vrsta osobe koja voli pronalaziti bugove, tada ćete voljeti i rasti na ovom polju.

Kad to kažem, malo je više vještina koje vam mogu pomoći u pronalaženju grešaka i boljem radu s QA procesima.

Ovo je članak koji će prikazati postupak osiguranja kvalitete kakav se slijedi u većini tvrtki i pružit će novim ispitivačima pojašnjenja o testiranju.

Potanko ćete naučiti postupak dokumentacije i standarde, predradnju ispitivača, ispitivanje temeljeno na ograničenjima, ispitivanje tijekom djelomičnog razvoja i na kraju postupak odjave.

osnovne vještine testiranja

Započnimo.

Što ćete naučiti:

osnovna java intervju pitanja i odgovori za svježe

# 1. Dokumentacija

Dokumentacija je ključna za testiranje. Većina tvrtki taj zadatak dodjeljuje novoprimljenim. Da biste uspjeli, trebali ste dobar rječnik jer ostatak stvari kao što su standardi dokumentacije itd. nisu pod vašom kontrolom i ovise o procesima tima i tvrtke.

Također pripazite da vidite vrijednost postupka dokumentacije. Prednosti su brojne - pomažu vam pratiti promjene zahtjeva, pratiti korake testa, prijaviti svoj rad itd.

Preporučeno čitanje=> Zašto je dokumentacija važna u testiranju softvera

# 2. Priprema testa

Od svih dostupnih dokumenata, sljedeće se ne može zanemariti. Oni se također nazivaju isporučivim dokumentima i povezuju razumijevanje klijenta, programera i ispitivača.

a) Plan ispitivanja: Ucrtava tijek ispitivanja od početka do kraja .

Plan ispitivanja prikazuje opseg i aktivnosti faze ispitivanja. Stvoren od strane QA vodstva, tim mora doprinijeti i biti u toku sa svime što je napisano u planu testa.

Neki timovi imaju više razina planova ispitivanja: Master plan i fazni planovi.

Plan ispitivanja mora imati:

  • Naziv i verzija projekta
  • Identifikatori plana ispitivanja - kreator, br. Nacrta, datum izrade itd.
  • Uvod - Pregled projekta, cilj i ograničenja
  • Reference - Popis referenci koje se koriste kao ulaz (provjerite koristite li točne i najnovije verzije)
  • Ispitne stavke - moduli, verzija, opseg, izvan opsega itd.
  • Cjelokupni pristup testiranju / strategija ispitivanja - alati za upotrebu, postupak praćenja kvara, razine ispitivanja koje treba izvesti itd.
  • Kriteriji za uspjeh / neuspjeh - Smjernice za izvršavanje testa
  • Kriteriji suspenzije i nastavka
  • Rezultati ispitivanja - Test slučaj, izvještaji o ispitivanjima, izvještaji o programskim pogreškama, mjerni podaci ispitivanja itd.
  • Pojedinosti o testnom okruženju
  • Sastav tima s kontaktnim podacima. za svaki modul ili vrstu ispitivanja
  • Procjene testa - vrijeme i trud. Pojedinosti o proračunu su povjerljive i ovdje ih nećete pronaći
  • Rizici i planovi ublažavanja
  • Odobrenja
  • Ostale smjernice

Također pročitajte=>

kako otvoriti .torrent

b) Scenariji ispitivanja:

Jedan redak upućuje na „što testirati“ na temelju svakog zahtjeva i obično se dokumentira i prati putem proračunskih tablica.

Većina ih sadrži:

  • Naziv modula / komponente / funkcije (prijava, admin, registracija itd.)
  • ID scenarija je za referencu (npr. TS_Login_001)
  • Opis scenarija - ‘Što testirati’ Npr .: Potvrdite ako prijava omogućuje korisnicima s važećim vjerodajnicama da se uspješno prijave
  • Važnost scenarija - Davanje prioriteta u slučaju nedostatka vremena - Visoko / Srednje / Nisko
  • ID zahtjeva - za sljedivost

Daljnje čitanje=>

c) Ispitni slučajevi:

Točni test slučajevi daju točne rezultate ispitivanja. Proračunske tablice i dalje su popularan medij za pisanje testova, posebno za početnike, iako neke tvrtke prilagođavaju alate za upravljanje testovima. Osnova za pisanje testnih slučajeva je dokument SRS / FRD / Req. Ali to nije često dovoljno, pa ćete morati koristiti puno pretpostavki i rasprava s timovima BA / Dev.

Pisanje učinkovitih test slučajeva je najvažnija kvalifikacija koju ispitivač mora imati. Obično su svi testovi kategorizirani kao pozitivni / negativni. Pozitivan test daje valjane podatke i postiže pozitivne rezultate. Negativni testni slučaj daje nevaljane unose i dobiva točnu poruku pogreške.

Za više informacija o njima provjerite:

Neki od uobičajenih atributa koje imaju svi testovi su:

  • ID scenarija - preuzeto iz dokumenta o testnom scenariju
  • ID testnog slučaja - za jedinstvenu identifikaciju i praćenje. Npr .: TC_login_001
  • Opis testa - Kratko objašnjenje ispitanog stanja ispitivanja
  • Koraci za izvršavanje - detaljne upute o koracima kako testirati
  • Podaci o ispitivanju - Podaci dostavljeni u korake ispitivanja
  • Očekivani rezultat - Ishod prema očekivanjima
  • Stvarni rezultat - odgovor AUT-a prilikom pokretanja testa
  • Status - uspješno / neuspješno / nema pokretanja / nedovršeno / blokirano - opisuje rezultat testa
  • Komentari - Za dodatne detalje
  • Izvršio - Testerovo ime
  • Datum izvršenja - Datum pokretanja testa
  • ID kvara - kvar prijavljen na test slučaju, u slučaju neuspjeha testa
  • Pojedinosti o konfiguraciji - OS, preglednik, platforma, podaci o uređaju (nije obavezno)

Preporučeno čitanje=>

# 3. Proces testiranja - Koje testove izvesti?

Postoji ogroman broj vrsta ispitivanja, ali ne mogu se sva provesti na tom AUT. Vrijeme, proračun, priroda posla, priroda aplikacije i interes klijenta ključni su igrači u odabiru testova koji će se raditi na aplikaciji.

Na primjer: Ako se radi o portalu za internetsku trgovinu, tada su testiranja otpornosti na stres i opterećenja obavezna. Međutim, neke od vrsta ispitivanja koje se ne smiju propustiti su:

pitanja o intervjuu za web usluge za sapun i odmor

# 4. Ispitivanje u djelomičnoj fazi razvoja

Općenito, kod srednje razine i novoosnovanih tvrtki ograničeno je vrijeme i resursi. Tester ovdje može započeti svoj postupak testiranja prije integracije modula, što znači da možda radimo testove integracije jedinica i posrednika.

Važno je napomenuti da se rezultati iz ovih faza ne mogu računati kao točni, pa ćete možda morati planirati cjelokupni test crne kutije kad sve bude spremno za rad. Previdjenje tog dijela moglo bi se pokazati skupim i testiranje neučinkovitim.

# 5. Dokument o prijavi greške

Praktično, ovo je najkritičniji QA dokument koji ćete ikad izraditi.

Slijede polja koja mora imati dobro izvješće o greškama:

  • ID kvara - Obično serijski broj
  • Opis kvara - Objašnjenje problema u jednom retku
  • Mjesto - modul / područje AUT-a na kojem je pronađen problem
  • Broj verzije - verzija verzije i koda.
  • Koraci za reprodukciju - Popis koraka koji vas vode do problema
  • Ozbiljnost - postavite razinu za opis ozbiljnosti problema - niska, srednja, visoka, blokator itd.
  • Prioritet - programeri postavljaju kako bi odredili redoslijed kojim će kvar biti otklonjen (P1, P2, P3, itd. P1 - najviši)
  • Dodijeljeno vlasniku kvara u tom trenutku
  • Prijavio - Testerovo ime
  • Status - različit status koji predstavlja fazu životnog ciklusa greške
    • Novo - Pronađena je greška i upravo je prijavljena
    • Otvoreno - potvrđeno od strane voditelja osiguranja kvalitete
    • Dodijeljeno - poslano vodstvu za programere radi dodjele odgovarajućem programeru
    • U tijeku / Work in Progress - Dev je počeo raditi na tome
    • Ispravljeno / riješeno - programer je završio s radom na tome
    • Potvrđeno / zatvoreno - QA tim je ponovno testirao i utvrdio da je greška ispravljena
    • Ponovno testiranje - QA tim se ne slaže s rezolucijom tvrtke Dev i dalje napreduje u programskoj pogrešci
    • Duplikat - Slična greška već postoji
    • Odgođeno - važeća greška, ali će biti ispravljena u kasnijim izdanjima
    • Nevaljano - Nije greška ili se ne može reproducirati ili nema dovoljno podataka

Daljnje čitanje=>

# 6. Postupak odjave

Odjavi se a slanje konačne dokumentacije zadatak je voditelja osiguranja / menadžera. Međutim, tim mora dostaviti gore navedene dokumente (scenarij ispitivanja, test slučaja i dokument dnevnika kvara) na konačne preglede i reviziju.

Obavezno ih lektorirajte i pošaljite konačne verzije.

Također pročitajte=>

Zaključak

To je postupak kojem sam se osobno nagledao i iskusio dok sam bio ispitivač i nadam se da vam je ovo dalo neke korisne upute.

Napokon, karijera u testiranju bila mi je apsolutna radost, a nadam se da je i za vas.

Sve najbolje za vašu karijeru!

Preporučena literatura

^