Testy eksploracyjne wyjaśnione??

James Bach w swoim artykule "Exploratory testing explained" stara się wytłumaczyć czym dokładnie są testy eksploracyjne. I rzeczywiście o ile z punktu widzenia testera wydaje się to bardzo interesującą ideą o tyle z punktu praktycznego narodziło mi się kilka wątpliwości:

Pytanie #1

W opisie karty testów eksploracyjnych (ang. testing charter) Bach zakłada istnienie podręcznika użytkownika.

---

O ile spotykałem wiele projektów - o wiele więcej niż to zwykło się narzekać w literaturze - z całkiem przyzwoitą dokumentacją o tyle nie spotkałem jeszcze projektu, który wyprodukowałby podręcznik użytkownika przed wyprodukowaniem samego systemu. Powoływanie się na podręcznik użytkownika, w zbudza moją wielką wątpliwość. Ale to nawet nie jest istotne... tak czy siak ET potrzebuje jakiejkolwiek dokumentacji aby móc przygotować sobie tą kartę testów. Oczywiście w tej chwili można dyskutować na temat użyteczności takiej karty. Według mnie im skromniejsze rozmiary - w sensie merytorycznym - tym silniejsze będą następujące problemy:

1. trudności z zatrudnianiem studentów
2. trudności z zatrudnianiem zewnętrznych konsultantów
3. trudności z raportowaniem
4. brak wymienności wykonawców testów

AD1: W dużych firmach często stosuje się metodę zatrudniania studentów do prostych prac. Np. do wykonywania testów. Ta czynność przestaje być opłacalna gdyż przy pomocy karty testów, testy wykonać może tylko doświadczony tester znający zagadnienia z dziedziny testowania.
AD2: Ten problem nie jest znaczny - zakładając ze zatrudniamy profesjonalistów - ale zawsze należy doliczyć czas potrzebny na tzw. "rozruch" względem karty.
AD3: Bardzo często w dużych firmach wykonanie czegoś równa się dostarczenie raportu z wykonania tego czegoś. Tak samo jest z testami... bardzo często raport z testów stanowi integralną cześć dokumentacji projektowej przedstawianej kierownikowi projektu, zarządowi czy klientom. Bardzo często od tego dokumentu uzależnione są dalsze kroki w projekcie.
AD4: Ten punkt łączy się z pierwszym. W razie rotacji w zespole ucieka także cała wiedza i nic nie pozostaje na miejscu oprócz karty testów i raportów z defektów.

Pytanie #2

Wydaje się, że znaczna część karty testów może powstać na podstawie dokumentacji (nawet jeśli sama karta jest skromnych rozmiarów).

---

To jest coś co jest napisane między wierszami ale zdziwiło mnie powoływanie się na chociażby wyżej wymieniony podręcznik użytkownika.

Pytanie #3

Testowanie obsługi błędów - skąd wiadomo, kiedy i jakie te błędy mają się pojawić. Mocno związane z zagadnieniem weryfikowalności poprawności wyników.

---

Obiekcja, która rodzi się tutaj jest związana z weryfikowalnością wyników, np. skąd wiemy, że wygenerowaliśmy wszystkie scenariusze obsługi błedów? Dodatkowo skąd wiemy, że akurat ten a nie inny komunikat powinien się pojawić w danym miejscu?

Pytanie #4

"In freestyle exploratory testing, the only official result that comes from a session of ET is a set of bug reports."
Można to przetłumaczyć jako "W swobodnym stylu testów eksploracyjnych, jedynym oficjalnym rezultatem testów jest zbiór raportów defektów"

---

Idea całkiem słuszna. Jednak z praktycznego punktu widzenia mało realizowalna. W dużych firmach istnieje silny nacisk na udokumentowywanie i powtarzalność wykonywanych testów. Jest to pośrednio związane z rotacją kadry ale przede wszystkim z faktem, że firmy świadczą usługi na rzecz innych firm - swoich klientów. Bardzo często klienci zainteresowani są sposobem w jaki dana funkcjonalność zostąła przetestowana. Co więcej bardzo często procedura testów akceptacyjnych przygotowywana przez dostawcę jest częścią produktu przekazywanego klientowi i wchodząca w zakres testów akceptacyjnych wykonywanych przez klienta przy odbiorze produktu.
Tak więc w mojej opinii praktyczne zastosowanie tej zasady jest możliwe przy małych projektach lub przy projektach wewnętrznych gdzie odbiorcą jest rynek a firma jest pewna swoich procesów stymulowania jakości.

