Szkoła testowania Context-Driven School w

(prostych) przykładach

Radosław Smilgin

O mnie

• Konsultant i trener

• Twórca i właściciel testerzy.pl (od 2006 roku)

• Wykładowca na Uniwersytecie Jagiellońskim i Vistuli

• Autor publikacji m.in. “Zawód tester”

• Mówca polskich i zagranicznych konferencji: TestWarez, Free Test,

CzechTest, etc., i lokalnych spotkań testerskich -> WarszawQA

• Twórca i organizator TestingCup – mistrzostw Polski w testowaniu

oprogramowania

• Testowania sterowanie kontekstem

– W przykładach

• Myślenie krytyczne

• Zarządzania zgodne z CDT

• Praca zespołu

• Kontekst projektu

• Automatyczne testowanie

• Miary i ich użycie

• Relacje z interesariuszami

Context-Driven School of testing

• Kiedy? 2001

• Kto? James Bach, Brian Marick, Bret Pettichord i Cem Kaner

• Dlaczego? 'The value of any practice depends on its context'.

• Szkoła… rozpadła się

Kontekst projektu

P1: Oprogramowanie samolotu– Regulacje FAA

– 20 lat działania

– Poprawne zachowanie rozumiane

jako aspekt techniczny i

matematyczny

P2: Edytor tekstu online– Postrzeganie zgodne z wizją

użytkowników MS Office

– Za 20 lat nikt już nie będzie o tym

pamiętał

– Krótki time-to-market

Praktyki użyte w P1 będą różne od tych w P2. Techniki użyte w P2 będą

nieskuteczne względem P1.

Zasady

1. Wartość dowolnej praktyki zależy od kontekstu.

2. Istnieją dobre praktyki w danym kontekście, ale nie ma najlepszych

praktyk (best practices).

3. Ludzie pracujący wspólnie stanowią najważniejszą część każdego

kontekstu projektowego.

4. Projekty zmieniają się w czasie, ale często w nieprzewidywalny

sposób.

5. Produkt jest rozwiązaniem. Jeśli problem nie jest rozwiązany, to produkt

nie działa.

6. Dobre testowanie oprogramowania jest wyzwaniem intelektualnym.

7. Tylko poprzez właściwy osąd i umiejętności, wykonywane wspólnie w

całym projekcie, jesteśmy w stanie robić właściwe rzeczy we właściwym

czasie tak, by skutecznie przetestować nasze produkty.

Context-Driven – Cem Kaner (1/2)

Tester sterowany kontekstem wybiera cele, techniki i dostawy (w tym

dokumentację) patrząc najpierw na szczegóły konkretnej sytuacji,

włączając w to pragnienia interesariuszy, którzy zlecili testowanie.

– Przykład: klient ma zawsze rację?

Istotą testowanie sterowanego kontekstem jest właściwy dla danego

projektu dobór umiejętności i osądów. Context-Driven School lokuje

to podejście do testowania w strukturze humanistycznej, społecznej i

etycznej.

Context-Driven – Cem Kaner (2/2)

Ostatecznie, testowanie sterowane kontekstem jest działaniem w

sposób najlepszy jaki potrafimy z uwzględnieniem tego co mamy.

– Przykład: korzystamy z wyroczni jakie mamy (nawet jeśli nie są doskonałe)

Zamiast próbować wdrażać „najlepsze praktyki”, akceptujemy, że

bardzo różne praktyki (nawet różne definicje popularnych pojęć

testerskich) będą działały najlepiej w różnych okolicznościach.

– Przykład: klient mówi „błąd” myśląc „defekt”

Context-Driven - Jamesa Bacha

Context-Driven - myślenie krytyczne

• „Krytyczne myślenie jest wprawną i aktywną interpretacją i

ewaluacją tego, co obserwujemy, komunikatów, informacji i

argumentów.” - Michael Scriven

Context-Driven a ISTQB

• ISTQB nie dostrzega CDT • CDT zwalcza ISTQB i standardy

Context-Driven a Agile

Agile ELEMENT Context - Driven

rekomendowane(Przykład: dużo)

PRAKTYKI / REGUŁY(Przykład: testy jednostkowe)

zależne od kontekstu

tyle ile potrzeba DOKUMENTACJA tyle ile potrzeba

rekomendowany MODELtester działa w zastanych

ramach

Zasady CDT w (prostych) przykładach

Zasady CDT w (prostych) przykładach

• Testerzy nie kierują projektem, pomagają projektowi

Defekt czy sugestia?Priorytet czy pilność?

Zasady CDT w (prostych) przykładach

• Testowanie realizuje się w imieniu interesariuszy. Różne strategie

mogą być stosowane dla różnych celów jakie mają interesariusze.

– Przykład: dlaczego „losowo” zmieniają się ceny biletów przy zakupie?

Zasady CDT w (prostych) przykładach

• Praktyki różnych grup testerskich mogą być różne. Mogą nawet

uchodzić za niepotrzebne i nieproduktywne.

– Przykład: użyteczność kontra funkcjonalność

Zasady CDT w (prostych) przykładach

• Wartość każdego przypadku testowego to jego zdolność do

dostarczenia informacji.

Zasady CDT w (prostych) przykładach

• Wyrocznie są omylne. Nawet jeśli produkt przeszedł test to

mógł go oblać w obszarze, w którym go nie monitorowałeś.

Zasady CDT w (prostych) przykładach

• Różne rodzaje defektów zostaną wykryte przez różne testy. Testy powinny

być coraz bardziej wymagające kiedy produkt się stabilizuje.

– Przykład: przejdź proces kontra sprawdź walidację pola

Zasady CDT w (prostych) przykładach

• Standardy dają nam sugestie do implementacji działań, ale

działania są sterowane przez wymagania klienta, praktyczne

ramy i szanse w projekcie.

Zasady CDT w (prostych) przykładach

• Artefakty testowe są przydatne jeśli spełniają oczekiwania

interesariuszy.

– Przykład: przypadki testowe kontra sesje eksploracyjne

W poszukiwaniu kontekstu…

Podsumowanie

• Context-Driven jest podejściem, a nie techniką. Czym więcej

technik znamy tym więcej opcji posiadamy.

• Context-Driven stawia na kontrowersje, ale nie na polaryzacje.

• Do Context-Driven trzeba „dorosnąć”

• Context-Driven jest naturalnym wyborem każdego testera.

• context-driven-testing.com

Dziękuję za uwagę!

Pytania?

Odpowiedzi…