Trudno o sukces, kiedy nieznany jest cel. O pułapkach w podejściu do zapewniania jakości

– Bezcelowe jest automatyzowanie dla automatyzowania, tymczasem zaskakująco częstym celem automatyzacji testów jest uzyskanie pokrycia testów wyrażonego ekspercko oszacowaną wartością procentową – powiedziała nam Małgorzata Sadowska, Ekspert Testów. Wraz z Michałem Figlem, Kierownikiem Działu Testów Technicznych, opowiedzieli nam o pracy testera w takiej organizacji jak SOFLAB TECHNOLOGY.

Czym zajmujecie się w SOFLAB TECHNOLOGY?

Małgorzata Sadowska: W SOFLAB TECHNOLOGY pełnię rolę Eksperta Testów. W praktyce oznacza to, że w ramach projektów dla Klientów organizuję proces testowy oraz podpowiadam, jak radzić sobie z problemami w obszarze zapewniania jakości. Proponuję konkretne usprawnienia, dzięki którym podejście do testowania jest dopasowane do specyficznych potrzeb Klienta. W ramach prac wewnętrznych prowadzę szkolenia dla pracowników SOFLAB TECHNOLOGY oraz jestem odpowiedzialna za szkolenie i promowanie produktów firmy Tricentis wśród naszych zespołów oraz klientów.

Potrafiłabyś określić czasowo, czyli ile zajmuje ci dana część twojej pracy?

Małgorzata Sadowska: Nie liczę tego dokładnie, ale myślę, że ok. 70% czasu poświęcam głównie na prace projektowe takie jak różnego rodzaju audyty czy organizacje procesów testowych w projektach, a pozostałe 30% stanowią zadania związane ze wsparciem sprzedaży.

Dziękuję. Michał, czym Ty się zajmujesz w SOFLAB TECHNOLOGY?

Michał Figiel: W SOFLAB TECHNOLOGY pracuję od niemal siedmiu lat, zaczynałem od zadań programistycznych, koordynacji zespołów testowych, prowadziłem projekty wdrożeniowe narzędzi wsparcia i automatyzacji testów. Natomiast od trochę ponad 3 lat jestem kierownikiem działu testów technicznych. Razem z niemal 30-osobowym zespołem specjalistów wdrażamy rozwiązania automatyzacji testów zarówno oparte o frameworki open source, jak i narzędzia komercyjne. Pomagamy również w zarządzaniu wydajnością systemów, a także prowadzimy wdrożenia rozwiązań opartych o narzędzia Atlassian.

Waszym zdaniem organizacje zbyt późno interesują się testowaniem czy automatyzacją testów? Czy zazwyczaj to jest zbyt późny proces waszym zdaniem?

Małgorzata Sadowska: Czy firmy zbyt późno chcą uruchomić proces testowania? Moim zdaniem obecnie przekonanie klientów o potrzebie testowania jest już ugruntowane. To nie są lata ’90 czy nawet 2000, gdy panowało przekonanie, że: „najważniejsze to zrobić soft, a później jakoś to będzie, będziemy poprawiać na produkcji”. Teraz każdy ma świadomość kosztów wizerunkowych, finansowych, a w niektórych branżach nawet konsekwencji prawnych, w sytuacji wystąpienia błędów produkcyjnych. Przestoje spowodowane błędami wymiernie przekładają się na zysk. Teraz firmy nie tyle zastanawiają się czy testować, ale raczej jak to zrobić możliwie niskim kosztem i bez wydłużania procesu wytwórczego w taki sposób, aby jak najbardziej skrócić tzw. „time to market”.

Michał Figiel: Warto myślę tutaj wspomnieć o ogromnym wpływie metodyk zwinnych prowadzenia projektów informatycznych, które przedefiniowały nieco podejście do testów w dynamicznym procesie wytwórczym. Agile jako taki nie uwzględnia ról jakościowych, czyli w zespole takim typowo scrumowym nie ma mowy o dedykowanej roli testera, bo zgodnie z założeniem za jakość odpowiedzialne są całe zespoły scrumowe. W Polsce wraz z mocnym wejściem Agile’a do naszej projektowej rzeczywistości, rola testów przez chwilę straciła na znaczeniu.

To co jednak obserwujemy od dłuższego czasu to fakt, że wiele firm, zarówno tych w dużej skali, jak i nawet startup-ów, zauważyło, że rozproszenie odpowiedzialności za jakość na cały zespół spowodowało pewne zagubienie tej jakości gdzieś w procesie. Nawet jeśli ktoś nie do końca o testach myślał na początku organizacji projektu to dość szybko zderza się z koniecznością powołania ról QA. Powołanie ról QA odbywa się w takich wypadkach w dość niekomfortowym momencie odbioru biznesowego czy też wskutek nieprzychylnych opinii klientów korzystających z udostępnionej aplikacji czy systemu.

