Programiści i testerzy powinni wspólnie tworzyć zarówno produkt, jak i jego testy

Tworzenie software’u jest proste, nawet bardzo. Dostajemy wymaganie od klienta, próbujemy je zrozumieć, zdekomponować, a potem zakodować. Najczęściej sprowadza się to do prostego CRUDa – aplikacji typu create, read, update, delete. Czyli można utworzyć dane, przeczytać, zaktualizować i usunąć. To ostatnie czasem nie zostaje doimplementowane, bo po co? To nie jest najważniejsze, a czas goni. Taki kawałek aplikacji to nie jest jednak żaden „rocket science”.

Najbardziej generyczna architektura klasy pudełko, pudełko i beczka oraz dwie dzidy w zupełności wystarczają. Najpiękniejsze w takim rozwiązaniu jest to, że można je szybko i łatwo przetestować. Nie trzeba robić doktoratu z teorii testowania, nie trzeba używać automatów ani wymyślnych narzędzi. Uruchamiamy aplikację, klikamy i gotowe. Można wystawić fakturę i gnać do następnego projektu. Eh, gdyby tak świat wyglądał, jakże by było pięknie… ale tak nie jest.

Jedynie na początku tworzenia produktu wszystko wygląda tak wspaniale jak w pierwszym akapicie. Rzeczywistość różni się tym, że ten pierwszy akapit jest powtarzany x razy. Gdzie x bardzo rzadko kiedy jest mniejsze niż 100. Ilość wymagań jakie daje klient jest olbrzymia. To jednak nie jest problem – taka praca. Problem jest taki, że wymagania są ze sobą powiązane. W dodatku klienci rzadko wiedzą dokładnie czego potrzebują, co powoduje, że wymagania się zmieniają. Czasem lekko, czasem fundamentalnie. To z kolei powoduje, że po pierwsze generyczna architektura (2x pudełko + beczka + 2x dzida) zupełnie przestaje się nadawać. Początkowy CRUD przynosi więcej szkody niż pożytku, a przetestowanie aplikacji staje się lekko mówiąc niełatwe.

Zobacz też

DevDebata Bolączki testera. Devdebata

Klient ZAWSZE będzie zmieniał wymagania

Sądzisz, że gdyby klienci dokładnie wiedzieli czego chcą to byłoby łatwiej? Możliwe, ale przeprowadźmy eksperyment myślowy. Przypomnij sobie jak wyglądał Twój pierwszy telefon. W zależności od tego ile masz lat, był to albo analogowy czerwony, albo zielony aparat wykonany z bakelitu, który wisiał na ścianie lub stał na biurku. Może była to pokraczna cegła, która potrafiła dzwonić i wysyłać sms-y, ale którą trzeba było ładować raz na tydzień lub dwa. Może też był to jako tako działający kawałek plastiku, który trzeba ładować codziennie. Kiedy już masz przed oczami swój pierwszy telefon to zastanów się, jakie były wtedy Twoje potrzeby z nim związane…. A teraz porównaj to ze swoimi wymaganiami odnośnie następnego telefonu, który kupisz. Gdyby prawdą było, że klienci nie zmienią raz wymyślonych wymagań to prawdą również byłoby, że Twój pierwszy telefon byłby ostatnim jaki kupujesz w życiu. Mam nadzieję, że jedno mamy ustalone. Klient ZAWSZE będzie zmieniał wymagania. To jest pewne.

Tak samo pewne jest, że jeśli Twój klient używa Twojego software’u, to będzie przyrastała ilość funkcjonalności. Tutaj dochodzimy do pewnej granicy, gdzie programista lub programiści przestają mieć czas, a czasem nawet wiedzę jak sensownie testować oprogramowanie. Pojawia się potrzeba zatrudnienia ludzi wyspecjalizowanych w testowaniu właśnie, którzy potrafią przeklikać aplikację, przetestować ją za pomocą automatów i którzy wiedzą jak poprawnie zrobić testy wydajności czy pentesty. Pojawia się potrzeba współpracy z człowiekiem specjalizującym się tylko w tej dziedzinie.

