Dzisiejsze podejście do
testów nie ma przyszłości

Artykuły eksperckie | 20.09.2017 | Czas czytania: 4 minuty

Patrząc na motocykl Harley-Davidson, śmiało można stwierdzić, że pewne rzeczy nie muszą się zmieniać. Klasyczna dusza harleya z biegiem czasu tylko zyskuje. Świat jednak nie zważa na takie wyjątki i stale prze naprzód. Zwłaszcza z perspektywy branży IT. Żyjemy wśród ciągłej zmiany, a środowisko IT to prawdziwa dżungla, w której pojawiają się co rusz nowe technologie – jedne szybko znikają, inne przez pewien czas wyznaczają trendy. Z mojego punktu widzenia nasuwa się więc pytanie: w jaki sposób zachować jakość i testować w takich warunkach? IoT, Big Data, wyrafinowane systemy do zarządzania – to tak naprawdę szereg połączonych technologii, stanowiących jeden produkt, przez co wymykają się klasycznemu podejściu do testowania. Niestety – żeby przetrwać w dżungli IT, trzeba dołączyć do biegu.

Więc oto mamy rzeczywistość, w której wciąż pojawiają się nowe technologie, trendy, a oprogramowanie staje się coraz bardziej skomplikowane. To już samo w sobie powoduje, że praca testera jest bardzo wymagająca. A jeżeli dodamy do tego jeszcze wszechobecne agilowe podejście, w którym tester tworzy produkt wraz z resztą zespołu, czyli musi posiadać jeszcze dosyć szerokie umiejętności programistyczne (a raczej chcemy by je posiadał), robi się naprawdę ciężko.

Nie oszukujmy się przy tym – rola testerów oprogramowania jest wciąż podważana. Pomimo starań budowania świadomości dotyczącej istoty przeprowadzania testów, wciąż zdarzają się firmy, które najchętniej uniknęłyby kosztów z nimi związanych. Niektórym osobom może się to wydawać „prehistorycznym" podejściem, jednak nadal spotkać się można z opiniami typu:

  • testy nie przynoszą wymiernych korzyści,
  • testy powodują, że programiści staja się leniwi,
  • po co testy, skoro deweloper powinien programować wszystko tak, jak należy?

Jest to oczywiście podejście dość krótkowzroczne i tak naprawdę da się te argumenty sprowadzić do dwóch aspektów, mianowicie do pieniędzy i chęci ograniczenia kosztów. Dodatkowo niestety zdarza się, że sam proces testowania skonstruowany jest tak, że rzeczywiście nie dostarcza wystarczającej wartości dodanej do projektu. I niekoniecznie musi to być wina samych testerów.

Testy – jak to wygląda w praktyce

Weźmy na celownik klasyczny projekt. Mamy pewne potrzeby względem wykonywania testów w danym projekcie, co więcej nie są one stałe, bardzo często mają różnorodny charakter i zmieniają się w czasie. Oczywiście już na początku projektu staramy się różne ewentualności przewidzieć i takimi informacjami odpowiednio zarządzać, jednak musimy zawsze zakładać, że prędzej czy później powstanie dług, wynikający z prostego rozejścia się możliwości w stosunku do wynikających potrzeb.

Przyjmijmy, że do naszego klasycznego projektu delegujemy dwie osoby. Co to oznacza? To, że mamy w nim dwóch testerów, którzy mają określoną ilość czasu, określoną wiedzę i doświadczenie. Nawet jeśli są to bardzo doświadczeni testerzy, którzy są w stanie wykonać różne typy testów, takie jak: testy manualne, automatyzacja, testy wydajności, testy bezpieczeństwa, testy API, testy statyczne, możemy być pewni, że nie są specjalistami w każdej z tych dziedzin. Są więc w stanie dostarczyć nam określoną ich jakość. Czyli może się zdarzyć, że będziemy mieć bardzo dobrych testerów manualnych, którzy testów wydajności będą musieli się dopiero uczyć, w związku z tym, jakość tych testów będzie wątpliwa.