W kontekście tego pytania, bardzo ciekawym też zagadnieniem są testy wydajnościowe. Trochę lekceważone i pomijane, bo w procesie tworzenia oprogramowania problemy z wydajnością bywają trudne do zauważenia. Łatwo więc przyjąć założenie „jakoś to będzie, przecież działa”. Dopiero udostępnienie softu użytkownikom weryfikuje jego rzeczywistą stabilność, co czasem kończy się awarią. Jeśli wcześniej nie symulowaliśmy zachowaniu systemu podczas działania produkcyjnego i nie wdrożyliśmy rozwiązań monitoringu infrastruktury, trudno szybko określić co powoduje niedostępność systemu.

Paradoksalnie w budowie świadomości w zakresie realnej potrzeby prowadzenia takich testów, sporo pozytywnego wydarzyło się od wybuchu trwającej pandemii. Przeniesienie znacznej części działalności firm, a także ich klientów do internetu uwypukliło potrzebę zarządzania wydajnością i dostępnością systemów IT.

Skąd Waszym zdaniem podejście „jakoś to będzie działać”? Wynika ono z braku wiedzy?

Małgorzata Sadowska: Wiedza i świadomość dot. testów jest – jak wcześniej wspomniałam – w miarę dobrze ugruntowana. Jednak tak jak powiedział Michał, proces transformacji organizacji do metodyk zwinnych wiązał się często z niezrozumieniem na czym polega „wbudowywanie jakości’ w produkt, co z kolei spowodowało rozmycie odpowiedzialności za jakość. Obecnie w procesie oferowania naszych usług zauważamy trend po stronie klientów wskazujący na powrót do budowy dedykowanych zespołów testowych.

Michał Figiel: Wydaje mi się też, że w przypadku testów wydajnościowych czy monitoringu to jest to połączenie nieświadomości zagrożeń z realnymi wyzwaniami projektowymi tj. ograniczaniem budżetów projektów w zakresie testów oraz oczekiwanie jak najszybszego uruchomienia produkcyjnego rozwijanych systemów.

Obydwoje uczestniczycie w spotkaniach z klientami, jeżeli chodzi o usługi oferowane przez SOFLAB TECHNOLOGY?

Michał Figiel: Jak najbardziej tak, staramy się w taki sposób dobierać skład rozpoznający potrzeby naszych klientów, aby finalnie wszystkie strony, czyli i klient i my były na końcu w pełni zadowolone ze współpracy.

Gosia, jakich informacji potrzebujesz od klienta, żeby przygotować ofertę wdrożeniową, albo zaproponować mu którąś z waszych usług?

Małgorzata Sadowska: Dla mnie kluczowe jest zrozumienie w jakim kontekście pracuje Klient, czyli jakie realizuje procesy, w jaki sposób ma zorganizowany proces wytwórczy i w konsekwencji z jakimi wyzwaniami się mierzy. Dzięki temu, bazując na pozyskanych informacjach oraz na własnym doświadczeniu w podobnych projektach, możemy przygotować ofertę dedykowaną dla konkretnego Klienta. Nigdy nie jest to szablonowe rozwiązanie z pudełka, ani ta sama oferta przedstawiana różnym firmom. Zawsze dostosowujemy metody i narzędzi potrzebnych do realizacji określonych celów biznesowych.

Zdarza się, że klient przychodzi i po prostu mówi: „pomóżcie, bo nie jesteśmy efektywni”. Dojrzałość klientów w rozumieniu swoich potrzeb jest bardzo różna – każdy przypadek jest na swój sposób inny – dużo zależy od typu organizacji oraz branży.

Najważniejsze jest zrozumienie celu, któremu służyć ma konkretna usługa oraz uzyskanie odpowiedzi na pytanie „Po co czegoś potrzebuje?”

Oferty pracy z

Często zadajecie klientowi pytanie po co czegoś potrzebuje?

Małgorzata Sadowska: Zawsze. Każde testy muszą mieć jasno określony cel, żeby spełniały swoją rolę. Bezcelowe jest automatyzowanie dla automatyzowania, tymczasem zaskakująco częstym celem automatyzacji testów jest uzyskanie pokrycia testów wyrażonego ekspercko oszacowaną wartością procentową.

Zdarzają się firmy, które proszą o pomoc w automatyzacji, bo same już nie są w stanie utrzymać wytworzonych skryptów. Gdy dopytujemy jak wygląda obecny stan automatyzacji, słyszymy zazwyczaj: “mamy setki skryptów automatycznych” i niewiele więcej. Klienci nie wiedzą czemu te skrypty mają służyć, więc nie są w stanie interpretować otrzymanych wyników. Bo czy 15% testów zakończonych statusem negatywnym to wynik dobry czy zły?

