Czas na konkrety!

Czy programista może wykorzystać swoje umiejętności do innych celów niż pisanie kodu i czy te działania mogą przynieść dobry skutek? W metodykach zwinnych popularnym działaniem jest tzw. TDD (Test Driven Development), z grubsza rzecz ujmując, polega to na tworzeniu testu jednostkowego do kodu, który dopiero zamierzamy napisać. Każdy fragment programu realizujący określoną funkcjonalność będzie stowarzyszony ze zbiorem testów, których zadanie możemy interpretować jako pozytywne przetestowanie danego wymagania. Każdy zdany test jednostkowy obniży zatem ryzyko w systemie.

Aby tworzyć dobre testy jednostkowe, programista może poprosić o pomoc testera, który podpowie, jak efektywnie przetestować dany moduł. Programiście pozostanie jedynie zaimplementowanie testów. Warto korzystać z rad doświadczonych testerów, ponieważ ich testy będą silne, a więc będą w stanie wykryć więcej potencjalnych defektów.

Zobacz również:

• Relacja z WWDC 2023 - najważniejszej konferencji Apple w roku

Jeśli testy jednostkowe zbierzemy we wspólnym repozytorium, jesteśmy w stanie stworzyć zbiór testów regresyjnych. Testy regresji wykonuje się po zmianie oprogramowania na jego niezmienionych fragmentach, aby sprawdzić, czy wprowadzone zmiany nie zepsuły czegoś w innych miejscach programu. Ponieważ testy te wykonuje się często, regresja praktycznie zawsze jest zautomatyzowana.

Programista może wykorzystać swoje zdolności do automatyzowania innych testów. Czasami testerzy nie są w stanie samodzielnie zaimplementować kodu czy napisać fragmentu skryptu. Tu pomoc programisty jest nieoceniona. Tak stworzone testy automatyczne ułatwiają wykonanie wysokopoziomowych testów systemowych, które mogą stanowić część testów regresji.

W wielu firmach praktykuje się tzw. code review czy inne formy przeglądów bądź inspekcji dotyczących zarówno kodu, jak i dokumentacji czy projektu. Przegląd kodu polega na testowaniu go bez wykonywania. Obecność programisty na spotkaniu przeglądowym kodu autorstwa innego dewelopera niesie wiele korzyści: dobry programista może udzielić cennych rad w zakresie wykorzystania wzorców projektowych czy standardów kodowania; wychwyci często popełniane przez mniej doświadczonych kolegów błędy w kodzie. Programista z kolei usłyszy od testera, że jakieś wymaganie czy fragment kodu będą trudno testowalne lub niemożliwe do przetestowania. Wtedy mogą wspólnie popracować nad modyfikacją kodu, by proces jego testowania przebiegał szybciej i sprawniej. To przełoży się na większą zdolność testów do znajdowania defektów.

Badania pokazują, że inspekcje są efektywnymi metodami zapewniania jakości. Są w stanie wykryć nawet do 80% defektów! Co więcej, na inspekcjach często wykrywa się błędy projektowe, których koszt naprawy w późniejszych fazach cyklu życia byłby wielokrotnie większy niż po spotkaniu przeglądowym.

Inspekcje oraz testy systemowe są w stanie wykrywać defekty, których usunięcie poprawia jakość tworzonego oprogramowania. Ale jakość ujawnia się nie tylko jako zmniejszenie liczby defektów w tworzonym kodzie. Usunięcie znalezionych problemów pozwala poprawić sam proces produkcji oprogramowania.

Testy i przeglądy pozwalają na ulepszenie procesu pozyskiwania i analizy wymagań. Wymagania stanowią podstawę dla projektu. Ten z kolei jest podstawą, której używa programista do tworzenia kodu. Mamy więc w systemie dodatnią pętlę zwrotną: wymagania -> kod -> testowanie -> lepsza jakość -> lepsze wymagania. Aby ta pętla zadziałała, programista nie może ograniczać się tylko do tworzenia kodu. Powinien także:

• aktywnie uczestniczyć w inspekcjach i przeglądach kodu oraz dokumentacji;
• tworzyć dobrej jakości testy jednostkowe stanowiące podstawę suity testów regresji;
• pomagać testerom w automatyzowaniu testów.

Wymierne korzyści

Rysunek 2 przedstawia schematyczną sieć zależności, jakie mogą występować w projekcie. Jeśli programista nie będzie ograniczał się tylko do pisania kodu, lecz także współdziałał z innymi członkami zespołu, służąc im swoimi umiejętnościami, zwróci się mu się to z nawiązką. Po jakimś czasie zacznie dostawać wymagania lepszej jakości, na których podstawie będzie mógł łatwiej tworzyć lepszy kod.

Z punktu widzenia programisty takie działanie należy potraktować jako inwestycję zarówno dla siebie, jak i dla projektu. Wiadomo, że odrywanie się od swojej pracy, aby pomóc komuś innemu, zabiera cenny czas. Ale pomyślmy o tym w ten sposób: jeśli poświęcę średnio godzinę pracy dziennie na pomoc testerom, uczestnictwo w przeglądach czy pisanie testów jednostkowych, po jakimś czasie zyskają na tym wszyscy:

• testerzy – bo używając napisanych we współpracy z programistą testów automatycznych, będą w stanie efektywniej testować oprogramowanie;
• jakość procesu – bo wykryte defekty oraz ich analiza pozwolą na usunięcie przyczyn źródłowych problemów, lepszą kontrolę tworzonego kodu, obszerniejszą i dokładniejszą informację zwrotną dla programisty i lepszą jakość wymagań;
• programista – bo dostanie czytelne, bezbłędne wymagania, których nie będzie musiał konsultować z analitykami tak często jak do tej pory, co pozwoli na szybszą i efektywniejszą pracę, a tworzony kod będzie miał mniej defektów.

Widać, że zysk dla programisty nadejdzie dopiero po jakimś czasie. Wielu menedżerów popełnia błąd, przerywając wdrożenie zmian mających ulepszyć proces, ponieważ nie tylko nie widzą poprawy, ale wręcz dostrzegają pogorszenie jakości procesu. Również członkowie zespołu mogą zniechęcić się do zmian, widząc ich pozorny bezsens i nieskuteczność. To przejściowy okres chaosu związany z wdrożeniem nowych działań. Jeśli uda się go cierpliwie przeczekać, jakość stopniowo polepszy się, aż w końcu ustabilizuje się na nowym, wyższym niż początkowy poziomie. Taką sytuację związaną z wdrażaniem zmiany przedstawia model Virginii Satir przedstawiony na rysunku 3.

Myślenie systemowe pozwala zobaczyć cały proces wytwarzania oprogramowania. Zrozumienie zależności pomiędzy jego poszczególnymi częściami i określenie wpływu zmian w jednej z nich na inne umożliwiają łatwe udoskonalenie procesu. Zobaczyliśmy to na przykładzie programisty. Zidentyfikowaliśmy proste czynności, których wykonywanie przez dewelopera przyczynia się do ulepszenia zarówno jakości procesu, jak i tworzonego produktu.

Adam Roman – adiunkt w Instytucie Informatyki i Matematyki Komputerowej UJ, wieloletni trener i wykładowca przedmiotów związanych z testowaniem i zapewnianiem jakości oprogramowania. Certyfikowany inżynier jakości oprogramowania (ASQ CSQE) oraz tester (ISTQB – Full Advanced Level). Autor monografii „Testowanie i jakość oprogramowania. Modele, techniki, narzędzia” (PWN, 2015).