Oczywiście możemy nie testować aplikacji, przetestują ją użytkownicy. Jednak w takiej sytuacji użytkownicy dosyć szybko zaczynają być poirytowani, bo otrzymują produkt, który nie spełnia ich potrzeb, sypie się, a w skrajnych przypadkach w ogóle nie uruchamia. Co zrobi klient w takiej sytuacji? Po prostu zrezygnuje z naszych usług. Czyli wiemy już, że warto testować. Osoby zajmujące się testami są potrzebne.

Kto ważniejszy – tester czy programista?

Czas na finałowe pytanie – kto jest ważniejszy? Tester czy programista? Niektórym wydaje się, że programista…, ale szanowny programisto, ile jest wart Twój produkt, jeśli sypie błędami tak, że użytkownicy już z niego żartują? Innym wydaje się, że testerzy…, ale szanowny testerze, ile jest warta Twoja praca, jeśli nie ma produktu, który masz testować? Sensowny zespół to taki, na który składają się obie role. Powiedzmy to jeszcze raz, SENSOWNY ZESPÓŁ…. OBIE ROLE. Nie ma sensownego zespołu złożonego z samych testerów albo samych programistów.

Idealny zespół to taki, gdzie zarówno programiści, jak i testerzy wspólnie tworzą produkt. Wspólnie, to znaczy, że pracują razem. Razem znaczy, że jeden nie czeka, aż drugi skończy. Razem oznacza, że wspólnie i równolegle tworzą zarówno produkt, jak i testy do tego produktu.

Dlaczego wspólnie? Co jest złego w tym, że testerzy zaczynają swoją pracę dopiero po tym jak programiści „coś” wytworzą? „Coś” jest tutaj użyte bardzo umyślnie. Zanim to „coś” nie zostanie przetestowane, nie wiadomo czy to „coś” nadaje się do dostarczenia klientowi.

Oferty pracy z

Koszty, koszty, koszty…. Koszty rosną tym bardziej, im później testujemy oprogramowanie. Jeśli podczas testowania okaże się, że znaleziony został błąd to trzeba go poprawić. Jeśli błąd znajdziemy godzinę po napisaniu kodu – ile czasu programista poświęci na poprawkę? Raczej niewiele, bo jeszcze będzie pamiętał jak stworzył kod. Z dużą dozą prawdopodobieństwa będzie w stanie w przeciągu kilku minut naprawić go. W dodatku, jeśli nie zostało to dostarczone do klienta to nie będzie skutków w postaci utraconych danych, zgłoszeń od klienta, kar, incydentów itp. Co jeśli błąd znajdziemy dwa tygodnie po napisaniu kodu? Ile czasu programista będzie musiał poświęcić, aby odszukać felerny kawałek kodu? Obstawiam, że znacząco więcej. A co jeśli testujemy pół roku później?

Trzeba pamiętać, że koszt usunięcia błędów rośnie wraz ze wzrostem czasu jaki upłynął od momentu stworzenia błędu do jego wykrycia. Dlatego tworzy się testy jednostkowe, bo te wykrywają błędy w sekundach – dają najszybciej informację, że coś jest nie tak. Niestety nie są w stanie wyłapać wszystkiego. Dlatego mamy dalsze testy komponentów, integracyjne czy end to end. Należy jednak pamiętać, że dalsze testy powinny być wykonywane możliwie jak najszybciej.

Jeśli testerzy współpracują ramię w ramię z programistami, wówczas otrzymujemy przetestowany produkt przy możliwie najniższym koszcie.

To jednak nie koniec. Czasem niewielkim kosztem można już na etapie pierwszych linijek kodu przygotować system do późniejszego testowania, co ułatwi pracę testerom. Jednak aby to miało miejsce, warto aby testerzy i programiści pracowali razem – obok siebie. Najlepiej w jednym teamie. Bo trzeba i jednych, i drugich, aby dostarczyć sensowny produkt z wartością dla klienta.

Współpracujmy

Co się stanie, jeśli do jednego teamu wrzucimy programistów i testerów? Powstanie team deweloperski – taki, w którym ludzie uzupełniają się kompetencjami. To spowoduje, że team będzie w stanie dostarczać produkty lepszej jakości przy jednoczesnym utrzymaniu kosztów na akceptowalnym poziomie. To jest coś czego oczekują klienci i za co są skłonni płacić więcej. Dlatego zamiast walczyć, współpracujmy, aby wszystkim żyło się lepiej.

Zdjęcie główne artykułu pochodzi z unsplash.com.