Testowanie

, blados

Na fali ostatnich wydarzeń związanych z #pkw #wybory2014 #nabino #facepalm #ajawiemcosiepopsulo postanowiłem ujawnić nieco jak testuje się oprogramowanie. Na początku jest słowo od klienta. Chciałbym coś. Jeszcze nie wiem dokładnie dlaczego ani jak ma to wyglądać, ale na pewno to chcę. Ta potrzeba może wynikać z różnych przesłanek:

Teoretycznie klient ma zawsze rację a nawet jeśli nie ma to patrz punkt pierwszy. Uwierz, w większości przypadków klient się myli i Twoim zadaniem jest wyprowadzić go z marazmu i otępienia na prostą drogę. Zweryfikuj co i dlaczego chce. Niech Ci opowie jak krowie na rowie, niech rysuje obrazki, niech tłumaczy jak przedszkolakowi. Całkiem możliwe, że w trakcie tego procesu nagle on uświadomi sobie niemądrość swego pomysłu. Równie prawdopodobne, że to Ty niespodziewanie docenisz przebłysk geniuszu klienta i odkryjesz co tak naprawdę ma na myśli.

Różne wizje tego samego projektu

Jeśli już jesteście na tej samej stronie (to be on the same page) - dokumentuj. Spisuj wszystkie aha momenty, żeby łatwo było to przekazać ziomalom z zespołu. Im prościej dokumentacja napisana, tym szybciej zrozumie ją osoba nieobecna w trakcie waszej sesji. Prosto nie znaczy po łebkach, prosto nie znaczy skrótowo. Pominięcie oczywistej oczywistości, którą przecież każdy zna na etapie dyskusji może nie będzie skutkowało natychmiastową katastrofą ale daje głowę, że za tydzień, miesiąc oczywista oczywistość nie będzie już taka... oczywista. Przykłady:

Bywało, że rano dzwonił VIP z propozycją nie do odrzucenia na zmianę w systemie używanym w 400 sklepach w kraju. Zmiana musi się pojawić do 12 tego samego dnia. Co robisz? Krótka piłka do developerów, którzy rzucą wszystko aby wypełnić tę misję, test najbardziej wrażliwych miejsc w systemie na proponowaną zmiany, testy regresywne w szczątkowym formacie i heja! Zdążyłeś, aktualizacja systemu tak jak planowano o 12. Cóż, że do końca dnia prawdziwi klienci testowali na sobie genialny pomysł VIPa. Nie obyło się bez czkawki ale plusy dodatnie przeważyły nad plusami ujemnymi. Klient był zadowolony a Ty sobie solennie przyrzekałeś, że to był ostatni raz...

Nie jestem ekspertem od testowania ale skoro już przy testach regresywnych jesteśmy... Jak przetestować produkt, którego liczba konfigurowalnych opcji wynosi 10^24?

Dobra, mamy dokumentację zmiany czy też nowego systemu albo potrzeby klienta. Rozmawiamy z zespołem, rozmawiamy z deweloperami. W trakcie tych konwersacji mogą paść słowa powszechnie uważane za niecenzuralne. Klient również mogłby się obrazić, gdyby tylko usłyszał niektóre przymiotniki, którymi został obdarzony, ale... Taka burza mózgów musi się zadziać. Wiesz, co jest przedmiotem bólu głowy klienta i jak chce to usunąć a teraz masz dodatkowe informacje od kolektywu zaprawionego w bojach. Niejedno widzieli, niejednego klienta przeżyli i niejedną walkę z wiatrakami wygrali. Kiedy już ich opinia jest Ci znana, w zależności od jej treści albo wracasz do klienta albo zaczynasz pracę - pora przełożyć założenia na język zrozumiały dla firmy. W idealnym świecie będzie ona zawierać rozdział opisowy, część dla developerów oraz wskazówki dla testerów. Sukces implementacji będzie w dużej mierze zależało od zawartości tego dokumentu. Do niego będziesz wracać, gdy klient będzie wyrażał niezadowolenie lub jakieś nowe wymagania. Do niego zaglądniesz w czasie testowania.

Jest pierwsza wersja napisana przez programistów w piwnicy. Wrzucamy na serwer, próbujemy się zalogować. Bez sukcesu. Ktoś coś zapomniał. Jest następna iteracja, logowanie działa, wszystko działa poza zmianą oczekiwaną jako efekt końcowy. Kolejny build. Zmiana działa ale nie tak. Następna aktualizacja i następna. Po pewnym czasie nie spodziewasz się, że tym razem wszystko zatita ale niespodziewana niespodzianka - działa wszystko! Hurra! Dzwonisz do klienta, że może zacząć swoje testy kiedy to on mówi, że w sumie wszystko fajnie ale chciałbym nanieść pewne poprawki. Kolejne słowa powszechnie uznawane za obraźliwe rzucane w bliżej określonym kierunku przez zespół. Analizujemy i mówimy OK albo no way!

Powyższe tylko pobieżnie dotyka testowania. Co zawiniło w przypadku wyborów? Wydaje mi się, że procedury. Przetarg na budowę mostu, organizacji szkolenia czy dostarczenia działającej aplikacji rządzi się takimi samymi prawami. Nie będę wdrażał się w szczegóły, które w różnych miejscach w sieci żyją swoim życiem. Co się stało już się nie odstanie i pytanie tylko, czy jakiekolwiek wnioski i zmiany w tychże procedurach zostaną wprowadzone, żeby uniknąć tego rodzaju sytuacji w przyszłości? Nie ma implementacji w 100% pozbawionej błędów, gdyż to ludzie ją przeprowadzają. Lecz gdy tylko kurz opadnie i wszystko działa jak należy, osoby związane z procesem na spokojnie powinny wypunktować wszystkie pozytywy i delty. Deltą będzie splot wydarzeń, który nie przyniósł oczekiwanego efektu i nie powinien zostać powtórzony w przyszłości.