QUALITY

ASSURANCE

CURS 3

AGENDA

• Change of plans – TRP vine saptamana viitoare

• Planificare si executie

• Automation

• Unit testing

• Test Driven Development

• Continuous Integration

PLANIFICARE

EXECUTIE

PLANIFICAREA SI EXECUTIA TESTARII

• Activitati importante

• Planificare si pregatire

• Testare

• Analiza si follow-up

• Planificare

• Stabilirea obiectivelor

• Stabilirea strategiei

• Pregatire

• Pregatire test cases si suite de teste

• Pregatirea procedurii de testare

• Test cases = o instanta a unui use case compusa din date

intrare, conditii de executie si rezultate asteptate

PLANIFICARE SI EXECUTIE

• Stabilirea obiectivelor

• Perspectiva beneficiarului despre calitate

• Asteptarile beneficiarului cu privire la calitate

• Maparea la obiectivele interene

• Strategia

• Obiective specifice pentru testare (module, functii, etc)

• Tehnici (si modele) de folosit

• Date masurate

• Analiza si follow-up

PLANIFICARE SI EXECUTIE

• Procedura pentru pregatirea testelor

• Pregatirea test caseurilor

• Test caseuri individuale

• Alocarea test caseurilor

• Pregatirea procedurii de testare

• Ordine

• Flow

• follow-up

PLANIFICARE SI EXECUTIE

• Pregatirea test case-urilor individuale

• Test caseuri individuale (micro) vs suite de teste (macro)

• Din surse multiple

• Executie efectiva (usage based)

• Bazate pe implementare (white-box)

• Bazate pe specificatii (black-box)

• Utilizarea de produse/proiecte similare/precedente

PLANIFICARE SI EXECUTIE

• Pregatirea suitelor de test (macro)

• Organizare si managemen in general ierarhic

• Modul • Sub modul

• Test case

• Functionalitate

• UI

• Adaugarea de test cases

• Estimarea numarul de test cases adaugate

• Specificarea

• Integrarea cu cele existente (flow) • Nu poti testa remember password pana nu ai testat create account

• Consideratii

• De la simplu la complex

• Dependenta dintre test cases

PLANIFICARE SI EXECUTIE

• Executarea testelor

• Alocarea timpului

• Acoperirea sectiunilor critice

• Acoperirea functiilor/structurilor

• Bottom-up

• Test case-uri individuale => timp

• Suma

• Per componente, etc

• Invocarea test caseurilor

• In secventa ierarhica

• Analiza outputului pentru a identifica deviatii

• Deviatie = defect?

• Deviatie = defect

• Colectarea informatiilor: unde/ce/cand/severitate/etc

PLANIFICARE SI EXECUTIE

• Analiza si followup

• Analiza rezultatelor

• Baza pentru followup

• Luarea deciziilor (exit testing?)

• Schimbari sau imbunatatiri

• Intrare

• Informatii despre executia test case-urilor (timp)

• Test case-uri care nu trec

• Iesire

• Pentru test case-urile care nu trec

• Identificarea problemei/raportare

• Replicabilitate

• Analiza stabilitatii (model V)

PLANIFICARE SI EXECUTIE

• Pentru fiecare test case

• Succes

• Continua

• Failure

• Intelegera problemei prin studierea contextului

• Recrearea problemei (confirmare)

• Diagnostic (poate fi necesara rularea repetata a testului)

• Localizare

• Fix (Modificari cod sau design)

• Retestare

NEXT STEPS? AUTOMATION

• Nu doar unit testing! Inclusiv pentru black-box testing.

• Necesar pentru sistemel mari

• Automatizare completa este imposibila

• Focus pe module specifice

• Aspecte cheie

• Nevoi specifice si potential

• Aplicatii existente si costuri aferente (cost/training/etc)

• Costuri aditionale din utilizare si suport

• Impact asupra resurselor si planificarii

AUTOMATION

