Radek Smilgin
Jak wiele razy podkreślaliśmy, za jakość końcowego produktu odpowiada cały zespół. Współpraca członków zespołu jest więc kluczowa do osiągania optymalnych rezultatów.
Tester programiście może ułatwić pracę poprzez:
- znajdywanie defektów w oprogramowaniu,
- dbanie o wysokiej jakości specyfikację wymagań,
- dobre raportowanie problemów,
- pomoc w poszukiwaniu rozwiązywania dla defektów (patrz: https://testerzy.pl/baza-wiedzy/artykuly/tester-driven-development),
- pomoc w interpretacji wymagań klienta,
- itd.
Programista testerowi może ułatwiać pracę poprzez:
- budowanie testowalnego oprogramowania,
- dostarczanie noty wydania z opisem zmian w oprogramowaniu,
- itp.
Obie role mogą współpracować nad budową środowiska testów automatycznych, uruchamianych na każdej nowo zbudowanej wersji oprogramowania. Dotyczy to testów jednostkowych, integracyjnych oraz e2e (skrótów operujących na interfejsie GUI). Odnosi się to też zarówno do środowiska uruchomienia, zaprojektowanych skryptów, jak i danych testowych.
Przykład
Współpraca testera z programistą w projekcie najczęściej widoczna jest przy okazji zgłaszania i obsługi defektów. Niskiej jakości zgłoszenie od testera będzie skutkować zwrotką od programisty z komentarzem „u mnie działa” lub „potrzebne więcej informacji do reprodukcji”. Brak informacji o rodzaju dokonanych zmian przez programistę utrudnia wykonanie retestu przez testera.
Programista, oddając defekt bez informacji jak został on naprawiony, upraszcza sobie pracę, ale utrudnia ją testerowi. Nie jest to duży problem, gdy mamy szczegółową i jednoznaczną specyfikację, która pokazuje, jak oprogramowanie ma się zachowywać. Jednak gdy nie wiemy do końca, co zostało zrobione, to musimy się domyślać, jaka poprawka została wprowadzona i w jaki sposób. Dodatkowym problemem będzie tutaj trudność w zdefiniowaniu zakresu testów regresji. Nie mając informacji o zakresie zmian oraz obszaru kodowego, którego one dotyczyły, nie będziemy w stanie jednoznacznie określić, ile i jakie testy uruchomić. Możemy zostać przymuszeni do uruchomienia wszystkich, co jest kolejnym antywzorcem projektowym i sygnałem patologii.
Kluczowa staje się więc nota wydania, która powinna zawierać informacje nie tylko o tym, jakie defekty zostały poprawione w danej wersji oprogramowania, jakie nowe funkcje zostały dodane, ale również jakie wcześniej testowane moduły zostały zmodyfikowane aby wprowadzić zmiany. Dzięki temu tester ma pełną informację o zakresie pracy do wykonania.
Podsumowując, środowisko pracy z otwartą dwukierunkową komunikacją jest szansą na lepsze i efektywniejsze wytwarzanie oprogramowania.
