Automatyzacja testów dla managerów. Q&A

W odpowiedziach staram się nie wypowiadać swoich poglądów, ale bazować na danych i opiniach uznanych ekspertów chyba, że pytany jestem o moją opinię. W niektórych przypadkach nie udało mi się znaleźć wartościowych źródeł z odpowiedzią, dlatego w takich przypadkach albo powstrzymuję się od udzielenia odpowiedzi, albo dzielę się własnymi doświadczeniami. 

Nagranie sesji Q&A znajdziecie tutaj:

Poniżej pytania i odpowiedzi w formie tekstowej:

1. [Q]: Czy wyniki badania uwzględniają rozmowy/opinie z innymi praktykami? (Piotr, menadżer testów)
   
   [Redakcja] To pytanie odnosi się do pierwszej części webinaru „Automatyzacja testów dla Managerów” dostępnego >> tutaj << 
   
   [A]: Tak.
2. [Q]: Jakie są najczęstsze błędne przekonania menadżerów dotyczące kosztów i zwrotu z inwestycji (ROI) w automatyzację testów? 
   
   [A]: Najczęstszym błędnym przekonaniem jest założenie, że da się precyzyjnie wyliczyć ROI dla automatyzacji testów. W rzeczywistości, wiele zmiennych wpływających na rzeczywisty zwrot z inwestycji jest trudnych do zmierzenia lub nieprzewidywalnych.
3. [Q]: Czy możesz podać konkretne liczby lub przykłady pokazujące rzeczywisty koszt i oszczędności wynikające z dobrze wdrożonej automatyzacji?
   
   [A]: Koszty automatyzacji są stosunkowo łatwe do oszacowania, natomiast rzeczywiste oszczędności są trudne do precyzyjnego określenia. 
4. [Q]: Jak dobrze pokazywać wartość (QA) w liczbach? 
   
   [A]: Podobnie jak w przypadku automatyzacji testów, pokazanie wartości całego procesu QA w liczbach jest wyzwaniem. 
5. [Q]: Dlaczego nie lubisz automatyzacji?? (Edyta, Manager)
   
   [A]: Nie jest to kwestia niechęci, ale zdrowego sceptycyzmu, opartego na doświadczeniu. Podchodzę sceptycznie do skuteczności automatyzacji, ponieważ obserwowałem więcej nieudanych projektów automatyzacji niż udanych. Nadal poszukuję przekonujących dowodów, że automatyzacja testów się często / zawsze / zazwyczaj sprawdza
6. [Q]: Wdrażam się od niedawna w automaty… w jakie narzędzia teraz inwestować patrząc w przyszłość? (Daniel, konsultant)
   
   [A]: Pytanie opiera się na założeniu, że istnieją narzędzia, które w przyszłości będą bardziej opłacalne niż inne.
   
   
   
   Software Test Automation - Gartner Magic Quadrant 2019
7. [Q]: Jakie masz podejście do automatyzacji / bądź nie w branżach mocno regulowanych (banking/pharma) etc - gdzie część testów musi być wykonywana na poziomie Acceptance/UI? (Bartek)
   
   [A]: Automatyzacja powinna być stosowana wszędzie tam, gdzie testowanie ręczne jest niewystarczające lub gdzie korzyści z automatyzacji przewyższają zalety innych metod kontroli jakości. 
8. [Q]: W którym momencie wytwarzania oprogramowania powinna rozpocząć się automatyzacja testów? (Miron)
   
   [A]: Automatyzacja testów powinna rozpocząć się jak najwcześniej (ASAP). W idealnym przypadku, nawet jeszcze przed powstaniem właściwego kodu oprogramowania.
