Modern Testing, czyli testowanie bez testera

Produkcja oprogramowania ciągle ewoluuje. Programy, które kiedyś wymagały lat pracy, teraz zespół dwu-trzy osobowy potrafi napisać w weekend. Zawdzięczamy to wielu czynnikom, zaczynając od ogromnego wzrostu mocy obliczeniowych komputerów, po rozwój naszych narzędzi i języków programowania, jak i zasad, wzorców programowania, na metodykach kończąc.

Maciej Wyrodek. Tester z 8 letnim doświadczeniem. Specjalizuje się w automatyzacji, choć jego pierwszą miłością są dalej testy eksploracyjne. Pracował w wielu projektach w Polsce i zagranicą. Od dwóch lat udziela się aktywniej w community, prezentując na wielu konferencjach i meetupach. W wolnym czasie prowadzi swój blog thebrokentest.com.

Konsekwencją tego jest parę rzeczy:

• o wiele łatwiej o konkurencję,
• użytkownicy mają o wiele więcej opcji (dzięki czemu koszt zmiany zmalał),
• firmy są w stanie dostarczać swoje aplikacje o wiele szybciej.

W tym świecie jakość jest wciąż ważna, ale jak to Amerykanie lubią mówić „What brought us here, won’t bring us there”.

To samo tyczy się tradycyjnego testowania. Pomogło ono dotrzeć do tego miejsca w jakim obecnie jesteśmy, ale nie znaczy to, że umożliwi dalszą podróż. Wiele firm zdało sobie z tego sprawę i zmieniło swoje podejście do testowania (Microsoft, Unity, Spartez, Netflix).

To co sprowadza nas do tematu Modern Testingu, to nie próba wymyślenia nowego teoretycznego sposobu testowania. Modern Testing stara się nadać nazwę i wyciągnąć esencję z praktyk tych firm, by ułatwić ich wdrożenie innym.

Problemy z tradycyjnym testowaniem

Uwaga, większość problemów zarysowanych w tej sekcji dotyczy i Waterfall, i Agile. Ale dla uproszczenia wątku będę używał terminologii „agile’owej”.

Wąskie gardło

Obecnie testowanie najczęściej wygląda tak: developer kończy pisać kod, tester dopiero zabiera się za testowanie. Nieważne czy to feature, historyjka czy bug, co z reguły oznacza, że testowanie jest na końcu fazy. Niesie to za sobą pewne problemy, jeśli cokolwiek opóźni się to odbędzie się kosztem testowania. Co z tego, że to zbieranie wymagań opóźniło się, czy może developerzy mieli problem, ale to przez to, że testowanie będzie na końcu, to ono będzie powodem przekroczenia deadline’u i najczęściej ono będzie poświęcone. Dlatego wielu uważa, że testowanie jest wąskim gardłem.

Ale to nie do końca prawda. Jeśli zrobić poprawnie Root Cause Analysis, okaże się, że testowanie jest po prostu miejscem, w którym to wąskie gardło się ujawniło, ale samo testowanie nie jest jego przyczyną. Co to oznacza? Często, zamiast po prostu przesunąć historyjki na inny sprint, czy przesunąć deadline, testowanie zostaje okrojone w czasie — na czym ostatecznie cierpi produkt.

Zobacz też

QA Każdego tygodnia wykonujemy 250 tys. testów. Jak wygląda praca testera w Ericsson

Testerzy jako siatka zabezpieczająca

Innym częstym problemem jest traktowanie testerów jako siatki zabezpieczającej. Developerzy, zamiast samemu pomyśleć i upewnić się czy coś działa, wypchną kod, bo „najwyżej tester złapie”. A potem zaczyna się długi ping-pong, bo jeśli tester nie siądzie od razu do testowania tej historyjki, to minie czas zanim bug zostanie znaleziony, historyjka wróci do developera, a zanim on to sprawdzi i zrozumie swój kod (on już mógł dobre parę dni robić co innego może nie pamiętać już detali) i naprawi, potem znowu retest… to wszystko kosztuje!

Ostatnio usłyszałem termin Bug-Driven Development, czyli developer, który nie zdążył zrobić historyjki, oddaje byle co, byle kompilowało się. A potem tak naprawdę brakująca funkcjonalność jest implementowana jako bugi. Niestety miałem nieprzyjemność współpracować z zespołem, który tak pracował, czyli z takim, w którym testowanie nie było jedynym problemem, ale było wygodną wymówką.

Tester jako adwokat klienta

Pewnie każdy spotkał na swojej drodze takiego testera, który myślał o sobie jako tym ostatnim prawym, który stoi między developerami a klientem, który zgłaszał bugi i wymaga mniej więcej takich zabiegów by zreprodukować.

Źródło grafiki: monkeyuser.com

Sam kiedyś taki byłem, ale zmianę zawdzięczam firmie Contium (teraz Grupa Unity). Testerzy odpowiadali tam także za support aplikacji po jej wydaniu na produkcję.

Bardzo szybko nauczyłem się, że wiele bugów, które naprawiliśmy wcale nie przeszkadzało klientowi. A wiele rzeczy, o których my nie pomyśleliśmy, były dla niego naprawdę problemem. Tester nie jest klientem! (chyba, że pisze soft dla testerów). On ma swoją hipotezę, czym jest jakość i na czym może zależeć klientowi. Tak samo, jak Produkt Owner ma hipotezę jak feature może się przydać. Ale prawda jest taka, tylko i wyłącznie klient jest w stanie powiedzieć czy produkt jest dobrej jakości.

Jest wiele innych jeszcze patologii tradycyjnego testowania, na przykład traktowanie testerów jako kozły ofiarne. Drogi czytelniku, jeśli choć odrobinę jesteś taki jak ja, to zaczynasz się niecierpliwić, bo nadal nie napisałem, czym jest Modern Testing! A poza tym gadam o produkcie, a pewnie pracujesz w software housach aka B2B.