• Automation in activitatile cheie

• Planificarea si pregatirea testelor automate

• Executia testelor automate

• Masurare, analiza, followup pentru testele automate

• Planificarea si pregatirea testelor automate

• Planificare: activitate specific umana

• Constructia modelului: similar ca mai sus, automatizare posibila la scara mica (bespoke)

• Generarea test case-urilor: manuala

• Executie

• Semi automatica

• Secventierea este importanta

• Masurare, analiza, followup

• Masurarea este dictata de nevoile pentru analiza

• Cel mai comun se masoara “coverage” si numarul de defecte

UNIT

TESTING

UNIT TESTING

• Scenarii dificile de testat

• Modele de obiecte inchise/proprietare (SharePoint, Silverlight)

• Arhitectura client server

• Actiuni “out-of-process” (interogari DB)

• UI (GUI interaction)

• xUnit numele colectiv dat diferitor frameworkuri de unit testing

• Se bazeaza pe un design a lui Kent Beck implementat pentru

Smalltalk

• Erich Gamma a portat SUnit pe Java si a creat JUnit

• A fost portat dupa si pe alte platform: CPPUnit, NUnit, etc

UNIT TESTING

• Toate framework-urile xUnit au aceiasi arhitectura de baza

• Test case

• Cea mai elementara clasa

• Toate testele sunt derivate din ea

• Test fixtures

• Test context

• Un set de preconditii necesare pentru rulare

• Test suite

• O suita de teste care folosesc acelasi Test Fixture

• Ordinea executiei nu ar trebui sa conteze

• Executie

• Setup() – pregatirea mediului izolat de test

• …

• Teardown() – curatarea mediului izolat de test – transaction roll-back

• Assert

• Functie sau macro care verifica comportamentul sau starea

• Esecul executiei unui Assert arunca o exceptie care intrerupe executia normala a testului

UNIT TESTING

public class TestAdder {

public void testSum() {

Adder adder = new AdderImpl();

assert(adder.add(1, 1) == 2);

assert(adder.add(1, 2) == 3);

assert(adder.add(2, 2) == 4);

assert(adder.add(0, 0) == 0);

assert(adder.add(-1, -2) == -3);

assert(adder.add(-1, 1) == 0);

assert(adder.add(1234, 988) == 2222);

}

}

interface Adder {

int add(int a, int b);

}

class AdderImpl implements Adder {

int add(int a, int b) {

return a + b;

}

}

UNIT TESTING

• 5 scuze pentru a nu scrie unit testu-uri

• 1) nu am timp sa scriu unit testuri

• 2) clientul ma plateste sa scriu cod nu sa scriu unit testuri

• 3) intretin o aplicatie veche care nu are unit test-uri

• 4) testarea manuala este mult mai eficienta in descoperirea

defectelor

• 5) nu stiu cum sa scriu unit test-uri sau nu stiu cum sa scriu unit-

testuri bune

UNIT TESTING

• Frameworks

• .NET: NUnit, MBUnit, VS Unit Testing, xUnit

• Java: JUnit

• PHP: PHPUnit

• ActionScript: AS Unit

INTREBARI

RASPUNSURI

PAUZA

TEST

DRIVEN

DEVELOPMENT

TDD

• Ce este?

• Nu este vorba de a scrie teste

• Este o strategie de design

• Cod cu un design mai bun

• Mai multa incredere in cod

• Schimbari mai usor de facut

• Cod care raspunde mai bine la cerintele clientului

• Si… o suita completa de teste automate

• A aparut la sfarsitul anilor 90

• Kent Beck, Martin Fowler, etc

TDD

• Kent Beck: “Never write a single line of code without having a

failing automated test. Eliminate duplication.”

• Make it fail

Test

• Make it work

Code • Make it better

Refactor

TDD

• Pas 1: Test

• Design-ul codului din exterior

• Cum va fi folosit codul?

• O interfata “curata”

