O tym, jaka jest zależność między testowaniem i Twoim ulubionym odtwarzaczem muzyki oraz co tak naprawdę wnosi tester do projektu, opowiada Michał Zaczyński, jeden z najbardziej doświadczonych testerów w Solwicie.
Po co przeprowadzamy testowanie oprogramowania? To jedno z najczęściej zadawanych przez nas pytań na rozmowach rekrutacyjnych na stanowiska testerskie w Solwicie. Czy jest na nie jedna prawidłowa odpowiedź? Z całą pewnością nie. Jak więc powinien odpowiedzieć przyszły „junior” (i nie tylko) tester?
Podejdźmy do tematu „po testersku” i zacznijmy od drugiej strony… A co by było, gdybyśmy NIE testowali? Czy programy przestałyby działać? Czy sygnalizacja świetlna dawałaby błędne sygnały? Czy windy przestałyby rozwozić pasażerów po piętrach?
Moim zdaniem odpowiedź brzmi – nie. Większość deweloperów sprawdza, czy to, co napisali, działa. Testy oprogramowania nie obejmują całego zapisanego kodu, tylko sprawdzają jeden podstawowy przypadek i to wyłącznie poprawnego użycia konkretnego fragmentu tego kodu.
Z punktu widzenia użytkownika wymienionych wyżej przykładów, oznacza to, że:
Wydaje się, że to bardzo oczywiste scenariusze, ale praktyka pokazała, że są one bardzo często pomijane na etapie pisania kodu. Koncentrowanie się na realizacji zadania oraz niemożność spojrzenia na nie nieco z boku to naturalne i powszechne zjawisko. Dlatego proces testowania oprogramowania, obok sprawdzenia tych podstawowych i oczywistych ścieżek, ma na celu także zbadanie tych nietypowych obok sprawdzenia tych podstawowych i oczywistych ścieżek, zbadanie również tych nietypowych, które mają małą szansę, by się wydarzyć.
W przypadku, gdy oprogramowanie nie zachowa się w zamierzony sposób, efektem mogą być znaczne straty finansowe albo szkody na zdrowiu ludzi. Testowanie oprogramowania ma zatem na celu znalezienie defektów w zachowaniu oraz ich zgłoszenie.
Bardzo często od testera wymaga się czegoś więcej niż tylko „proste” szukanie defektów i potwierdzenie (nie)prawidłowości działania. Wyobraźmy sobie taką sytuację: deweloper miał napisać funkcjonalność regulacji dźwięku w skali 1 – 100 z opcją wyciszenia. No i napisał:
Niestety, może się okazać, że działa ona prawidłowo… Czy tester powinien zaakceptować takie rozwiązanie? Oczywiście, że nie, bo właśnie poprzez testowanie oraz swoje doświadczenie tester stwierdza, że to, co zostało stworzone (i nawet działa) nie powinno nigdy ujrzeć światła dziennego, bo jest niepraktyczne, trudne w użytkowaniu, a może po prostu brzydkie. Testowanie ma na celu wyłapanie tych wszystkich wątpliwości i głośne krzyknięcie: „stop, czy to naprawdę jest to co, chcemy wydać na świat?”.
Przyjrzyjmy się kultowemu już rysunkowi z huśtawką:
W komunikacji, w sposobie przekazywania informacji oraz w jej odbiorze. Bardzo często, opierając się na słowie mówionym czy pisanym, rozumiemy przekaz, mając w tle swoje doświadczenia. W takim przypadku testowanie oprogramowania ma na celu wyeliminowanie potencjalnych błędów projektowych, błędnych założeń czy interpretacji już na etapie samego projektowania, zanim powstanie pierwsza linia kodu. To właśnie dlatego tak ważne jest, aby tester (w miarę możliwości) uczestniczył we wszystkich etapach cyklu życia projektu. Bo właśnie przez swoje doświadczenie, czy też po prostu pewną niezależność, będzie potrafił już na samym początku stwierdzić, że pewne założenia powinny ulec zmianie.
Częstą odpowiedzią na pytanie: po co testujemy, jest „bo ktoś nam każe…”. Prawie zawsze ma to zastosowanie w układach związanych z bezpieczeństwem ludzi, gdzie przepisy krajowe, normy czy też certyfikacje wymagają od nas przeprowadzenia pewnej gamy testów.
W Solwicie przykładem takich projektów są projekty związane z branżą kolejową, medyczną oraz samochodową. Każda z tych branż ma ściśle określone procedury związane z testowaniem w powiązanych ze sobą normach.
Oto jedne z ważniejszych celów testowania oprogramowania. Ich wypełnienie prowadzi do wygenerowania pewnej ilości danych oraz statystyk na temat jakości produktu. W ten sposób docieramy do kolejnego (jeśli nie najważniejszego z punktu widzenia Produkt Menadżera) celu testowania, czyli przekazania informacji o stanie/jakości wytwarzanego oprogramowania osobom decyzyjnym w projekcie.
Bardzo często w Solwicie, szczególnie w momentach release’u (zarówno wśród testerów, jak i liderów zespołów testerskich) klient pyta nas: „czy ta wersja nadaje się produkcję?”. I to pytanie pada pomimo defektów opisanych w systemach i statystykach wszystkich możliwych wielkości. A to właśnie testowanie ma finalnie dać odpowiedź o jakości oprogramowania i umożliwić podjęcie decyzji PM’owi odnośnie dalszych kroków.
A kto lepiej zna program, jak nie tester, który spędził dziesiątki/setki godzin przeklikując się przez wszystkie jego opcje? To właśnie ta informacja o jakości oprogramowania – wyrażona w liczbach, w systemie, czy będąca po prostu subiektywnym odczuciem testera – jest moim zdaniem najważniejszym celem testowania, bo to od niej zależą dalsze kroki związane z testowanym oprogramowaniem.
