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 MODEL
tester 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…

Context Driven School of testing w prostych przykładach

  • 1.
    Szkoła testowania Context-DrivenSchool w (prostych) przykładach Radosław Smilgin
  • 2.
    O mnie • Konsultanti 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
  • 3.
    • Testowania sterowaniekontekstem – 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
  • 4.
    Context-Driven School oftesting • 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ę
  • 5.
    Kontekst projektu P1: Oprogramowaniesamolotu – 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.
  • 6.
    Zasady 1. Wartość dowolnejpraktyki 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.
  • 7.
    Context-Driven – CemKaner (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.
  • 8.
    Context-Driven – CemKaner (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”
  • 9.
  • 10.
    Context-Driven - myśleniekrytyczne • „Krytyczne myślenie jest wprawną i aktywną interpretacją i ewaluacją tego, co obserwujemy, komunikatów, informacji i argumentów.” - Michael Scriven
  • 11.
    Context-Driven a ISTQB •ISTQB nie dostrzega CDT • CDT zwalcza ISTQB i standardy
  • 12.
    Context-Driven a Agile AgileELEMENT 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 MODEL tester działa w zastanych ramach
  • 13.
    Zasady CDT w(prostych) przykładach
  • 14.
    Zasady CDT w(prostych) przykładach • Testerzy nie kierują projektem, pomagają projektowi Defekt czy sugestia? Priorytet czy pilność?
  • 15.
    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?
  • 16.
    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ść
  • 17.
    Zasady CDT w(prostych) przykładach • Wartość każdego przypadku testowego to jego zdolność do dostarczenia informacji.
  • 18.
    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ś.
  • 19.
    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
  • 20.
    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.
  • 21.
    Zasady CDT w(prostych) przykładach • Artefakty testowe są przydatne jeśli spełniają oczekiwania interesariuszy. – Przykład: przypadki testowe kontra sesje eksploracyjne
  • 22.
  • 23.
    Podsumowanie • Context-Driven jestpodejś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
  • 24.