Tymczasem należałoby się najpierw zastanowić, co chcemy osiągnąć, jakie procesy wspierać zautomatyzowanymi testami i dopiero znając te podstawy automatyzować przypadki testowe adekwatne do postawionych celów.

Klienci też zmienili swoje podejście do sprzedaży?

Małgorzata Sadowska: Moim zdaniem tak. Coraz rzadziej Klient ma gotową wizję usługi, którą chce kupić, coraz częściej zwraca się do nas z zagadnieniem, z którym się mierzy, słusznie zakładając, że sposób jego rozwiązania warto oddać specjalistom.

Ostatnio podczas spotkania Klient podzielił się ciekawym spostrzeżeniem. Zaskoczony naszymi dogłębnymi pytaniami o specyfikę jego projektu stwierdził, że zazwyczaj przychodzą do niego ludzie chcący szybko sprzedać usługę czy produkt. Chcą szybko zarobić nie patrząc na to, jakie klient ma potrzeby. Moim zdaniem nie tędy droga. Żeby świadczyć usługi dobrze trzeba poznać potrzeby Klienta i po prostu się nimi zająć.

Michał Figiel: Tak, zwłaszcza że obserwujemy coraz niższą efektywność i znudzenie klientów sprzedażą „na siłę”. Najważniejsze jest skupienie się na rzeczywistych potrzebach klientów, którzy zwłaszcza teraz, w czasach pandemii mocniej patrzą na budżety i efektywność inwestycji. Firmy potrzebują eksperckiego podejścia, skupienia się na szybkich, ale dojrzałych efektach prac w pierwszych krokach na tzw. „zrywaniu najniżej wiszących owoców”, ale mając z tyłu głowy długoterminowy cel.

Dlatego też zawsze zastanawiamy się nad tym czego klient potrzebuje na teraz? Jaką ma strategię długookresową? Jakie narzędzie i w jakim zakresie optymalnie zaadresuje mu jego potrzeby? To jest bardzo ważne, w szczególności dla takich inicjatyw jak długofalowe projekty automatyzacji testów. Generalnie pierwsze pytanie, jakie zadajemy zawsze na pierwszych spotkaniach dot. automatyzacji testów brzmi: „Jaki jest podstawowy cel automatyzacji w organizacji? Co chcemy osiągnąć wdrożeniem automatyzacji testów??”.

Pracownicy takich firm raczej ciepło przyjmują pomysł automatyzacji?

Michał Figiel: Prawdą jest, że samo hasło automatyzacja, bez poznania definicji i zagłębienia się w temat, wywołuje niekiedy obawę – zwłaszcza tam, gdzie do tej pory realizowano powtarzalne czynności manualnie. Ludzie, szczególnie w większych i mniej zwinnych organizacjach podświadomie obawiają się nowych narzędzi. Jeśli nie ma w firmie przekonania, że warto dokonać jakichś zmian, odpowiedniej komunikacji, czy kogoś kto jest influencerem zmian wewnątrz organizacji to wdrożenie samej automatyzacji testów, czy robotyzacji procesów biznesowych jest dość trudne, a może być nawet skazane na porażkę.

Od kilku lat wszyscy jesteśmy bombardowani informacjami o erze automatyzacji i ona się faktycznie rozpoczęła, również w testach natomiast często obserwujemy że potrzeba automatyzacji testów wynika z samej chęci ich posiadania w projektach. Od razu stawiany jest ambitny cel – przykładowo: w X czasu zautomatyzujemy 100% naszych regresyjnych procesów testowych. Mało kto zastanawia się jednak, jaki wpływ na organizację (w tym m.in. development, testy, biznes) będzie miało postawienie takiego celu. Staramy się dotrzeć do tej informacji, dowiedzieć się, jaki jest rzeczywisty cel automatyzacji, kto za nią będzie odpowiedzialny, kto będzie realizował i jak zadania związane z rozwiązaniem automatyzacji testów będzie funkcjonowało szerzej w organizacji.

Zatrzymajmy się na chwilę na rynku specjalistów. Jak pięć lat temu wyglądał rynek specjalistów od automatyzacji testów? A jak wygląda rynek dzisiaj?

Małgorzata Sadowska: Rynek IT bardzo się zmienił. Dziś już chyba nie ma firmy, która nie próbowałaby przyśpieszać procesu wytwórczego i dostarczać choć części oprogramowania w sposób zwinny. Dzięki tym zmianom istotnie wzrosła rola automatyków testów.

