O interakcjach niekoniecznie mile widzianych
piątek, 15 listopada 2013
Rozważania o testowaniu cz1

Mówienie o testowaniu jest modne

Testowanie stało się modne. Pisze się o nim coraz więcej, ustala normy, certyfikuje, firmy tworzą dedykowane zespoły, uczelnie otwierają specjalistyczne kierunki, a portale pracy zarzucane są ofertami na stanowisku testera oprogramowania. Wraz ze wzrostem popularności następuje również rozwój mitów i legend, które niestety rozprzestrzeniają się w zastraszającym tempie. Chciałbym przedstawić swoje przemyślenia o tej branży z punktu widzenia osoby związanej z edukacją (wykładowcy), jak i z branżą IT (kierownika zespołu testowego). Moją analizę potraktuję jako zabawę. Opowiadając o wielu aspektach będę je ‘testował’ tworzył przypadki testowe, scenariusze i jeśli się da - sprawdzał rezultaty.

Na początek przedstawmy sobie trzy główne poziomy testowania:
1) Czy działa? – sprawdźmy czy dana rzecz funkcjonuje
2) Czy działa poprawnie? – sprawdźmy czy wszystko funkcjonuje wedle ustalonych zasad biznesowych
3) Jak zepsuć? – sprawdźmy czy odejście od ustalonych zasad lub tworzenie nowych scenariuszy potrafi wywołać  nieprzewidywane i/lub niechciane efekty.

Te trzy poziomy są świetnym przykładem na pokazanie różnorodnego podejścia do testowania. Na zajęciach zawsze zadaję pytanie „Dlaczego tworzy się dedykowane zespoły testowe? Dlaczego developer czy analityk nie są najlepszymi kandydatami do testowania?”.

Powodów jest wiele: od kosztów (testerzy to jednak tania siła robocza), przez zasadę ‘niezależności’ (developerzy nie powinni sprawdzać wzajemnie swojej pracy), do właśnie podejścia do testów. Analitycy czy developerzy stosują zasadę ‘good enough’ co oznacza, że zatrzymają się na co najwyżej drugim poziomie i nie będą na siłę doszukiwać się usterek czy usprawnień.

Takie podejście do testów jest obarczone sporym ryzykiem dostarczenia oprogramowania słabej jakości i kompletnie nie nadaje się w przypadku firm, które chcą tworzyć nie tylko projekty ale i wartościowe produkty.

Testerzy są potrzebni – to wiedzą i zauważają wszyscy. Firmy potrzebują ludzi do testowania, uczelnie otwierają kierunki specjalizujące się w tej dziedzinie, młodzi ludzie zauważają okazję i starają się przebranżowić. Trend na pierwszy rzut oka jest fajny. Jednak spróbujmy to dokładniej przeanalizować, gdyż fakt, że dużo się mówi nie oznacza, że dobrze i sprawnie się działa.

 

Część 1. Wyedukujmy sobie testera

Uczelnie pragnąc unowocześnić swój program otwierają kierunki dedykowane testowaniu – jest to fajny przykład dostosowywania się do potrzeb rynku i na pewno idea przechodzi pierwszy poziom testów „działa”. Jednak zastanówmy się jakie są zasady biznesowe i czy są spełnione. Potem pomyślmy, co może się nie udać i jakie są ryzyka związane z ideą wytwarzania oprogramowania…

Sformujmy zasady biznesowe:
1) osoba po kierunku ‘testowanie oprogramowania’ powinna dysponować wiedzą i umiejętnościami pozwalającymi na łatwe zdobycie pracy na stanowisku testera.
2) osoba po kierunku ‘testowanie oprogramowania’ powinna posiadać wiedzę, która stanowi wartość dodaną dla firmy (występuje w roli specjalisty czy eksperta).

Jak to przetestować?

Możemy przyjrzeć się absolwentom przeanalizować ich potencjał rekrutacyjny czy wiedzę. Problem w tym, że nie ma jeszcze absolwentów. To nowy projekt w pierwszej iteracji i nie możemy czekać tak długo. Nasze przypadki testowe powinny być dostosowane do tego czym dysponujemy.