Tak, mówię o firmach produktowych, bo jest to o wiele łatwiejsze do pokazania na przykładzie takich firm, ale te same zasady tyczą się także software house’ów.

Czas na Modern Testing

Jak wszystko, Modern Testing ma swój manifest – możecie go znaleźć tutaj. Na końcu artykułu znajdziecie moje tłumaczenie na polski.

Po pierwsze czym jest jakość?

Twórcy modern testingu często powtarzają: Klienci nie kupują oprogramowania, Klienci kupują rozwiązanie ich problemu.

Co prowadzi nas do pytania:

Mamy dwa programy, które w teorii rozwiązują ten sam problem.

Oprogramowanie A – które ma też cały backlog pełen bugów. Ale 100 tysięcy użytkowników.

Oprogramowanie B – które nie ma znanych błędów, ale ma tylko 50 użytkowników.

Które z tych narzędzi jest lepszej jakości? MT twierdzi, że A. Ci użytkownicy wybrali to oprogramowanie, bo mimo tych wszystkich bugów ono rozwiązuje ich problem lepiej niż B.

Dlatego Modern Testing uważa, że jakość to rozwiązany problem dla użytkowników.

Konsekwencją tego jest nastawienie na szybkie prototypownie, małe, ale częste wydania by można było ocenić, czy rozwiązujemy problem użytkownika. W takiej sytuacji testowanie na końcu jest problematyczne, bo wydłuża ten czas.

Dlatego ono musi dziać się szybciej. Stąd jest większa odpowiedzialność na developerach za to, by ich kod działał. Oczywiście to nie znaczy, że od jutra nie ma testerów i sam sobie radź. Oczywiście jakby teraz nagle zabrać testerów, to by jakość poszła ostro w dół. Bo większość developerów nie ma odpowiednich narzędzi z testowaniem i umiejętności.

Ale to jest cel, do którego dąży MT. Czy sugeruje, jak to uzyskać? Tak. Poleca eksperymentację, czyli próbować, co działa a co nie. Nie możemy bać się porażek i musimy się na nich uczyć. Więc pierwsze co musi się wydarzyć to zapewnić, że konsekwencje porażki są odpowiednio małe.

Czyli częste wydania, zbieranie danych i obserwacja czy wszystko działa, i najważniejsze możliwość szybkiego wycofania zmian jak coś się zepsuje.

Tutaj też objawia się największy fakt o Modern Testingu. By zapewnić jakość oprogramowania, zmiany nie mogą być w testach, a w całym procesie.

Oferty pracy z

Jak to wygląda z mojej perspektywy?

Bez bicia przyznam się, że nie miałem okazji pracować w projekcie, który w pełni przestrzega zasady modern testingu. Ale pracowałem w paru, które zmierzały w tym kierunku nim nawet znały nazwę.

Uważam, że ścieżka Modern Testing dla firm produktowych jest naturalną ewolucją z Agile i DevOps. Tego typu firmy naprawdę wiele zyskują na szybkim dostarczaniu i szybkim weryfikowaniu swoich zmian.

Największą kwestią jest jak zawsze dojrzałość zespołu do jakości — to największe wyzwanie. Na szczęście reguły modern testingu także wyznaczają kierunek jak zabrać się zabudowę tej kultury. Kwestia software house’ów jest jednak bardziej skomplikowana.

W przypadku modeli takich jak Time and Material, czyli opcja sprzedaży samych deweloperów bez testerów może ułatwić sprzedanie testowania. Zwłaszcza kiedy mamy do czynienia z klientami, którzy nie rozumieją jego wagi.

Sprawne wykorzystanie Modern Testing w B2B definitywnie zależy od tego jak dobrą relację mamy zbudowaną z klientem i jak bardzo możemy wpłynąć na to jak on używa oprogramowania.

Źródła

Jest wiele kwestii, które chciałbym jeszcze poruszyć, ale ten artykuł miał być zajawką tematu, a nie pełnym tutorialem Modern Testingu.

Jeśli jesteście zaciekawieni i chcieliście dowiedzieć się więcej, tutaj link do podcastu poświęconego Modern Testingu. Odcinki 81 i 83-88 są poświęcone omawianiu poszczególnych zasad i jak je wdrożyć w życie.

Dziękuję za uwagę, poniżej moje tłumaczenia zasad.

Zasady Modern Testing

1. Naszym priorytetem jest usprawnianie biznesu.

2. Przyspieszamy zespół używając modeli takich jak zwinne myślenie (ang. Lean Thinking) oraz teoria ograniczeń (ang. Theory of Constrains), by pomóc znaleźć, priorytezować oraz ograniczać wąskie gardła w systemie.

3. Wspieramy ciągłe udoskonalanie. Pomagamy zespołowi dostosować się do zmian i ciągle rozwijać w celu uzyskiwania sukcesów.

4. Mocno dbamy o kulturę jakości w naszym zespole, uczymy, prowadzimy i pielęgnujemy zespół w kierunku bardziej dojrzałej kultury jakości.

5. Wierzymy, że tylko Klient jest w stanie ocenić jakoś naszego produktu.

6. Używamy danych by w pełni zrozumieć działanie naszego klienta, oraz by zminimalizować różnice między hipotezami a rzeczywistością.

7. Rozwijamy umiejętności testowania i know-how w zespole. W pełni rozumiemy, że może to zmniejszyć (lub wyeliminować) potrzebę specjalisty w testowaniu.

Zobacz też

QA W banku duży nacisk kładziemy na testowanie. Historia Piotra Józwiaka