• Implementarea doar a functionalitatilor necesare

• Ofera un exemplu despre cum te astepti sa fie folosit codul tau

TDD

• Pas 2: Code

• Scrie cod cat sa treaca testul/testele

• Solutia poate sa nu fie optima

TDD

• Pas 3: refactor

• Design in modelul evolutiv

• Cod “curat”

• Se elimina duplicatele si se repara probleme de design

• Restructurarea codului existent (fara functionalitati noi)

• Toate testele trebuie sa treaca

TDD

• “Silver bullet” – nu e raspunsul la toate problemele

• TDD nu inlocuieste design-ul high level

• TDD se refera la exprima intentia codului pe care il scrii

• Este o practica de design

• Te forteaza sa scrii cod asa cum ai vrea sa il scrie altii (din

echipa) pentru tine

TDD

• La inceput viteza scade cu 20-30%

• Programatori cu experienta (in TDD) nu au o viteza sensibil mai mica decat cei care nu fac TDD

• Dar codul are o calitate mult mai buna (mai putine defecte)

• “I can finish much faster if it doesn’t have to work”

• Testele nu trec de cate ori schimb codul

• Valideaza comportamentul si nu implementare

• Maintenance

• Codul de test nu este “second hand”

• Refactoring pentru a il pastra “curat”

TDD

• Inca e nevoie de testeri

• Inca poti face greseli

• Dar sunt mai usor de izolat si de fixat

• Daca ai gasit un bug adauga un nou test pentru a il reproduce si

apoi repara

CONTINUOUS

INTEGRATION

CONTINUOUS INTEGRATION

• SDLC a evoluat in timp si echipele au realizat importanta unui

build regulat. A inceput cu un build saptamanal, apoi unul in

fiecare noapte, si acum avem build continuu

• Recomandat de practicat impreuna cu TDD

• Este un proces de generare a unui build ori de cate ori un

programator face check-in la cod in sistemul de source control

• Destinat (in special dar nu numai) organizatiilor care au nevoie de

un sistem de build repetabil si de incredere

• Este recomandata utilizarea unui server de build separat

CONTINUOUS INTEGRATION

• Termenul "continuous integration" se refera la un proces de build

si de testare a codului frecventa

• A fost creat de Martin Fowler si Kent Beck la sfarsitul anilor 90

• Un server dedicat monitorizeaza constant sistemul de source

control si ori de cate ori apar schimbari se initiaza un nou build

• Procesul implica compilare, si diverse teste si metode automate

de analiza a codului

• Daca procesul intampina erori va fi notificat un responsabil (build

master) sau cel care a invalidat codul

CONTINUOUS INTEGRATION

• Procesul poate fi sumarizat astfel:

• Un membru al echipei face check-in in source control

• Serverul de build monitorizeaza constant SCMS

• Codul este “checked-out” (de server)

• Proiectul este compilat si testat si problemele sunt raportate in timp

real

• Automatizarea acestui proces implica formalizarea unor

proceduri

• Programatorii sunt fortati sa faca “check-in” des

• Utilizarea responsabila a SCMS

CONTINUOUS INTEGRATION

• Ant / NAnt

• Cruise Control - .NET

• Continuum (Apache) - Java

• Hudson - Java

• MS Team Foundation Server

• Componente:

• Core – monitorizare continua a SCMS

• UI control: Web, RSS, XML, command line, email, etc

• Extensibilitate cu scripturi (ex FTP)

• Prin plug-inuri pot fi extinse pentru alte limbaje: C#, Python,

Maven, Ruby

CI

BUILD CONTROLLER

AUTOMATED TESTING

RETENTION POLICY

BUILD QUEUE

BUILD RESURS (INC TESTS)

LA CE AJUTA?

INVITAT SAPTAMANA VIITOARE

• Elvis Ciocoiu, Manager, Red Point

(de data asta chiar vine)

VA

MULTUMESC!