9. [Q]: Jak podejść do zbierania danych liczbowych w organizacji która ma już wdrożoną automatyzacje i przepala na to zasoby? (TAE / Łukasz /Adam, kierownik) [1/2]
   
   [A]: Warto skupić się na miarach powiązanych z ROI - porównanie kosztów automatyzacji względem
   a.    Liczby znajdowanych defektów
   b.    Pokrycia funkcji
   c.    Pokrycia kodu
   
   Pomaga też pomiar nieefektywności (co wymaga obserwacji i badania automatyzacji):
   a.    Flaky test, 
   b.    Testy false positive i false negative
   c.    Testy, które niczego nie sprawdzają
   d.    Sprawdzenie jakości automatyzacji – posiew defektów
10. [Q]: Jak podejść do zbierania danych liczbowych w organizacji która ma już wdrożoną automatyzacje i przepala na to zasoby? (TAE / Łukasz /Adam, kierownik) [2/2]
    
    [A]: Warto rozważyć wdrożenie uznanych metryk, takich jak: 
    a.    EMTE: Equivalent Manual Test Effort, 
    b.    DDP - the number of defects found in testing, and the number that were found later, 
    c.    Durability, 
    d.    Percent Automatable or Automation Index
    
    
11. [Q]: Jak podchodzić do budowania testów automatycznych opartych na procesie biznesowym e2e? Czy takie testowanie ma sens? (Tomasz, Manager)
    
    [A]: Nie wiem czy w danym kontekście projektu takie testowanie ma sens. Automatyzacja długich i złożonych procesów ma sens, jeśli spełnione są następujące warunki:
    a.    Proces jest stabilny
    b.    Aplikacja nie podlega dużym zamianom
    c.    Testowany software jest podatny na automatyzację
    d.    Framework jest wdrożony wraz z dobrymi praktykami automatyzacji
12. [Q]: „…"próg bólu" - kiedy testów jest za dużo i więcej spędzamy 100% czasu na pisaniu i analizie, a nie inwestujemy w rozwój i szukanie lepszych rozwiązań?” (Bartosz, Lead)
    
    [A]: Dokładnie wtedy testów jest za dużo. Zawsze powinniśmy zostawić sobie czas na szukanie lepszej metody.
13. [Q]: Jak wiele firm faktycznie analizuje opłacalność automatyzacji i rozważa koszty z nią związane a jak wiele "ślepo" podąża za trendem automatyzacji? (Kasia, Leader)
    
    [A]: Żadna znana mi organizacja nie ma (nie miała) poprawnie zrobionej analizy opłacalności (ROI) przed wdrożeniem automatyzacji.
14. [Q]: Jakie są koszty związane z automatyzacją, które są najczęściej pomijane/niezauważane podczas sprawdzania opłacalności? (Kasia, Leader)
    
    [A]: Najczęściej pomijanym elementem są długoterminowe koszty utrzymania automatyzacji.
15. [Q]: Ja poradzić sobie z niechęcią biznesu do tworzenia historyjek do automatyzacji i późniejszego monitorowania wyników? (Paweł, Leader)
    
    [A]: Odpowiedź zależy od znajomości konkretnego kontekstu organizacji. Moje rozwiązania
    a.    Zbudować dobre relacje z biznesem / zbudować świadomość wagi testów
    b.    Wprowadzić / zmodyfikować proces. 
    c.    Formalnie przerzucić odpowiedzialność za testy na biznes (umowa).
    d.    Dokumentować sobie zbiór dowodów na brak zaangażowania biznesu (na czarną godzinę).
16. [Q]: Kiedy zaprzestać automatyzacji, jeśli zostały już poniesione koszty? (Asia, Leader)
    
    [A]: ASAP, jeśli tylko okaże się, że automatyzacja nie dowozi.
17. [Q]: Jak przekonać firmę do zakupu płatnych narzędzi? (Asia, Leader)
    
    [A]: Najskuteczniejszą metodą jest przeprowadzenie pilotażowego wdrożenia narzędzia w mniejszym zakresie projektu. Konkretne, mierzalne wyniki z takiego pilotażu dostarczą znacznie silniejszych argumentów niż sama teoria i obietnice.