Popatrzmy więc na program zajęć, ich organizację, samych studentów i ich podejście i spróbujmy z tego ekstrapolować nasze wnioski. Mam okazję prowadzić zajęcia z zakresu testowania na WSB oraz uczestniczyć w organizacji planu takich zajęć na innych uczelniach. Standardowym dokumentem karta przedmiotu – gdzie rozpisane są zajęcia i ich zakres. Łatwo więc analizując ten dokument określić jakich testerów sobie wykształcimy.

Tu niestety pierwsze rozczarowanie. Karty przedmiotów z którymi się spotkałem były niedostosowane do potrzeb. Jedna dla przykładu była przekopiowaniem kilku najważniejszych rzeczy z sylabusa ISTQB, druga skupiała się na organizacji testów jednostkowych i skupiona była głownie na testowaniu przez developerów.

Innym problemem jest właściwe wyważenie pomiędzy teorią testowania a praktyką. Uczelnie posiłkujące się sylabusem ISTQB skupiają się praktycznie tylko na teorii. Rzeczy związane z psychologią testowania czy ogólnie podejściem do testowania – czyli umiejętności miękkie są pomijane lub traktowane po macoszemu. Jeśli firma informatyczna ma ustalone procesy testowania, wzory dokumentacji czy inne tego typu elementy, to w procesie rekrutacji skupi się na poszukiwaniu osoby pomysłowej, nieszablonowej, potrafiącej doszukiwać się problemów – a nie teoretyka, który wie na jakie typy testy można dzielić.

Nie ma nic złego w takich przedmiotach jeśli to fakultety i w ramach całego kierunku znajduje się kompletny zestaw przedmiotów poruszający różne zagadnienia z zakresu testowania.

Nikt chyba jednak nie podszedł od tej strony… nie pomyślał jakie przedmioty stworzyć i w jaki sposób z kierunku „testowanie oprogramowania” stworzyć kompletny pakiet. Uczenie idąc na poziom minimum po prostu wzięły inne kierunki i dodały jakieś losowe przedmioty związane z testowaniem. W rezultacie 80-90% to klasyczne przedmioty z innych kierunków (wiedza ogólna) + 10% coś losowego z testowania (chaotyczne wycięcie wiedzy specjalistycznej).

Jaki jest sens realizowania projektu, jeśli już sama dokumentacja jest niekompletna i z niej wynikają duże braki? W klasycznym projekcie informatycznym po zauważeniu czegoś takiego PM projektu by kazał to dokładniej przeanalizować i poprawić. W edukacji robi się roczniki eksperymentalne i czeka kilka lat na rezultaty. Dlaczego komisje programowe na uczelni nie zadadzą sobie trudu zapytania biznesu – czego w praktyce rynek pracy potrzebuje.

Już teraz widać, że nie jest dobrze zorganizowane – produkt tworzony przez uczelnie – będzie wybrakowany i niekompletny, a ciężar właściwej edukacji jak zawsze spocznie na firmach.

Nie tylko ramy programowe i zakres są problemem. Sami studenci również nie są przekonani do tego kierunku. Zadałem na zajęciach pytanie – „czy chcecie być testerami i zarabiać pieniądze jako tester oprogramowania?”. Okazało się, że nie – większość uczestników myśli o byciu grafikami czy analitykami a testowanie traktują tylko jako mało znaczący dodatek.

I jak przy takim podejściu mamy spełnić nasze założone zasady biznesowe? Nie da się…

Czy nawet jest sens tworzyć przypadki testowe i analizować ten problem od strony pytania „jak to zepsuć?”. No cóż… wydaje mi się, że to samo się psuje już w pierwszych krokach realizacji.

Ten projekt zdecydowanie wymaga poprawy… fajnie by było jakby uczelnie nie tylko posiłkowały się swoimi pracownikami, ale i wyszły do przemysłu i wspólnie spróbowały stworzyć kompleksowy plan nauczania, w którym przedmioty ogólne nie będą przekraczały 50% materiału.

Brakuje nam łączników. Brakuje ludzi, którzy połączą biznes z uczelniami. To bardzo odległe od siebie światy i potrzeba sporo wysiłku aby zbudować mosty między nimi. Wniosek ten nie dotyczy tylko testowana, ale można go rozwinąć

Koniec części pierwszej…
W następnym odcinku: rekrutacja testerów