by Logo Technical Blog – Future Processing
23.05.2013
Komunikacja DEV−QA a wczesne testowanie_

Czy zastanawialiście się kiedyś, jak u Was w projektach wygląda komunikacja pomiędzy tymi dwoma grupami ludzi? Absolutnie nie chcę tutaj wchodzić w rozumowanie typu: „u nas jest Agile, a w Agile nie ma podziału DEV/QA”. Jestem pewien, że w większości projektów ten podział w pewnym stopniu występuje. Ale nie o tym teraz.

Czy zdarzyło Wam się kiedyś powiedzieć do deva: „hej, twój kod jest do niczego, a program działa jak krew z nosa” albo „znowu zapomniałeś obsłużyć ten wyjątek, a tutaj to już kompletnie się zbłaźniłeś”? Czy zdarzyło się Wam kiedyś pomyśleć w ten sposób? Nie musicie tu odpowiadać na te pytania, sami znacie prawdę − jeżeli obydwie odpowiedzi są przeczące, możecie zrezygnować
z dalszego czytania. Trzeba sobie w takiej sytuacji zadać proste pytanie: co ja mogłem zrobić, żeby zapobiec takiej sytuacji?
Czy może ta funkcja nie działa także z mojej winy? Ktoś powie, że to dev stworzył tę funkcję i nic nam do tego. BŁĄD.
Jesteśmy jednym zespołem, a komunikacja to podstawa − trzeba o tym pamiętać w każdym momencie. Jeżeli mamy wymagania i wiemy, że za chwilę będą implementowane przez devów, to może warto poświęcić trochę czasu na ich wcześniejszą analizę?
Spisać możliwe przypadki testowe, nietypowe sytuacje, miejsca podatne na wszelkiego rodzaju błędy. Skoro my je znamy,
to dlaczego nie podzielić się tą wiedzą z devami?

Wyobraźmy sobie, że mamy te informacje w chwili, gdy dev siada do zadania i możemy te wszystkie przypadki z nim omówić, wskazując potencjalne niedoróbki, a przede wszystkim, prezentując mu nasz punkt widzenia. O ileż łatwiej będzie nam testować, wiedząc, że w założeniu dev już na etapie implementacji znał potencjalne miejsca wystąpienia błędów i starał się od razu przed nimi uchronić.

Testowanie powinno zaczynać się jak najwcześniej i chciałbym Was wszystkich gorąco zachęcić do ścisłej współpracy z devami.
Im więcej uwag, wątpliwości im przekażecie już na samym początku, tym lepsze będzie nasze oprogramowanie.
Nie bójmy się rozmawiać z devami, trzymajmy się razem z nimi, pracujmy w parach. Pamiętajmy także o stylu komunikacji, bardzo ważne jest nasze nastawienie do reszty zespołu. Jeżeli podejdziemy do deva i po raz kolejny powiemy coś w stylu: „stary, znowu zrobiłeś kiepską  robotę”, albo „twoje kodowanie jest słabe, a ficzery są do niczego”, to nie dziwmy się negatywnemu nastawieniu
do naszej osoby, a nawet samego procesu testowania. Dev to tak samo członek zespołu i powinniśmy traktować go z szacunkiem,
a błędy zgłaszać w formie obiektywnych spostrzeżeń całkowicie pozbawionych personalnych przytyków.
W końcu − wszyscy gramy w tej samej drużynie. Wszystko dla jeszcze lepszego procesu i tak naprawdę łatwiejszego życia całego zespołu.

Być może większość z Was od dawna pracuje w ten właśnie sposób, ale jeśli choć jednej osobie mój post w jakimś stopniu pomoże, będę zadowolony :).

Related Posts

Comments

Cookies

This website stores cookies on your computer. These cookies are used to improve our website and provide more personalized services to you, both on this website and through other media. To find out more about the cookies we use, see our Cookies policy.