Oznacza to, że posiadając pewne skończone zasoby, nigdy nie będziemy w stanie zapewnić najwyższej jakości testów w kontekście wszystkich pojawiających się potrzeb – nawet jeżeli nasi testerzy dołożą największych starań i będą pracować czy dokształcać się po godzinach. A co w momencie, kiedy praca testerów akurat nie jest potrzebna? Przecież ciągle płacimy za zajmowane przez testerów krzesła – co oczywiście oznacza, że marnotrawimy posiadane przez siebie środki.

Quality-Assurance-JPro

Rysunek 1. Potrzeby względem dostarczanych testów. Niebieska linia przerywana oznacza pracę wykonaną, błękitne pola wartości, które pokryły potrzeby w projekcie, a białe pole oznacza niepokryte przez testy obszary.

Narzędzia testerskie

Istnieje też problem narzędzi. To, że dysponujemy określonymi narzędziami nie oznacza wcale, że są one najlepsze. Zazwyczaj wybór narzędzi przypomina sposób, w jaki wybieramy piekarnię, w której kupujemy codziennie bułki. Najlepsze według nas bułki to nie takie, które są faktycznie najlepsze w całym mieście, a takie które były wystarczająco dobre, żebyśmy przestali szukać innej piekarni. Bułki zwykle nie są dla nas priorytetem, tak jak testy nie są priorytetem dla wielu firm wytwarzających oprogramowanie. Firmy te, ze względu na to, że nie specjalizują się w testach, rzadko posiadają wiedzę o najnowszych, najbardziej optymalnych rozwiązaniach, trudno też od nich wymagać, żeby miały pełną ich paletę.

Specjalizacja

Priorytet i specjalizacja to w tym przypadku słowa klucze, bowiem firma zajmująca się tworzeniem oprogramowania zazwyczaj nie będzie traktowała testów jako core swojej działalności. To programowanie nim jest. Może więc powinna poszukać odpowiedniego partnera technologicznego, dla którego właśnie testy są priorytetem?

Pracując w systemie, w którym nasi testerzy muszą pokrywać bardzo różne wymagania, zawsze będziemy mieć problemy z odpowiednim pokryciem testami. Taki system nie tylko dostarcza nieefektywne testy, ale również produkuje pracowników, którzy są „mistrzami w niczym". Czyli testerów, którzy potrafią „trochę tego, trochę tamtego". Problem polega na tym, że nawet z najlepszymi chęciami i predyspozycjami ci testerzy sami stają w obliczu pułapki „umiejętności średniej jakości".

Przestańmy się więc oszukiwać. Dobrej jakości testy automatyczne, nie zostaną wykonywane przez testera, który zajmuje się nimi sporadycznie, bo na co dzień zajmuje się testami manualnymi, czasem może wydajnościowymi. Testy automatyczne wymagają wyspecjalizowanego programisty testów, który swój czas poświęci nie tylko na przygotowanie skryptów testujących, ale także ich utrzymanie, refaktoryzację itd. Z drugiej jednak strony utrzymywanie w zespole wyspecjalizowanego testera, który ma wykonać testy raz na 4 miesiące nie ma ekonomicznego sensu.

Dobrym przykładem jest także bezpieczeństwo i wydajność. Wykonujemy te testy raz na jakiś czas, w związku z tym zatrudnienie na pełny etat wyspecjalizowanego w nich testera będzie trudne do obrony, przynajmniej z ekonomicznego punktu widzenia. Co więc jeśli zależy nam na tym, żeby nasze testy wykonywał doświadczony specjalista, który dostarczy testy najwyższej jakości? Rozwiązaniem tego problemu wydają się być usługi: wewnętrze lub zewnętrzne.

Więcej w kolejnej części artykułu, którą opublikujemy już wkrótce.

Autorem wpisu jest

Leszek Zieliński, JCommerce

Software Quality Assurance Engineer

Od 2011 roku realizuje i kieruje projektami QA. Ekspert w obszarze testów manualnych i automatycznych. Zafascynowany głównie rozwiązaniami BDD. Absolwent Politechniki Śląskiej w Gliwicach. Po godzinach działacz społeczny, muzyk, trójboista.

Komentarze

  • Aktualnie brak komentarzy.

Skontaktuj się z nami