1. Tester jako strażnik jakości
oprogramowania

2. O nas
Magda Traciłowska
2013-08-22
Bogna Majchrzak
2

3. Na początku był chaos...
2013-08-22
3

4. Model kaskadowy i jego wady
Określenie
wymagań
Analiza
I projektowanie
Implementacja
Testowanie
Utrzymanie
I zmiany
2013-08-22
4

5. Model V i jego wady
Określenie
wymagań
Testy
Tworzenie
Analiza
I projektowanie
przypadków
testowych
Implementacja
2013-08-22
5

6. A może jednak można
z tą jakością
nieco lepiej...
SCRUM!
2013-08-22
6

7. Troszkę terminologii
Ø
Ø
Ø
Ø
Ø
Ø
Ø
Ø
Product Backlog
Story
Sprint
Grooming
Planning
Daily Scrum
Sprint Review (Demo)
Sprint Retrospective (Retro)
2013-08-22
7

8. Zespół scrumowy
•
Product Owner (PO)
•
Zespół Developerski
•
Scrum Master
2013-08-22
8

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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

16. SCRUM vs WATERFALL
Przejrzystość 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

17. 2013-08-22
17