Redakcja
Podczas majowej WarszawQA miałem przyjemność prezentować temat "Co tester może osiągnąć w 60 minut?".
Zwiastun prezentacji opisywał ją tak: "Testowanie jest nieskończone, a czasu nigdy nie ma wystarczająco dużo. Tester pracuje 8h dziennie, podstawowa sesja eksploracyjna trwa 30 minut, a podczas rozmowy kwalifikacyjnej masz 2 minuty aby zrobić dobre, pierwsze wrażenie. A Ty, ile czasu potrzebujesz aby osiągnąć wartościowy rezultat?
W 60 minut można osiągnąć bardzo wiele, oczywiście jeśli rozsądnie definiujemy cele z uwzględnieniem dostępnych zasobów. Celem tej sesji jest przekazanie jak adaptować się do ograniczeń czasowych, niepełnej wiedzy i rozpraszającego środowiska przy użyciu zasad testowania sterowanego kontekstem i metody testowania eksploracyjnego.". Podczas przygotowania do prezentacji postanowiłem rozszerzyć ją o dodatkowe zadanie dla publiczności. Poprosiłem uczestników o próbę aplikowania reguł, które omawiałem do testowania prawdziwej aplikacji.
Zachętą do poruszenia takiego tematu były dwa czynniki:
1. Niebywale duże zainteresowanie filmikiem z naszego kanał YouTube: "Bugster - 60 minut testowania. Testujemy funduszeeuropejskie.gov.pl"
2. Niesłabnące zainteresowanie i wdrażanie coraz to nowych metod z obszaru testowania sterowanego kontekstem oraz testowania eksploracyjnego.
W mojej opinii 60 minut to bardzo dużo czasu na uzyskanie pewnej wartości dla klienta. Czas ten jednak nie może być poświęcony na pisanie przypadków testowych. Przede wszystkim musimy pamiętać, że naszym ograniczeniem jest czas, którego nie wolno nam przekroczyć - stąd koncept timebox. Czas ten musi być dobrze zaplanowany w sposób uniwersalny. Przykładowo można go planować zgodnie z regułą 20 / 60 / 20. Definiuje się ją jako: nie więcej niż 20% czasu poświęcamy na konfigurację środowiska i przygotowania do testowania, nie mniej niż 60% czasu poświęcamy na samo testowanie i weryfikowanie jakości oprogramownia i nie więcej niż 20% czasu poświęcamy na podsumowanie i raportowanie sesji testowej. Te dość restrykcyjne zasady nie tylko pomagają w strukturyzowaniu testów, ale również służą jako miary podsumowujące przeprowadzenie testów.
Reguł oczywiście jest więcej, ale ich dobór jest dość dowolny. Testowanie eksploracyjne jak i sterowane kontekstem to nie są sztywne metodyki, tak więc reguły można adaptować, należy jednak trzymać się kluczowych zasad CDT. Zasady te wymuszają od testera przyjęcie perspektywy biznesu oraz nieprzywiązywanie się do praktyk. Skuteczność praktyk zależy bowiem od kontekstu projektu i produktu. Nie istnieje coś takiego jak najlepsza praktyka.
To co jest najbardziej pociągającego w podejściu proponowanym przez Cema Kanera czy Jamesa Bacha to założenie, że testowanie jest procesem intelektualnym, wymagającym czegoś więcej niż tylko ślepego klikania. Jest to opracowanie strategii i wymagająca skupienia interakcja z maszyną.
Każdy element w CDT i ET ma znaczenia, ale najważniejszym jest to jak podsumujemy naszą pracę czyli raportowanie. Końcowy raport musi być dopasowany do odbiorcy i dostarczać mu tę informację jaką w danym momencie potrzebuje. Aby dobrze zrozumieć co jest wymagane możemy o to zapytać, możemy również jednak sami wypracować raport, który będzie optymalny dla naszych klientów / odbiorców.
Poniżej slajdy z prezentacji.
