Redakcja
Paweł Cichoński: Cześć Rik. Jak widzisz przyszłość testowania oprogramowania? W dobie TDD i sztucznej inteligencji ... Czy testerzy zostaną zasymilowani przez zespoły agile, czy będą coraz bardziej niezależni?
Rik Marselis: Cześć Paweł, dziękuję za zaproszenie. Tak, to ciekawe i jednocześnie lekko dezorientujące czasy dla testerów. Niektóre zespoły agile’owe (zwinne) nie mają już wydzielonej funkcji testera. Jednakże, by członkowie zespołu wiedzieli jak testować, profesja ta musi mieć swego przedstawiciela. Tester profesjonalista może im często pomóc poprzez coaching i wsparcie - na przykład pokazanie, jak prawidłowo stosować TDD.
Sztuczna inteligencja jest zarówno błogosławieństwem, jak i zagrożeniem dla testerów. Błogosławieństwem, gdyż wymaga zupełnie nowych kompetencji. Podczas testowania maszyny, która się uczy, nie będziesz w stanie w prosty sposób przewidzieć wyniku końcowego. Z biegiem czasu rezultaty będą się zmieniać, gdyż maszyna będzie się uczyła. W tej sytuacji znalezienie sposobu na odpowiednie przetestowanie będzie ekscytujące. Możesz uważać się za psychologa sztucznej inteligencji ;-)
Niektórzy postrzegają sztuczną inteligencję jako zagrożenie, ponieważ jeżeli maszyny zrobią się zbyt mądre mogą zastąpić pracę testerów, przez co stracimy nasze prace. Uważam jednak, ze spośród wszystkich ról w IT testowanie jako ostatnie zostanie całkowicie zautomatyzowane, ponieważ testowanie wymaga kreatywności, a pełna automatyzacja testów nie jest prosta. Byłoby miło gdyby maszyny przejęły całą nużącą pracę tworzenia test case’ów w celu osiągnięcia 100% pokrycia. Wtedy moglibyśmy skupić na pracy twórczej i wyzwaniach intelektualnych.
PC: Jakie według Ciebie umiejętności powinien mieć (lub szlifować) inżynier testów, by odnieść sukces w obecnych czasach?
RM: Najważniejsze dla testera powinno być używanie kombinacji technik testowania opartych na pokryciu i doświadczeniu. Wiem, że wielu testerów testuje patrząc tylko na pokrycie i polegają całkowicie na predefiniowanych test case’ach. Wiem również, że wiele osób korzysta jedynie z testów ad hoc wykorzystując swoje doświadczenie i technikę „zgadywania błędów” (ang. Error Guessing) opisaną przez Glenforda Myers’a w książce „The art of software testing” z 1979. W mojej ocenie nie jest to podejście optymalne. Uważam, że zawsze powinno się korzystać do pewnego stopnia zarówno z technik projektowania testów opartych na pokryciu, jak i testów opartych na doświadczeniu, jak choćby testów eksploracyjnych. Na stronie www.tmap.net znajduje się opis naszego podejścia do testów eksploracyjnych, które wypracowaliśmy bazując na pracy osób takich jak: Cem Kaner, Elisabeth Hendrickson, James Whittaker oraz na serii naszych książek o TMap.
Pomimo wielu technik projektowania testów tester zazwyczaj musi korzystać z 5-10 z nich: jakich konkretnie, to już zależy od okoliczności. Ważną umiejętnością testera jest prawidłowe określenie potrzebnych technik i skuteczne ich wdrożenie. Moja rada: róbcie warsztaty/szkolenia poświęcone konkretnym technikom projektowania testów i ćwiczcie poprawne korzystanie z testów eksploracyjnych (korzystając z charterów, logów i odpraw).
PC: Obecnie testerzy skupiają się na zautomatyzowaniu jak największej ilości testów regresji. Czy istnieje jakieś podejście lub metryka, która odpowie jaki procent testów powinniśmy zautomatyzować, a jaki pokryć testami eksploracyjnymi?
RM: W mojej ocenie poprawne testowanie zaczyna się wraz ze strategią testów opartą na ryzyku. Jeżeli ryzyko nie istnieje to nie ma potrzeby dla testów regresji, jeżeli natomiast jakiś obszar jest potencjalnie zagrożony powinieneś puszczać pełny zestaw regresji automatycznie przy każdej zmianie w oprogramowaniu. W świecie agile testy regresji powinny być przeprowadzane podczas każdego sprintu lub nawet po kilka razy w trakcie jego trwania. Dodatkowo musisz także uwzględnić testy eksploracyjne. Ponieważ automatyzacja oznacza testy tylko wcześniej zdefiniowane może się okazać, że pewne zdarzenia zostaną wykryte jako anomalia (rezultat inny niż oczekiwany), która nie zostanie dalej analizowana lub nie zostaną wykryte wcale (gdy rezultat jest zgodny z oczekiwaniami, ale pojawia się nieoczekiwany efekt uboczny, np. poprawny rezultat, ale w postaci białej czcionki na białym tle, co tylko człowiekowi może wydać się niepożądanym efektem).
Podsumowując: łączmy testowanie oparte na pokryciu (predefiniowane) oraz doświadczeniu (testy eksploracyjne).
PC: Czy podczas pracy nad automatyzacją w danym projekcie powinniśmy najpierw skupić się na wyborze narzędzia i na tym budować, czy wręcz przeciwnie – najpierw opracowujemy podejście do automatyzacji, a narzędzie dobieramy na tej podstawie?
RM: Powiem krótko: “głupiec z narzędziem to nadal głupiec” i „jeśli zautomatyzujesz chaos otrzymasz jedynie bardzo szybki chaos”. Najpierw powinno się opracować strategię automatyzacji i będąc pewnym jej ewentualnych zalet, zacząć dobierać odpowiednie narzędzia i je wdrażać. W praktyce często oznacza to najpierw stworzenie konkretnych zestawów testów, a następnie automatyzację tych częsci, w których da to konkretną wartość.
PC: Jaki jest Twój stosunek do dokumentacji testowej? Czy ma sens rygorystyczne planowanie i pełna dokumentacja całego procesu?
RM: Powinieneś tworzyć dokumentację jedynie, jeśli jest dla kogoś przydatna. Szczegółowa dokumentacja może posłużyć do demonstracji pokrycia testami dla różnego rodzaju urzędów i organizacji certyfikujących (np. w systemach krytycznych ze względu na bezpieczeństwo). Nazbyt często zdarza się jednak, że testerzy tworzą tony dokumentacji, której nikt nie czyta.
Pierwszym krokiem powinno być rozpoznanie wśród wszystkich zainteresowanych, jakiej dokumentacji która grupa potrzebuje. Szybko przekonasz się, że potrzeby klienta są zupełnie różne od wymagań programistów, a jeszcze inne mają testerzy.
Dbaj, by dokumentacja nie rozrastała się niepotrzebnie. Używaj zdjęć, obrazków, emotikon i wykresów – przekazują równie dużo informacji, co 30-stronicowy raport.
PC: Jaką radę mógłbyś dać project managerom odnośnie automatyzacji I testów eksploracyjnych?
RM: Rada dla project managerów … usiądź ze swoim zespołem na 2 godziny i zapytaj w jaki sposób widzą współpracę w projekcie, skupiając się głównie na budowie zaufania do jakości skrojonej do potrzeb oraz braku zbędnego ryzyka.
Jeżeli problemy jakościowe i ryzyko jest duże i potrzebujesz automatyzacji testów, upewnij się, że zostanie ona wprowadzona. Nie wprowadzaj automatyzacji tylko dlatego, że jest w innych projektach.
Testy eksploracyjne zawsze są przydatne, ale nie jako jedyne podejście do testowania.
PC: IoT jest teraz na czasie – jak podejść do testowania tego typu urządzeń I całych systemów? Jak możemy upewnić się, że nasze dane są bezpieczne i nie mają do nich dostępu niepowołane osoby?
RM: Patrzę na IoT jak na część szerszej ewolucji. Wraz ze sztuczną inteligencją, analizą ‘big data’, przetwarzaniem w chmurze i innymi nowoczesnymi technologiami prowadzą do robotyki. Testowanie robotyki to z kolei coś, co mnie intryguje. Częściowo będziemy testować tak, jak robimy to od dawna (testowanie funkcjonalne, wydajności, bezpieczeństwa, itp.), ale będziemy też odkrywać nowe cechy jakości, jak choćby empatię (czy system ma na uwadze nasze odczucia, np. lodówka IoT nie obudzi Cię w środku nocy, bo odnotuje koniec daty ważności na opakowaniu mleka) lub personifikacja (jak powinien wyglądać robot, by być dobrym towarzyszem – obecnie panuje przekonanie, że roboty nie powinny wyglądać zbyt ludzko, gdyż wprowadza to pewien dyskomfort). Oczywiście bardzo ważna w przypadku sztucznej inteligencji będzie etyka. Mając na uwadze powyższe technologie spodziewać się można wielu dylematów odnośnie nowych możliwości i zagrożeń. Jako przykład zapoznaj się z ‘Moral machine survey’ z Uniwersytetu MIT (moralmachine.mit.edu)
PC: Dziękuję Ci bardzo! Z niecierpliwością oczekuję Twojej grudniowej wizyty we Wrocławiu.
Rik Marselis jest konsultantem w Sogeti (należącego do grupy Capgemini). Pracuje w branży IT od ponad 35 lat, a od około 20 specjalizuje się w jakości i testowaniu. Systematycznie wnosi swój wkład w tematykę testowania poprzez badania i rozwój. Jako współpracownik SogetiLabs (sieć badawcza Sogeti) brał udział w opracowaniu wielu artykułów i książek, a jego ostatnie publikacje to TMap HD, The PointZERO vision, Quality Supervision, Integrate Test Activities in Agile Projects i TPI NEXT. Obecnie jest zaangażowany w badania dotyczące testowania robotów.
Jest doświadczonym prelegentem na europejskich konferencjach IT, a jego prezentacje są zawsze doceniane za żywiołowość, nieskomplikowane przedstawienie nawet poważnych tematów oraz umiejętne użycie praktycznych przykładów i humorystycznych porównań. Obok pracy w Sogeti, Rik jest również aktywnym członkiem inicjatyw związanych z testowaniem oprogramowania jako przewodniczący TestNet - niezależnego stowarzyszenia testerów w Holandii oraz członek grup roboczych ISTQB pracujący m.in. nad przygotowaniem sylabusów ISTQB.
Wywiad przeprowadził Paweł Cichoński, lider Software Watch – społeczności testerskiej działającej w ramach wrocławskiego oddziału Capgemini – Software Solutions Center. Od 10 lat związany z testowaniem i zapewnieniem jakości oprogramowania.
7 grudnia 2016 o godzinie 18.00 w siedzibie Capgemini przy ul. Strzegomskiej 42 odbędzie się otwarty wykład Rika Marselisa. Oficjalna strona wydarzenia i start zapisów już wkrótce.
Dziękujemy firmie Capgemini za udostępnienie materiału.
