Dlaczego testujemy oprogramowanie? | Blog | Solwit

UDOSTĘPNIJ

Dlaczego testujemy oprogramowanie?

Autor: Michał Zaczyński (Manager ds. Testów, Solwit SA)

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.

testowanie-oprogramowania

Po co testujemy? 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. Jednak oni nie testują 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:

  • program będzie działał, dopóki nie wpisze się zbyt długiej nazwy pliku do zapisu; do momentu kiedy PC ma te same parametry co maszyna deweloperska; do chwili jego zminimalizowania,
  • sygnalizacja zadziała, póki nie pojawi się zanik napięcia i będzie musiała uruchomić się jeszcze raz – od jakiegoś momentu – do momentu, aż nie przepali się żarówka; do chwili, w której ktoś naciśnie przycisk na żądanie i to dwa razy itp.
  • winda ruszy, póki kogoś nie przytrzasną drzwi; póki nie wejdą dwie osobą chcące pojechać w przeciwnych kierunkach itp.

 

Wydaje się, że to bardzo oczywiste scenariusze, ale praktyka pokazała, że 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 właśnie jednym z celów testowania jest, 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. Celem testowania jest więc 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ł:

dlaczego-testujemy

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 na prawdę jest to co chcemy wydać na świat?”.

 

Przyjrzyjmy się kultowemu już rysunkowi z huśtawką:

dlaczego-testujemy2

Gdzie tak na prawdę leży problem w tym przykładzie?

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 celem testowania jest wyeliminowanie potencjalnych błędów projektowych, błędnych założeń czy interpretacji już na etapie samego projektowania, zanim powstanie pierwsze 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.

Podsumowując – ustaliliśmy, że testujemy między innymi, bo:

  • chcemy znaleźć defekty w pozytywnych, jak i negatywnych przypadkach użycia oprogramowania,
  • po to by program, który otrzymają klienci był przyjazny dla użytkownika i nie sprawiał mu trudności w obsłudze,
  • aby wykluczyć błędne założenia, które mogą nawet zablokować realizację projektu,
  • by wypełnić wymóg zewnętrznego regulatora, który od nas tego wymaga.

Oto jedne z ważniejszych celów testowania. 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 releasu (zarówno wśród testerów, jak i liderów zespołów testerskich) klient pyta nas: „czy ta wersja nadaję 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.

Sprawdź jak przyspieszyć pracę swojego zespołu testerskiego nawet 18-krotnie – czytaj więcej!