Transcript Vanda Muhar UVOD U TESTIRANJE UVOD U TESTIRANJE ● Što je to testiranje ● Tipovi testiranja ● Metode testiranja ● Funkcionalno testiranje ● Nefunkcionalno testiranje ● Test dokumentacija ● Certificiranje Što je to testiranje? ● Što je to testiranje? ● Tko.

Vanda Muhar
UVOD U TESTIRANJE
UVOD U TESTIRANJE
●
Što je to testiranje
●
Tipovi testiranja
●
Metode testiranja
●
Funkcionalno testiranje
●
Nefunkcionalno testiranje
●
Test dokumentacija
●
Certificiranje
Što je to testiranje?
●
Što je to testiranje?
●
Tko testira?
●
Kada početi a kada završiti testiranje
●
Verifikacija Vs. Validacija
●
Testiranje vs. Osiguranje kvalitete vs. Kontrola kvalitete
●
Testiranje i debugging
Što je to testiranje?
Testiranje je proces evaluacije sistema ili njegovih komponenti s ciljem
da se zadovolji zadana specifikacija.
Ovaj proces rezultira aktualnim očekivanim ili neočekivanim rezultatima
u odnosu na specifikaciju kao i objektivnim stavom na razumijevanje i
rizike implementacije.
➢
➢
Testiranje je provjeravanje sistema u namjeri da se pronađu
nedostatci, greške, nedostatci i/ili nepoštivanje specifikacije u odnosu
na aktualnu tj. željenu specifikaciju.
According to ANSI/IEEE 1059 standard, Testing can be defined as A
process of analysing a software item to detect the differences
between existing and required conditions (that is defects/errors/bugs)
and to evaluate the features of the software item.
Tko testira?
Ovisno o projektu, metodologiji, vremenu, financijama,
veličini firme...
●
Software testeri
●
Software Quality Assurance
●
QA Analyst
●
Developeri (Unit testing)
●
Voditelj projekta
●
Krajnji korisnik
Kada početi s testiranjem?
Što prije to bolje!!
Testiranje traje od pisanja specifikacije, tijekom cijelog razvoja do
izlaska na tržište.
Ovisno o modelu koji se koristi u SDLC-u testiranje može biti određeno
na Test Fazu kao npr u Waterfall modelu ili na kraju svake produkcije
kao npr u Incremental modelu, i na kraju testiranja cijele aplikacije.
●
●
Testiranje uključuje i provjeru dokumentacije (Requirement
specification, User manual, Online help...)
Testiranje koje obavljaju developeri, kojim provjeravaju ispravnost
svoga koda zove se Unit testing.
Software Development Models
●
Waterfall model
●
V-model
●
Incremental model
●
RAD model
●
Agile model
●
Iterative model
●
Spiral model
●
Prototype Model
Waterfall model
Incremental model
Agile lifecycle
Kada završiti testiranje?
●
Svršetak projekta
●
Svi test caseovi su izvršeni
●
Svršetak faze testiranja
●
●
Nema više prijavljenih bugova ili su ispod dozvoljenog
minimuma
Odlukom projekt managera
Što je Verifikacija?
➔
➔
➔
➔
Verifikacijom utvrđujemo da naš produkt pokriva sve
funkcionalnosti naručene od strane kupca
Verifikacija počinje na početku developmenta; uključuje
revizije, sastanke, evaluacije dokumenata, planova, koda,
specifikacija.
Odgovara na pitanje: RAZVIJAM LI DOBRO PROIZVOD?
Verifikaciju možemo definirati kao evaluaciju softwarea da
bi utvrdili da produkt u određenoj fazi razvoja zadovoljava
uvjete/requiremente koji su zadani na početku te faze.
Što je validacija?
●
●
●
Validacijom utvrđujemo da li system odgovara zadanim
requirementima i odrađuje sve zadane funkcije
Odgovara na pitanje: RAZVIJAM LI DOBAR PROIZVOD?
Validaciju možemo definirati kao proces evaluacije
proizvoda za vrijeme ili na kraju developmenta u svrhu
dokazivanja da proizvod odgovara definirane
requiremente.
Verifikacija Vs. Validacija
Testing, Quality Assurance & Quality Control
➢
➢
Najbitnija razlika između Testiranja i Osiguranja kvalitete je
u procesu.
Testiranje se radi na proizvodu koji je već gotov dok
Osiguranje kvalitete (SQA) osigurava da su svi procesi
ispoštovani i da je konačan proizvod kvalitetan i izrađen po
naručenim requirementima.
Testing, Quality Assurance & Quality Control
Testing & Debugging
TESTIRANJE:
➢
Uključuje proces identifikacije buga/errora/greške u softwareu.
➢
Odvija se u fazi testiranja.
➢
Ne uključuje popravke.
DEBUGGING:
➢
➢
➢
Uključuje proces identifikacije, izdvajanja i popravka
buga/errora/greške u softwareu.
Odvija se u fazi kodiranja od strane developera kada otkriju grešku
Dio je White box testa ili Unit code testiranja kao i popravaka
prijavljenih bugova.
Tipovi testiranja
Manualno testiranje
➢
Tester preuzima rolu krajnjeg usera te testira software bez
ikakvih alata ili skripti da bi pronašao bug ili neočekivano
ponašanje
Automatsko testiranje
➔
Automatsko testiranje ili Test Automation je proces kojima
se pomoću alata ili skripte testira software, tj. Automatizira
se manualni test u svrhu dokazivanja da je funkcionalnost
ostala ispravna
Manualno testiranje
➢
➢
Manualno testiranje je testiranje koje se odvija po napisanoj test
specifikaciji s točno definiranim test caseovima i provodi se
uglavnom na početku, ili nakon produkcije s novim featurima.
Manualno testiranje se dijeli na više faza:
•
Exploratory "istraživačko" testiranje
•
Integration testing
•
Partial system testing
•
System testing
•
User Acceptance testing
Automatsko testiranje
➢
➢
➢
Automatsko testiranje se koristi da bi se automatizirali procesi
regresije (ponovnog vrćenja testova) i osigurali kvalitetu
proizvoda.
Automatsko testiranje je brzo i precizno i može se ponavljati po
potrebi
Osim automatizacije manualnog testiranje može se još koristiti
kod:
–
Performance testa
–
Load testa
–
Stress testa
Kada automatizirati?
●
Kod velikih projekata
●
Continuous integration
●
Projekti koji zahtijevaju često testiranje istih područja
●
Simuliranje puno pristupa aplikaciji (load & stress)
Metode testiranja
●
Black Box testing
●
White Box testing
●
Grey Box testing
Black Box testing
●
●
●
Black Box testing je tehnika testiranja po specifikaciji
vođenoj na bazi inputa i outputa jer je njihov način
gledanja na software kao na crnu kutiju (black box) s
inputima i outputima
Tester ne poznaje kako je komponenta smještena u
sistem. Koncentrira se na to što sistem radi a ne kako
Tester radi sa UI tako da unosi inpute i pregledava outpute
ne baveći se pozadinom.
White Box Testing (glass testing ili open box testing )
●
●
●
White Box testing je detaljno istraživanje interne logike i
strukture koda.
Testeri moraju poznavati kako je software implementiran i
kako radi
Testeri moraju imati pristup kodu i pronaći koji dio koda se
ne ponaša dobro
Grey Box Testing
●
●
●
Grey box Testing je tehnika s ograničenim poznavanjem
sistema na kojem radi aplikacija
Testeri imaju pristup design specifikaciji i pristup bazi
Ovim načinom testeru je puno lakše pripremiti se za test
plan
Funkcionalno testiranje
●
Unit testing
●
Integration Testing
●
System testing
●
Regression testing
●
Acceptance testing
●
Alpha testing
●
Beta testing
Funkcionalno testiranje
●
●
●
Funkcionalno testiranje je tip black box testinga i bazira se
na specifikaciji softwarea koji se testira
Aplikacija se testira tako da se unose inputi i rezultati se
pregledavaju da li su u skladu sa zahtjevima/specifikacijom
Funkcionalno testiranje se obavlja na kompletnom,
integriranom sistemu da bi se procijenilo da li je sistem u
skladu sa specifikacijom
5 koraka Funkcionalnog testiranja
1. Određivanje funkcionalnosti koje aplikacija treba obavljati
2. Kreiranje test inputa/podataka na temelju specifikacije
3. Očekivani output/rezultat baziran na temelju inputa i
specifikacije
4. Pisanje Test Scenarija i izvršavanje test caseova
5. Uspoređivanje dobivenih i očekivanih podataka u
izvršenim testovima
Unit testing
●
●
●
●
Ovaj tip testiranja obavljaju developeri prije nego predaju
proizvod testerima koji će izvršavati test caseove
Developeri koriste drugi set podataka od onih koje koriste
testeri
Cilj unit testa je izolirati svaki dio programa i pokazati su
svi dijelovi po specifikaciji
Negativnost ovoga testa je što su developeri limitirani na
određen broj scenarija koje mogu izvršiti, nakon toga
segmenti kodova se spajaju i šalju na testiranje testerima
Integration Testing
●
●
Integration testom se testira integracija interfejsa između
komponenti, interakcije između više sistema, operativnog
sistema ili hardwarea
Nakon integracije dvije komponente zajedno, obavljamo
integracijski test
Integration testing
●
Integration testing obavlja posebni integration team
●
Postoje dvije metode integration testa
–
Top Down
–
Bottom Up
Integration testing
Regression Testing
●
●
Regression testing se obavlja svaki puta kada dođe do
promjene u softwareu ili bug fixa.
Važno je zbog
–
Minimiziranja propusta nakon nove produkcije
–
Utvrđivanja da dodani elementi nisu utjecali na
funkcionalnost starih
–
Štedi vrijeme i ne ugrožava završetak projekta
System Testing
●
●
●
●
●
Sljedeći nivo testiranja: jednom kad je sistem cijeli i sve komponente
integrirane, obavlja se Sistem test
Sistem test je prvi korak u SDLC kada se aplikacija testira kao cijela
Aplikacija se testira detaljno da se potvrdi funkcionalnost i tehničke
specifikacije
Aplikacija se testira u okružju koje je vrlo slično produkcijskom
okružju gdje će se aplikacija deployati
Sistem test nam omogućava verifikaciju i validaciju requirementa kao
i Arhitekturu aplikacije
Acceptance Testing
Nakon što sistem test ispravi većinu grešaka, sistem će se
dostaviti kod kupca. Tada počinje acceptance test
●
Acceptance test obavlja kupac
●
Cilj je dokazati povjerenje u sistem
●
Bazirano je na validaciji
Alpha Testing
●
Ovaj test se obavlja za vrijeme svih drugih testova a ovim
testom provjeravamo:
–
Gramatičke grešake
–
pravopis
–
Prekinute linkove
–
Instalaciju softwarea na najnižu specificiranu mašinu
–
Uputstva za korištenje softwarea
Beta Testing
●
Testiranje prije releasea
●
Još poznato kao testiranje u pravom svijetu
●
●
Software se daje userima koji će ga instalirati kod sebe i
slati povratne informacije projektnom timu
Što više stvari se popravi u beta fazi, to će kupci biti
zadovoljniji
Non-Functional Testing
●
Perforamance test
●
Load test
●
Stress test
●
Usability test
●
Security test
●
Portability test
Perforamance test
Najćešće se korsti da bi se otkirli problemi u performansama:
–
Network delay.
–
Client side processing.
–
Database transaction processing.
–
Load balancing between servers.
–
Data rendering.
Perforamance test
●
●
Smatra se jednim od najbitnijih testova u aspektima
–
Brzine
–
Kapaciteta
–
Stabilnosti
–
Skalabilnosti
Mogu biti kvalitativna ili kvantitativna ispitivanja i mogu se
podijeliti u 2 tipa – Stress test i Load test
Load test
●
●
●
●
Proces testiranja softwarea tako da se software maksimalno optereti
pristupom i manipulacijom podataka
Ovim testom identificiramo maksimum kapaciteta softwarea i kako će
se on ponašati u vrhuncu korištenja
Najčešće za ovu vrstu testa koriste se alati poput Load Runnera,
AppLoadera, IBM Rational Performance, Jmetera, itd
U alatima se definiraju virtualni useri i izvršavaju se skripte koje
verificiraju Load test. Broj korisnika se aplikacije se može povećavati
ili smanjivati, uglavnom se navodi prema specifikaciji
Stress test
●
Stress test se odvija pod neuobičajenim uvjetima:
–
Prevelik load
–
Nedostatak resursa
–
Nestanak mreže
–
Nepristupačnost bazi podataka
–
Uključivanjem drugih procesa koji bi mogli potrošiti
memoriju, procesor...
Security Testing
●
Pomoću Security testinga utvrđujemo sigurnost i ranjivost softwarea kao npr:
●
Povjerljivost
●
Autentifikaciju
●
Autorizaciju
●
Dostupnost
●
Sigurnost podataka
●
Da je u skladu sa sigurnosnim propisima
●
SQL injection (napadi na bazu)
●
●
cross-site scripting napada
...
Portability Testing
●
Software mora biti iskoristiv i portabilan:
–
Moći se premjestiti s jednog računala na drugo
–
S jednog sistema na drugi
–
Raditi na različitim platformama
Software test dokumentacija
●
Izrađuje se prije i za vrijeme testiranja
●
Pomaže u procjeni vremena
●
Pomoću dokumentacije pratimo progress:
koliko smo testova izvršili
–
Koliko bugova je otvoreno
–
Koliko bugova je završeno
–
Koliko vremena treba za jedan test/segment
Dokumentacija
Test dokumentacija se sastoji od:
● Test Plan
● Test Scenario
● Test Case
● Traceability Matrix
Test Plan
●
Test plan prikazuje strategiju po kojoj će se testovi izvršavati da bi se aplikacija
istestirala
●
Koji će se resursi koristiti
●
Test environment
●
Raspored testiranja
●
Quality Assurance Team Lead je zadužen za Test plan
●
Test plan između ostalog sadrži:
–
Listu testova
–
Listu featurea koji se testiraju
–
Rizike
–
Raspored
–
...
Test Scenario
●
●
Test scenario nam kaže koje područje čemo testirati
Testirati se može jedno ili više područja, svaki scenario
pokriva jedno područje
Test Scenario
●
Test scenario sadrži sve testove vezane za to područje /
modul testiranja i kojim redom se trebaju testovi izvršiti
Test Case
●
Test case sadrži set koraka, uvjeta i inputa koji se koriste za izvršavanje tog taska.
●
Svaki test case sadrži očekivane rezultate
●
Usporedbom dobivenog i očekivanog odlučujemo da li je taj Test case prošao ili pao
●
Testovi se pišu u formatu:
–
Test case ID.
–
Product Module.
–
Product version.
–
Revision history.
–
Purpose
–
Assumptions
–
Pre-Conditions.
–
Steps.
–
Expected Outcome.
–
Actual Outcome.
–
Post Conditions.
Test Case
Pisanje bug reporta
●
Ako je bug report dobro napisan, veća je vjerojatnost da će biti prihvaćen i ispravljen
●
Smisao pisanja bug reporta je da bude popravljen
●
Bug mora sadržavati:
–
Bug ID
–
Naslov (Opis buga u jednoj skraćenoj rečenici)
–
Detalji opis/ Korake po kojima se može reproducirati
–
Ime testera koji ga je prijavio
–
Ime verzije protiv koje se piše bug
–
Ime komponente
–
Platforma
–
Operativni sistem
–
Prioritet
–
Ozbiljnost
–
Ime osobe odjela na kojeg ćemo bug dodijeliti
Prioritet i ozbiljnost bug reporta
●
●
Prioritet bug reporta se označava brojkama 1-5 gdje P1 označava "najveću hitnost" a 5 "kad
stignete"
Ozbiljnost bug reporta označava utjecaj buga na ponašanje softwarea:
–
Blocker: Nemoguć početak/nastavak testiranja
–
Critical: Rušenje aplikacije – gubitak podataka
–
Major: Velike greške u funkcijama
–
Minor: manje greške u funkcijama
–
Trivial: Neke trivijalne greške poput gramatike, boje slova ili slično
–
Enhancement: Zahtjev za poboljšanjem nekog svojstva
Bug report Tips & Tricks
●
Bug valja reproducirati najmanje 3 puta prije nego se prijavi
●
Bug treba prijaviti odmah pri primjećivanju
●
●
●
●
Provjeriti da li postoji greška i na drugim modulima koji imaju slično ili
isto ponašanje
Prije pisanja buga provjeriti u alatu u kojem se bug prijavljuje da nije
već netko drugi prijavio
Svakako provjeriti još jednom što ste napisali u bugu prije nego ga
prijavite
U bug report uvijek kada je moguće dodati trace (trace, or it didn't
happen!)
Bug report sample
Stack trace
Certificiranje
●
●
The International Software Testing Qualifications Board (ISTQB) is a software testing qualification certification
organisation that operates internationally
Currently ISTQB® provides 3 levels of certification:
1.
ISTQB Foundation Level (CTFL)
2.
ISTQB Advanced Level (CTAL)
•
Test Manager
•
Test Analyst
•
Technical Test Analyst
•
3.
•
Advanced Level (CTAL) - Full Advanced Level (after passing the above exams of Advanced
Level)
Expert Level
•
Improving the Test Process
•
Test Management
•
Test Automation (planned to be deployed in 2015)
•
Security Testing (planned to be deployed in 2015)
In USA the corresponding organisation is the ASTQB (American Software Testing Qualifications Board), in
Britain the Information Systems Examination Board (ISEB) is the local board, and in India it is the Indian
Testing Board (ITB)
:)
Happy Testing!
Happy path testing is a well-defined test case that uses known input, that
executes without exception and that produces an expected output.
Happy testing guys!
Vanda Muhar
Happytestinglab.com