Jak patrzymy na testy czyli Jak punkt widzenia zależy od punktu siedzenia Click Piotr Kałuski to edit Master subtitle style
Punkty widzenia Zespół Testów Manager Projektu Użytkownik końcowy
Zespół Testów Co robi Przygotowuje scenariusze testowe Wykonuje scenariusze testowe Raportuje błędy Sprawdza czy błędy zostały naprawione... i czy po kolejnej zmiane nie popsuto czegoś co już wcześniej działało
Zespół Testów Z jakich narzędzi korzysta Metodologia Risk based testing Klasy równoważności Inne Narzędzia informatyczne System do zarządzania testami System do raportowania błędów Mnóstwo różnych malutkich narzędzi, które w różny sposób pomagają w konfiguracji środowiska i wykonaniu testów
Project Manager Musi wiedzieć jaki jest budżet, zapotrzebowanie na zasoby i jakie są terminy Może wiedzieć jakie są wymagania ale nie jest to niezbędne Metodologia testów raczej mało go obchodzi......za to bardzo go obchodzi metodologia zarządzania projektami. A w większości metodologii zarządzania projektami podstawowym rodzajem produktu jest dokument
Użytkownik końcowy Ma swoją wizję jak system powinien działać i uznaje, że działa, jeżeli działa end to end Nie interesuje go: Jakie są rodzaje testów Czym się różni black box od glass boxa... Ani inne tego rodzaju rzeczy Jeżeli system nie działa end to end to nie interesuje go także że poszczególne składowe infrastruktury IT w zasadzie działają
Przykład System do wstawiania buziek w tekst SMS-a.
Jak każdy widzi poszczególne fazy projektu Na początku projektu... Użytkownik Zgłasza potrzebę Chce wiedzieć na kiedy i za ile będzie to gotowe Project manager Chce jak najszybciej zdobyć informacje o harmonogramie i potrzebnych zasobach Te informacje przekaże potem użytkownikowi końcowemu i będzie za wiarygodność tych informacji odpowiedzialny Zespół Testerów Ma mgliste pojęcie o tym co system będzie robił a tym bardziej jak to będzie można przetestować i ile to
Jak każdy widzi poszczególne fazy projektu W miarę rozkręcanie się projektu Użytkownik będzie raz na jakiś czas pytał jak leci Project manager będzie cały czas próbował zdobyć informacje pozwalające mu w sposób mierzalny opisać stan projektu: Ile jeszcze będzie projekt trwał Ile jeszcze zużyje zasobów Ile jeszcze będzie kosztował Zespół testerów będzie zadręczany przez Project Managera pytaniami o harmonogram testów i ich pracochłonność. Będzie więc na bazie niepełnych informacji opracować dla Project Managera jakąś odpowiedź
Jak każdy widzi poszczególne fazy projektu Po fazie rozruchu Użytkownik będzie raz na jakiś czas pytał jak leci Project manager będzie walczył o mierzalne informacje w jakim stopniu jest realizowany założony plan ile zjadł budżetu, ile zostało wykonane Zespół testów w miarę otrzymywania coraz bardziej szczegółowych informacji, coraz lepiej będzie mógł określić ile będzie trwało testowanie i jakie będą na to potrzebne zasoby. Będzie też mógł zacząć przygotowywać scenariusze testowe, a jak Bóg da to może i coś przetestować
Jakie z tego wynikają różnice
Różnice Dla testerów plan testów jest (niezależnie od tego co przy tym mówią sami testerzy czy też mądre książki) pochodną ich pierwszego zrozumienia jak ma się zachowywać system. Zrozumienia, które często bazuje na dokumentacji projektowej, która niejednokrotnie jest ułomna. Ergo Jest naturalne, że w miarę
Różnice c.d. Dla Project Managera Plan testów jest zobowiązaniem, dokumentem na bazie którego podejmuje w imieniu projektu zobowiązania wobec stakeholderów Dla niego zmiana w test planie jest zmianą w kontrakcie jaki z nimi zawarł. W związku z powyższym będzie wrogo nastawiony do: Dodawania scenariuszy Usuwania scenariuszy
Różnice c.d. Zespół testerów oceniając postęp testów bierze pod uwagę procent wykonania planu i pokrycie funkcjonalności. Użytkownik oczekuje od systemu jakiegoś nowego zachowania. Nie wnika w szczegóły jak jest to realizowane. Jeżeli tego czegoś nie dostaje, to nie ma dla niego znaczenia, dlaczego tego nie dostał. Liczy się, że nie dostał. I informacja, że 99% testów zakończyło się sukcesem nie zmienia faktu, że nie ma produktu jaki było mu potrzebny
Co jest ważne Dla użytkownika Liczy się funkcjonalność na poziomie biznesowym Dla testera Testowane zagadnienie składa się z szeregu podzagadnień, niejednokrotnie technicznych, których wzajemne powiązania są skomplikowane Dla project managera Testowanie jest elementem większej układanki która konsumuje czas i zasoby a rolą managera jest pilnować trzymania się w ograniczeniach narzuconych przez powyższe.
Co robić żeby było lepiej Wszystkie strony powinny mieć świadomość potrzeb pozostałych uczetników projektu oraz rozumieć uzasadnienie tych potrzeb Project manager Musi wiedzieć, że harmonogramy które dostaje na początku projektu od testerów w 80% nijak się mają do rzeczywistości Musi też zrozumieć, dlaczego testerzy chcą zmieniać plan testów w trakcie ich trwania Testerzy Muszą wiedzieć, że pomimo, iż harmonogram testów jest robiony z dokładnością +-1000% to stanowią ona dla Project Managera pewną wartość. A przede wszystkim on tego po prostu potrzebuje.
A co z biednym użytkownikiem końcowym? Musi wierzyć, że zmiany harmonogramów i budżetu (zawsze wzrosty) nie są wynikiem złej woli IT, tylko ot tak, jakoś to tak wychodzi. My (ludzie IT) ciągle mało rozumiemy co się tak naprawdę dzieje w projektach IT i gdzie się ten cały czas i pieniądze rozpływają. Poza tym, każdy projekt jest inny. Nawet jeżeli jest to wdrożenie tego samego oprogramowani.
Przykład Automatyzacja testów Dla każdego projektu wydatki na automatyzacje testów są za duże Użytkownik końcowy bardzo nieufnie podejdzie do wydatków na to, co nie przyniesie mu wymiernych korszyści biznesowych...dzięki powyższemu testy nie zostają zautomatyzowane.
Aby testowanie sprawniej i efektywniej......biznes musi uwierzyć IT, że pewne wydatki, które nie przyniosą bezpośredniej korzyści, na dłuższą metę, przyniosą oszczędności IT musi zrozumieć, że dla Biznesu są działem, który chce coraz więcej pieniędzy a dotrzymuje coraz mniej obietnic.
Pytania?