18. [Q]: Kiedy zmieniać narzędzie? Jak kalkulować koszt zmiany narzędzia do automatyzacji?
    
    [A]: Narzędzie można zmienić, kiedy dysponujemy dowodami na to, że inne narzędzie jest skuteczniejsze / tańsze / szybsze. Kalkulując koszt zmiany, trzeba uwzględnić: 
    a.    …
    b.    Koszt migracji istniejących testów do nowego narzędzia
    c.    Koszt wycofania starego narzędzia
    d.    Koszt utraconych korzyści z poświęcania czasu na zmianę narzędzia
19. [Q]: Czy warto inwestować w testy wizualne GUI? (Ela, managerka)
    
    [A]: To zależy od kontekstu projektu. Automatyzacja po GUI zazwyczaj ma bardzo silną konkurencję innych metod kontroli jakości.
20. [Q]: Parokrotnie spotkałem się z propozycją "przepiszmy framework z X (zazwyczaj Selenium) na Y (Playwright, Cypress, coś tam innego)". Czy znane są Wam case study kiedy to miało sens? Ani razu nie udało mi się przekonać siebie samego do tego że to może mieć finansowy sens. (Michał, inżynier)
    
    [A:] Jeśli miarą sukcesu jest „przepisanie” automatyzacji, to większość takich projektów kończy się sukcesem. Jeśli sukcesem jest osiągnięcie większej skuteczności automatyzacji, to większość takich projektów kończy się niepowodzeniem.
21. [Q]: Kiedy […] korzyści są na tyle niewielkie, że nie warto wprowadzać automatyzacji do projektu? (Michał, Lead)
    
    [A]: Automatyzacji nie warto wprowadzać w następujących przypadkach:
    a.    Kiedy czas poświęcony na automatyzację jest dłuższy niż czas poświęcony na inne, równie skuteczne lub skuteczniejsze metody kontroli jakości
    b.    Dla oprogramowania niepodatnego na automatyzację
    c.    Dla oprogramowania niestabilnego
    d.    W krótkich projektach (realne korzyści z automatyzacji zazwyczaj są widoczne dopiero po 6-12 miesiącach)
    e.    Dla oprogramowania o dużej zmienności kodu
