Powrót inżynierii oprogramowania

Czy to źle? Ani źle, ani dobrze: taka jest specyfika ludzkich zbiorowości. Warto to dobrze rozumieć, bo wiedza na temat prawdziwych mechanizmów zwiększa szanse na wygraną w konkurencyjnej walce. Nie chodzi o to, aby do projektów IT zatrudniać psychologów albo etnografów, lecz by umieć wybierać ogólnie najlepsze, najskuteczniejsze metody działania w projektach IT, a nie zamykać się w przesądach należących do jednej tylko szkoły.

Przesuwające się granice i znikające punkty

Przez lata panowało mnóstwo nieporozumień na temat testowania. Czynności, które zajmują nawet 40% i więcej czasu pracy w projekcie, polegające na tym, że uruchamia się system czy jego kawałek, aby sprawdzić poprawność jego działania, nie zasługiwały w oczach wielu na osobną nazwę, nie chciano w nich widzieć odrębnej sfery, wymagającej specyficznych umiejętności. Testowanie zlewało się w jedną, amorficzną masę z programowaniem, gubiło się w meandrach debugowania lub – zdaniem niektórych – było nieważnym zadaniem, które można było powierzyć osobom bez kwalifikacji.

W latach 80. nastąpił gwałtowny wzrost świadomości testowania, pojawiły się książki, standardy, certyfikaty i nowe nazwy zawodu. Firmy, które jako pierwsze wskoczyły do pociągu testowania, wygrały. Te, które się spóźniły, musiały nadrabiać straty lub w ogóle wypadły w gry.

Dziś testowanie stało się pełnoprawnym elementem praktycznej inżynierii oprogramowania, ale w miejsce starych przesądów pojawiły się nowe.

Jeden z nich to przekonanie, że testowanie jest głównym mechanizmem zapewnienia jakości produktu informatycznego. Wymownym wyrazem tego przesądu jest nagminne nadużywania słowa „jakość”, zamiast testowanie. Testera nazywa się często „Quality Assurance Engineer” lub QA, przypisuje się mu odpowiedzialność za jakość testowanego produktu, zleca zadania niemające nic wspólnego z testowaniem, np. zbieranie wymagań. Często tak zdefiniowane zadania można znaleźć w ogłoszeniach o pracy. Nawet polskie stowarzyszenie testerów nazywa się – nomen omen – Stowarzyszeniem Jakości Systemów Informatycznych!

Jeśli nie inżynieria, to co?

Szczególną formą tego zjawiska jest fenomen tzw. testowania eksploracyjnego albo „szkoły kontekstowej testowania”. W Polsce niezbyt popularna, w niektórych krajach rozprzestrzeniła się wręcz histerycznie. Wymownym przykładem jest największa w Europie konferencja testowania EuroSTAR, która w roku 2013 odbyła się pod sztandarami szkoły kontekstowej. Koncepcja testowania eksploracyjnego zawiera wiele cennych metod i technik, ale zwolennicy zrobili z niej swoistą ideologię, podporządkowującą sobie obszary należące do zupełnie innych gałęzi inżynierii oprogramowania – inżynierii wymagań, zarządzania projektami.

Uleganie plemiennej wizji inżynierii oprogramowania grozi nam w tym kontekście dwiema ślepymi uliczkami: zupełnym ignorowaniem paru świetnych pomysłów testowania eksploracyjnego albo potępieniem dobrych metod tradycyjnych oraz marnotrawienia czasu i sił na rewolucję eksploracyjną.

Inny obszar inżynierii oprogramowania, który – choć kluczowy dla skuteczności i dla efektywności projektów IT – rzadko kiedy bywa nawet nazywany po imieniu, to inżynieria wymagań. Nagminnie ukrywa się ona pod innym, popularniejszym określeniem „analizy biznesowej” albo znika pod przykryciem zarządzania projektami. Czytam opis szkolenia zarządzania projektami: „nauczysz się skutecznie określać i weryfikować cele swoich projektów” – czyli mowa będzie o wymaganiach, testach akceptacyjnych, walidacji, ale te słowa nie padają.

Ważne obszary inżynierii wymagań ukrywają się w popularnych systemach certyfikacji PMI (w PMBOK), w PRINCE2, w standardach ITIL, COBIT. Dobrze, że jest tam o nich mowa; szkoda, że takie podejście znacznie ogranicza inżynierię wymagań, będącą w swojej istocie dziedziną interdyscyplinarną, do węższego zakresu spraw, dotyczącego zarządzania projektami lub usługami IT.


TOP 200