Tymczasem jeszcze nie tak dawno praca jako specjalista automatyzacji testów interesowała niewiele osób. Automatycy byli postrzegani jako „niespełnieni developerzy”, choć tak naprawdę automatyzacja testów wymaga wysokich kompetencji technicznych i programistycznych. W efekcie dobry specjalista automatyzacji był nie tylko trudno dostępny, ale również kosztowny, co przyczyniało się do mniejszego popytu na automatyzację na rynku usług IT.

Obecnie gwałtownie wzrosło zapotrzebowanie na automatyków, dość trudno jest w krótkim czasie osiągnąć poziom doświadczonego developera testów, specjalisty, który od A do Z potrafi zautomatyzować frontend, warstwy integracyjne, web serwisy wszelakiego rodzaju, podpiąć bazę danych, a dodatkowo w pełni rozumie proces testowy i ma tzw. „testerski mindsest”.

Michał Figiel: Zgadzam się tutaj z Gosią, coraz trudniej jest znaleźć osoby, które mają doświadczenie we wdrażaniu dojrzałych i skalowalnych rozwiązań i narzędzi automatyzacji testów. Jednak tymi, nawet ważniejszymi od kompetencji technicznych cechami, na które zwracamy uwagę przy wyborze kandydatów są pracowitość, chęć podnoszenia kwalifikacji i rzeczywiste zainteresowanie i pasja do testów oprogramowania.

Mam wrażenie, że cała branża boryka się z jednym problemem – brakiem specjalistów. Z drugiej strony jest mnóstwo juniorów, którzy nie mają możliwości zdobycia doświadczenia. Jak Wy radzicie sobie z tym problemem?

Małgorzata Sadowska: To rzeczywiście jest trudna sytuacja, bo nie każdy junior ma świadomość, że napisanie trzech prostych skryptów nie wystarczy by stać się specjalistą. Dlatego w SOFLAB TECHNOLOGY już na etapie rekrutacji kładziemy duży nacisk na wybór osób, które w naszej ocenie mają predyspozycje techniczne oraz rzeczywiście wiedzą, że zdobywanie doświadczenia to kluczowy element rozwoju.

W zależności od aktualnych potrzeb oraz skali zaangażowania projektowego naszych specjalistów, juniorzy są kierowani do programu szkoleniowego, który jest przez nich realizowany pod okiem doświadczonych koleżanek i kolegów. Zdajemy sobie jednak doskonale sprawę, że nic nie zastąpi rzeczywistego zetknięcia z wyzwaniami projektowymi.

Michał Figiel: Myślę, że dla adeptów sztuki automatyzacji testów ciekawą opcją mogą być wszelakie narzędzia typu code-less. Pozwalają one zrozumieć sam w sobie proces automatyzacji testów, pewne reguły i zasady w nim występujące. Narzędzia takie jak choćby Tricentis Tosca mają niski próg wejścia. Wystarczy poznać narzędzie, stosować się do dobrych praktyk związanych z automatyzacją testów i w stosunkowo krótkim czasie przygotować testy automatyczne nawet dla zazwyczaj kłopotliwych do automatyzacji systemów klasy Salesforce czy SAP.

W kwestii automatyzacji testów to właśnie te dobre praktyki oraz wspomniany przez Gosię testerski mindset, są moim zdaniem kluczowe. Natomiast wykorzystywane narzędzie czy język programowania jest sprawą wtórną. Wiadomo, te aspekty muszą być dopasowane do specyfiki klienta czy projektu, ale to właśnie testerskie podejście sprawia, że przynoszą one wysoką wartość w projektach.

Małgorzata Sadowska. Od prawie 15 lat związana z profesjonalnymi testami oprogramowania; realizując projekty dla polskich oraz międzynarodowych korporacji, uczestniczyła we wdrożeniach oprogramowania prowadzonych metodami klasycznymi jak i zwinnymi. Jako Ekspert Testów w SOFLAB TECHNOLOGY coach-uje i wspiera metodycznie zespoły wdrożeniowe. Realizuje warsztaty z zakresu metodyk wytwórczych oprogramowania i zapewniania jakości oprogramowania.

Michał Figiel. Ponad 10 lat doświadczenia w IT, 3 lata w roli konsultanta i koordynatora testów technicznych – automatyzacji i wydajności w projektach dla branży: IT, teleco, bankowości i media. Od trzech lat w roli Kierownika Działu Testów Technicznych SOFLAB TECHNOLOGY zarządza 30 osobowym zespołem konsultantów i specjalistów z obszarów: automatyzacja testów, testy wydajnościowe i monitoring środowisk, oraz wdrożenia rozwiązań Atlassian i narzędzi wsparcia testów.