Tester jako strażnik jakości oprogramowania

O nasMagda Traciłowska Bogna Majchrzak

2013-08-22 2

Na początku był chaos...

2013-08-22 3

Model kaskadowy i jego wady

AnalizaI projektowanie

Określeniewymagań

Implementacja

Testowanie

UtrzymanieI zmiany

2013-08-22 4

Model V i jego wady

AnalizaI projektowanie

Określeniewymagań

Implementacja

Tworzenie przypadków testowych

Testy

2013-08-22 5

A może jednak można z tą jakością nieco lepiej...

SCRUM!

2013-08-22 6

Troszkę terminologiiØ Product BacklogØ StoryØ SprintØ GroomingØ PlanningØ Daily ScrumØ Sprint Review (Demo)Ø Sprint Retrospective (Retro)

2013-08-22 7

Zespół scrumowy

• Product Owner (PO)

• Zespół Developerski

• Scrum Master

2013-08-22 8

Role testera• Grooming

Ø wymaganiaØ estymaty czasowe

• StoryØ User story (US)Ø Kryteria akceptacji (KA)Ø How to test (HTT)Ø TODOØ Testy automatyczne (TA)

2013-08-22 9

Role testera• Sprint

Ø testy automatyczneØ kryteria akceptacjiØ dane testoweØ przypadki testoweØ testy testy testy…Ø feedback dot. BłędówØ retesty

• Znajomość produktu

2013-08-22 10

Tester to nie klikacz!

●Świadomość działania programu od strony technicznej;●SQL (i bazy danych);●Cudowne narzędzie - Firebug;●Umiejętność programowania;●Systemy kontroli wersji;

2013-08-22 11

BDD – to jest to!Czytelny dla nie technicznego biznesu. Development testu w tym samym czacie co development aplikacji!

Scenario: I log in

Given I am on "/enter_login.php" And there is a "regular" user named "Adam the User" with parameters: | password | test1234 |When I fill in "user login" with login of user named "Adam the User" And I fill in "user password" with "test1234" And I press "submit button"Then I should be on "/" And I should be authenticated as user named "Adam the User"

2013-08-22 12

DOD na straży jakości

●DOD to checklista działań które należy wykonać w trakcie

tworzenia i developmentu „historyjki”●DOD to zasady które kontrolują jakość wytwarzanego oprogramowania;●DOD pozwala na zapobieganie powstawania błędów;●Nie spełnienie DOD=nie skończona historyjka

2013-08-22 13

Przykładowe DOD user story:●spełnia kryteria akceptacji;●została zaakceptowana przez UX (chyba że nie;)●zostało zrobione COD REWIEV;●spełnia standardy kodowania●Powstał test automatyczny – jeśli był wymagany;●została przetestowana i przechodzą testy behatowe;●Ma procedurę wdrożenia●Została zaakceptowana przez PO;

2013-08-22 14

Projekt „Parametr Stan” (Nowy/Używany)

Short time deliveryØ nowy parametr stanuØ formularz sprzedaży – wymagana wartość parametruØ 1 parametr – przemapowanie starych parametrówØ listingi – zakładki „Wszystkie/Nowy/Używany”Ø narzędzia dla SprzedającychØ webAPI

2013-08-22 15

SCRUM vs WATERFALLPrzejrzystość przez cały czas dzięki częstym inspekcjom

Przejrzystość na początku i na końcu projektu

Możliwość wprowadzenia zmiany w każdym momencie – mały koszt

Możliwość wprowadzenia zmiany tylko podczas planowania. Koszty zmian duże w późniejszych fazach projektu.

Wartość dostarczana iteracyjne Wartość dostarczana dopiero na końcu projektu

Mały koszt poprawiania błędów Duży koszt poprawiania błędów

2013-08-22 16

2013-08-22 17