Pytanie #5

Tester uprawiający testy eksploracyjne jest zawsze i przede wszystkim projektantem testów. Kazdy może przypadkowo zaprojektować test, jednak profesjonalny tester eksploacyjny jest w stanie zmajstrować testy systematycznie eksplorujące produkt. Wymaga to takich umiejętności jak, zdolność analizowania produktu, szacowanie ryzyka, wykorzystanie narzędzi oraz przede wszystkim krytycznego myślenia"
[oryg.] "An exploratory tester is first and foremost a test designer. Anyone can design a test accidentally, the excellent exploratory tester is able to craft tests that systematically explore the product. That requires skills such as the ability to analyze a product, evaluate risk, use tools, and think critically, among others."

---

Nic dodać, nic ująć... w pełni zgadzam się z tym twierdzeniem! To czego nie rozumiem, to dlaczego jest ono adresowane tylko do testerów uprawiających testy eksploracyjne. Dokładnie takie same przymioty potrzebne są testerom uprawiającym inne metodyki. Zaprojektowanie przypadku testowego wymaga wiedzy o produkcie. Wymaga takrze umiejętności oszacowania w którym miejscu można znaleźć defekty szczególnie groźne dla produktu. Następnie trzeba posiadać wiedzę na temat narzędzi z jakich można skorzystać w trakcie projektowania i/lub wykonywania tego przypadku testowego. A to wszystko jest możliwe kiedy jesteśmy krytycznie nastawieni od testowanego systemu ale potrafimy odrzucić te sugestie krytycyzmu, które nie wnoszą do jakości produktu nieczego oprócz naszej satysfakcji ze znalezienia buga.
Formalne zapisanie przypadku testowego to tylko opcja. I dlatego nie zgodzę sie, że takie ujęcie dotyczy tylko testerów od ET.

Pytanie #6

W praktyce, konkretny tester jest często permanentnie przypisany od jednego zbioru komponentów, aby projekt korzystał z regularnej krzywej uczenia [oryg.] "In practice, a particular tester is often permanently assigned to one set of components, so that the project benefits from an uninterrupted learning curve"

---

Biorąc pod uwagę słowa "permanentnie" i "często" trudno się tutaj ustosunkować bardzo zasadniczo. Ale uważam, że niezbędne jest tutaj słowo komentarza. Po pierwsze chyba każdy - nawet nie bardzo doświadczony manager testów - zdaje sobie sprawę, że komponent testowany w kółko przez tą samą osobą jest narażony na mutację syndromu pestycydów. Wynika to ze zwykłego znudzenia. Jeśli nie bierze tego pod uwagę to ma problemy i to duże bo będzie to rzutowało na morale całego zespołu. Znudzenie bardzo szybo się rozprzestrzenia.
Drugim aspektem tego zagadnienia jest to, że tworzenie unikalnych specjalistów nie jest dobrym sposobem na budowanie zespołu. Wiedza w takim zespole przyrasta znacznie wolniej.

Pytanie #7

[...] regularne spotkania z testerami w celu omówienia postępów, przynajmniej raz w tygodniu [oryg/] "regular meetings with testers to discuss test progress, at least once per week."

---

Bardzo szlachetna idea i na pewno daje doskonałe wyniki w środowisku jednego dużego projektu. Natomiast jest to kompletna klapa w środowisku wieloprojektowym gdzie kierownik projektu prowadzi na raz kilka projektów, a w strukturze projektu istnieje kilka grup (np. integracja, migracja, testy, logika biznesowa, GUI, itp). W takim przypadku nie jest to możliwe. Natomiast tutaj doskonale sprawdzają się raporty omawiające status, wcześniej uzgodnione z kierownikiem projektu.

Pytanie #8

Tester jako samotny lider

---

Nie wiem skąd to się wzięło ale jest to pomyłka i to straszna. Każdy tester działa w środowisku biznesowym i jego "meta-kontekstem" to właśnie środowisko. Ale jednocześnie, aby móc wykonywać swoje zadania sumiennie, nie bada pulsu tego środowiska. Robi to za niego jego kierownik, kierownik projektu, itd. A więc w sytuacji, w której środowisko biznesowe ulegnie zmianie, należy natychmiast zmienić kierunek testowania bez względu na to jak słuszna jest idea testów prowadzonych w chwili obecnej.