22. [Q]: [Mam małą styczność z kodem i testami automatycznymi czy tak powinno być w przypadku roli QA Managera? (Sebastian, Manager)
    
    [A]: Można to porównać do pytania, Czy dyrektorem szpitala powinien być lekarz? Odpowiedź zależy od zakresu odpowiedzialności QA Managera:
    a.    Jeśli decydujesz o metodach pracy, powinieneś mieć wiedzę o tych metodach (można posiłkować się „ekspertami dziedzinowymi”)
    b.    Jeśli  kontrolujesz skuteczność metod, musisz rozumieć ich mechanizmy działania.
    W mojej opinii: im głębsza wiedza o zarządzanym obszarze, tym większe szanse na efektywne dobieranie i wdrażanie metod testowych.
23. [Q]: Czy jako QA Manager powinienem aktywnie brać udział w przygotowywaniu zautomatyzowanych przypadków testowych? (Sebastian, Manager)
    
    [A]: To jak pytanie, czy dyrektor szpitala powinien operować? Moja opinia: manager pracujący przy automatyzacji ma większą świadomość jej kosztów, wartości i skuteczności.
24. [Q]: Co konkretnie przekonuje managera, że warto inwestować w automatyzację / utrzymywać / rozwijać obecny projekt? (Michał, automatyk / Gosia, managerka / Natalia, kierownik…)
    
    [A]: Argumenty, które przekonują managerów do inwestowania w automatyzację: 
    a.    Wykazanie, że rozwiązanie jest tańsze, szybsze lub jakościowo lepsze od alternatyw 
    b.    Odwołanie się do złych zdarzeń projektowych – kiedy emocje są jeszcze podgrzane
    c.    Udowodnienie, że nie ma innych, równie efektywnych metod
    d.    Przedstawienie porównania z innymi metodami, wykazując przewagę automatyzacji
    Jak podać powyższe argumenty? Najlepiej w 3 minutowej prezentacji. 
25. [Q]: Jak przekonać opornych członków zespołu, że automatyzacja ma dla nich sens (a nie chcą się rozwijać)? (Manager)
    
    [A]: Argumenty, które najskuteczniej przekonują testerów do automatyzacji:
    a.    Pieniądze 
    b.    Nowe, ciekawe zadanie
    c.    Większa odpowiedzialność
26. [Q]: Jaki framework jest dominujący na rynku i czy to prawda, że Playwright jest najbardziej trendującym frameworkiem do automatyzacji?  (Michał, inżynier)
    
    [A]: Dostępne są dane ilościowe z badań rynkowych. Wg tych danych Playwright nie jest najpopularniejszy.
    
    
27. [Q]: Czym się kierować wybierając obszary testów do zautomatyzowania? (Manager QA)
    
    [A]: Warto zastanowić się, co potrafi automat?
    a.    Teza 1: automat potrafi jedynie skontrolować obszar już wcześniej sprawdzony ręcznie podczas projektowania testów
    b.    Teza 2: automat nie ma zdolności do wykrywania nowych defektów. Może potwierdzić, że wcześniej znaleziony defekt nie pojawił się ponownie.
    
    Może sprawdzić, czy obszar wcześniej przetestowany ciągle poprawnie działa.
    Automatyzacja przyniesie korzyść tam, gdzie uruchamiamy ją wielokrotnie i gdzie chcemy pokazać brak regresu.
28. [Q]: Czy na przestrzeni lat, ROI z automatyzacji weryfikacji, znacząco się zmieniło (Aleksander, inżynier)
    
    [A]: W mojej opinii, jakość i efektywność automatyzacji znacząco wzrosła w ostatnich latach dzięki:
    a.    Lepszym i prostszym narzędziom (w tym rozwiązaniom typu no-code, które są lepsze niż kiedykolwiek)
    b.    Lepszym praktykom automatyzacji
    c.    Lepszym umiejętnościom automatyków
29. [Q]: Jaki największy F.ck-up miałeś w zakresie automatyzacji, i co było dalej? Jakie lekcje wyciągnąłeś? (Sergiusz, Manager)
    
    [A]: Największą porażką był projekt automatyzacji testów dla urządzeń mobilnych, który zakończył się:
    a.    Przepalonymi milionami przy zerowej skuteczności testów, 
    b.    Upadkiem firmy
    
    Od tamtej pory
    •    Nigdy nie ufam bezkrytycznie zapewnieniom dostawców narzędzi
    •    Zaufanie buduję na dowodach, zawsze proponując pilotażowe wdrożenia
    •    Pytam ludzi decyzyjnych – dlaczego? 
30. [Q]: Jakie narzędzia do automatyzacji wybrać i jak pisać testy w software housie w którym jest dużo niewielkich kilkumiesięcznych projektów z jednym QA? (Michał, inżynier)
    
    [A]: W przypadku licznych, krótkoterminowych projektów z ograniczonymi zasobami QA, najlepszym podejściem jest automatyzacja tylko przy użyciu gotowych narzędzi. Zastanówmy się, czy dla kilkumiesięcznego projektu napisałbyś własne narzędzie do rejestrowania defektów?
31. [Q]: Przy jakim zakresie testów automatycznych koszty wdrożenia i utrzymania zaczynają przekraczać koszty testów manualnych? (Adam, manager)
    
    [A]: Koszty testów manualnych będą zawsze mniejsze od kosztów wdrożenia i utrzymania testów automatycznych. Korzyści z testów automatycznych mogą przewyższyć korzyści z testów manualnych, szczególnie, jeśli dany obszar nie powinien być testowany ręcznie.
32. [Q]: Jak wyjaśnić managerom klienta, że utrzymanie testów wymaga czasu i pielęgnacji? (Adam, inżynier)
    
    [A]: Skuteczne argumenty to:
    a.    Testy automatyczne to w istocie kod, podlegający tym samym zasadom co inne elementy oprogramowania 
    b.    Każdy kod wymaga regularnego utrzymania
    c.    Brak utrzymania prowadzi stopniowo do degradacji testów, często nieodwracalnej 
    d.    Dług technologiczny
33. [Q]: Czy na podstawie Twoich obserwacji dalej w zespołach pokutuje podejście że testy automatyczne "to się stworzy później" (po stworzeniu właściwego software)? (Michał, Manager)
    
    [A]: Nie. Dawno się z tym nie spotkałem. Warto zauważyć prawidłowość: jeśli projekt radzi sobie bez testów automatycznych w procesie wytwórczym, prawdopodobnie poradzi sobie również po wdrożeniu. 
34. [Q]: Jaka wartość może dać puszczanie testów automatycznych na produkcji (shift right testing)  (Agnieszka, architekt)
    
    [A]: Monitorowanie. 
35. [Q]: Czy jeśli flow są dość skomplikowane to czy takie ścieżki powinny być też objęte automatyzacją, mimo że maintanance będzie trudniejszy? Czy lepiej automatyzować proste flow? (Basia, testerka)
    
    [A]: Proste flow – testy dymne. Skomplikowane flow – testy regresji.
36. [Q]: Jak mierzyć i raportować pokrycie testami automatycznymi funkcjonalności w dużych systemach IT, z ogromną ilością możliwości konfiguracyjnych? (Mateusz, lider)
    
    [A]: W dużych systemach z wieloma konfiguracjami warto mierzyć procent przetestowanych konfiguracji w odniesieniu do:
    a.    Wszystkich konfiguracji
    b.    Kluczowych konfiguracji
    c.    Najpopularniejszych konfiguracji
37. [Q]: Ile czasu powinien poświęcać zespół na implementację nowych testów automatycznych, a ile na utrzymanie automatów? Czy istnieje tutaj wzorcowe ratio? (Mateusz, lider)
    
    [A]: Nie istnieją uniwersalne, wzorcowe proporcje - zależą one od kontekstu projektu. Utrzymanie będzie zazwyczaj priorytetowe. Porzucenie utrzymania oznacza degradację testów, a dobrze zaprojektowane testy powinny minimalizować koszty utrzymania.
    Lawinowo rosnące koszty utrzymania świadczą prawdopodobnie o złej metodzie kontroli jakości.
38. [Q]: Jakie powinno być ratio ilości testerów automatyzujących vs programiści rozwijający produkt?  (Mateusz, lider)
    
    [A]: Nie istnieje uniwersalny wzorzec proporcji testerów do programistów, po raz kolejny wszystko zależy od kontekstu projektu. Często spotyka się proporcję tester – developer ratio – 1:5, ale… (w nowoczesnych podejściach, gdzie odpowiedzialność za jakość jest bardziej rozproszona, proporcje te mogą być zupełnie inne)  
39. [Q]: Jak podchodzić do automatyzowania testów nowych funkcjonalności w wersjach, które są w sprincie i na koniec mają być wydane? Skoro automatyzuje się regresje, a w tym nowych funkcjonalnościach jest sporo bugów blokujących często automatyzacje? (Mateusz, lider)
    
    [A]: Nie automatyzować.
40. [Q]: Jakie są największe ograniczenia AI w testowaniu oprogramowania? (Ola, Lead)
    
    [A]: Gen AI nie testuje oprogramowania – głównie generuje kod i dane. Pierwszą nadzieją do prowadzenia testów jest Operator / Agent, ale nawet one będą miały ograniczenia wynikające z braku wiedzy biznesowej i znajomości potrzeb użytkowników końcowych.
41. [Q]: Tradycyjna automatyzacja, czy to ma sens w dobie AI? (Paweł, QA Manager)
    
    [A]: TAK. AI jeszcze nie pokazało swojej skuteczności w kontroli jakości.
42. [Q]: Czy zaimplementowanie AI w automatyzacji jest faktycznie opłacalne biznesowo czy to tylko chwilowy trend? (Agnieszka)
    
    [A]: Gen AI udowodniło swoją przydatność na poziomie generacji i sprawdzenia poprawności skryptów. Biorąc pod uwagę znaczące inwestycje w rozwój tej technologii, ten trend może z nami zostać na dłużej.
43. [Q]: Czy AI będzie przydatna do testów automatycznych? (Paweł, Test Manager)
    
    [A]: Gen AI jest przydatne do testów automatycznych.
44. [Q]: Polecane narzędzia AI do automatyzacji? (Mateusz, Leader)
    
    [A]: Jednym z najbardziej wszechstronnych narzędzi AI wspierających automatyzację testów jest obecnie ChatGPT.

Po samej prezentacji otrzymałem jeszcze kilka pytań, na które nie udało mi się udzielić odpowiedzi w trakcie więc robię to teraz.

1. Jakich argumentów używać kiedy chcemy pokazać, że automaty to nie wszystko?
   
   Najważniejszym argumentem będzie pokazanie, że istnieje cały obszar kontroli jakości, którego nie da się zautomatyzować. Oczywiście możemy próbować wdrażać automaty niemalże wszędzie, ale musi zostać przeprowadzony rachunek ekonomiczny opłacalności poszczególnych metod. Najważniejsze pytanie, jakie należy sobie zadać, to czy automat będzie najtańszym, najszybszym i najskuteczniejszym rozwiązaniem naszego problemu?
2. Dlaczego dyskusję o automatyzacji skupiamy na porównaniach z manualnym testowaniem zamiast szukania maksymalnego toolsetu dla testera w celu suplementacji jego pracy (zwiększenia jej efektywności)?
   
   Na rynku widać wyraźny podział, w którym testowanie sprowadza się do dwóch obozów: manualnego i automatycznego. Jest to promowanie jednej metody poprzez krytykę innej popularnej i powszechnie stosowanej. Podobną drogą swego czasu próbowano pokazać siłę metodyk Agile zestawiając ją z najbardziej podatnym na krytykę modelem kaskadowym. 
   
   Zestawienie testów automatycznych po GUI z testowaniem manualnym jest próbą pokazania swojej skuteczności w oparciu o jeden parametr – szybkość uruchomienia testów. 
   
   Żeby realnie podejść do rozmowy o jakości, musimy przyjrzeć się pełnemu spektrum metod oraz narzędzi jej kontroli i wybrać te najbardziej optymalne dla nas. Jednocześnie musimy pamiętać, że niekoniecznie będzie to jedno rozwiązanie, a raczej miks wielu. 
3. Jaki proces automatyzacji był brany pod uwagę przy tych opracowaniach oraz przy Pana rozważaniach? Czy był brany pod uwagę proces na podstawie TDD?
   
   W analizie brane pod uwagę są wszystkie metody automatyzacji uruchomienia testów wymagające napisania dedykowanego kodu lub zbioru poleceń - od testów jednostkowych (w tym również metody TDD) przez testy integracyjne, aż po testy po interfejsie graficznym.
   
   Jeśli brane są pod uwagę inne formy automatyzacji jak np., monitoring, to jest to powiedziane. 
4. Czy faktycznie jest tak, że coraz częściej testerzy w zespołach również są odpowiedzialni za procesy CI/CD, ich projektowanie i utrzymanie? 
   
   Przerzucenie odpowiedzialności za proces CI / CD jest praktyką, ale nie jestem w stanie określić, czy jest to powszechne zjawisko. W mojej opinii CI / CD jest procesem wydawania i dostarczania oprogramowania, w związku z tym jego własność powinna być po stronie wytwórczej, ale oczywiście ze wsparciem ze strony zespołów QA i testerskich.

Część wykładowa: