Dlaczego Software Testing as a Service?

Artykuły eksperckie | 29.08.2018 | Czas czytania: 8 minut

Testowanie staje się stałym elementem większości procesów tworzenia oprogramowania, jednak dla samych firm produkujących software, jest to często element znajdujący się poza głównym obszarem zainteresowania. Nie ma w tym nic dziwnego, ponieważ jeżeli ktoś chce być najlepszy w tym co robi (w tym wypadku jest to tworzenie oprogramowania), niekonieczne chce lub może skupiać się na innych aktywnościach. Zazwyczaj więc zadania, które niekoniecznie są głównym trzonem działalności biznesowej danej firmy, oddelegowywane są poza jej strukturę, w celu obniżenia kosztów i usprawnienia działania.

Od lat pracuję jako tester i bardzo często spotykam się z koniecznością usprawiedliwiania kosztów wykonania testów. O ile wykonanie prostych testów automatycznych czy manualnych stało się pewnego rodzaju standardem, to bardziej skomplikowane testy i aktywności stają się czymś, co trudniej jest ekonomicznie uzasadnić, przez co spychane są na boczny tor w projektach. Oczywiście nie twierdzę, że tak jest zawsze, jednak mając doświadczenie w wielu projektach o mniejszej skali, obserwuję często właśnie takie „rzemieślnicze” podejście do zarządzania.

Takie zarządzanie procesem tworzenia oprogramowania opiera się na kilku uzdolnionych „testerach-rzemieślnikach”, od których zależy cały proces testowy. Nie jest to jednoznacznie złe, jednak powoduje, że wszystkie aktywności testowe są obsługiwane przez daną grupę testerów, którzy wykonują testy manualne, automatyzacje czy testy bezpieczeństwa, albo wydajności, ale także zarządzają wszystkimi testami. Zasadnicze pytanie brzmi, czy tak mały zespół posiada wszystkie wymagane kompetencje? Zwłaszcza, że w projekcie w końcu prawdopodobnie pojawi się moment, w którym niezbędni będą wysoko wyspecjalizowani specjaliści od testów wydajności, bezpieczeństwa czy inni eksperci, których utrzymywanie przez cały czas jest zwyczajnie nieefektywne pod względem kosztów.

Dowiedz sie więcej o usługach Quality assurance i testów oprogramowania w JCommerce.

Przestoje i „górki” w projekcie

Innym problemem jest fakt, że ilość i rodzaj zadań w trakcie trwania projektu nie są stałe. Założenie, że trzech pracowników będzie miało zawsze taką samą ilość pracy przez całość trwania projektu, jest błędne. Zarówno przestoje, jak i tak zwane „górki” w projekcie są zjawiskami zupełnie naturalnymi.

W pierwszym przypadku, można założyć, że pracownicy ze zbyt małą ilością zadań w danym momencie zajmą się innymi aktywnościami, na które nie ma czasu w innych momentach projektu, takie jak np.: zadania porządkowe. Na pierwszy rzut oka ma to sens, pytanie tylko, czy aktywności zostawione na taki moment, naprawdę są konieczne do wykonania. Dużo bardziej właściwe jest zastosowanie dobrych praktyk, które nie będą dopuszczać do sytuacji, kiedy takie działania będą w ogóle konieczne. Oczywiście pozostają jeszcze szkolenia i samodoskonalenie. Tę kwestię pozostawiam już każdej firmie do rozpatrzenia we własnym zakresie.

Dużo bardziej kłopotliwe są górki, ponieważ posiadając np.: trzech testerów w projekcie, nasze zasoby są siłą rzeczy ograniczone. Załóżmy, że nasz zespół testów oczekiwał na zadania, które miały być dostarczone do wykonania. Wykonał odpowiednie przygotowania, a także wszystkie inne aktywności. Niestety etap projektu poprzedzający testy się przedłużył i okazało się, że testy zaplanowane na dwa tygodnie należy wykonać w tydzień, ponieważ termin jest absolutnie nie do przesunięcia. W związku z tym trzech pracowników, którymi dysponujemy, muszą wykonać pracę dla sześciu osób.

Jakie w takiej sytuacji mamy możliwości? Możemy przesunąć testerów z innych, mniej pilnych projektów, pod warunkiem rzecz jasna, że jest w ogóle taka możliwość. Kolejnym rozwiązaniem tej sytuacji są nadgodziny. Jednak w tym przypadku skala takich nadgodzin byłaby bardzo duża, zdecydowanie przekracza bowiem 50% czasu pracy. Nie tylko zwiększy to koszty, gdyż praca w nadgodzinach oznacza wyższe stawki, ale również spowoduje zmęczenie testerów. I tu musimy liczyć się z tym, że zmęczony tester nie będzie pracował z taką samą efektywnością, jak wypoczęty pracownik. Oznacza to, że nawet jeśli nasz zespół będzie próbował zrealizować wszystkie zadania w terminie, nie daje nam to gwarancji odpowiedniego wyniku.

Potrzebujesz wsparcia w obszarze testów oprogramowania?

 

Podejście przemysłowe, a nie rzemieślnicze

Konieczna jest więc zmiana sposobu myślenia, o tym jak zarządzamy zespołem testowym, a dokładnie spojrzenie na człowieka i jego umiejętności. Firma w modelu rzemieślniczym, potrzebuje najzdolniejszego człowieka, który ma wszystkie konieczne umiejętności, aby wykonać prace w projekcie na odpowiednim poziomie. Jednak w realiach biznesowych ciężko jest taki model skutecznie realizować.

Trzeba pamiętać, że specjalista posiadający wszystkie kompetencje ze wszystkimi specjalizacjami, jakie są konieczne do pokrycia zapotrzebowania na testy w danym projekcie, prawdopodobnie nie istnieje. Nawet tester z wieloletnim doświadczeniem posiada jedynie te kompetencje i umiejętności, które ukształtowane zostały przez projekty, w których do tej pory uczestniczył. Przykładowo tester z 15-letnim stażem, nawet jeżeli 10 lat temu był wybitym programistą testów, jeśli nie wykonywał ich w tym czasie, tak naprawdę nie posiada już kompetencji w tym zakresie.

W tradycyjnym, rzemieślniczym podejściu mamy dostęp tylko do konkretnych umiejętności danego testera, czy danej grupy testerów, dodatkowo nie zawsze w odpowiednim momencie.

Innym problemem jest to, że wyzwania związane z rozwojem oprogramowania stają się coraz większe. Wyjątkowo trudnym zadaniem dla testerów jest więc bycie specjalistą w każdej dziedzinie. Ktoś kto doskonale wykonuje testy web, niekoniecznie będzie również specjalistą w zakresie testów Big Data. Oczywiście posiadając wiedzę na temat podstaw, dobry tester powinien poradzić sobie w każdym projekcie – jednak należy zadać sobie pytanie o efektywność jego pracy. Jedną z metod rozwiązania tego typu problemów jest testing center of excellence, czyli wyspecjalizowane działy, które zajmują się tylko testami, przeprowadzając je w formie usługi dla pozostałych działów firmy. Jest to jednak efektywne tylko w sytuacji, jeśli cały potencjał takiego działu jest rzeczywiście wykorzystywany, czyli firma musi posiadać odpowiednią wielkość i portfel projektów, które będą w ten sposób obsługiwane. W przeciwnym wypadku taki dział zamienia się w centrum kosztów.

Sposobem na rozwiązanie tego problemu dla firm mniejszych, lub nieposiadających wystarczającej liczby zróżnicowanych projektów rozwoju oprogramowania, jest Software Testing as a Service.

Czym jest STaaS

Software Testing as a Service jest modelem outsourcingu, w którym zamiast wynajmowania konkretnych specjalistów, outsourcowane jest wykonanie konkretnych zadań. Oznacza to, że usługobiorca nie korzysta z ograniczonej puli kompetencji danego pracownika lub pracowników, ale z chmury ich kwalifikacji. Unikamy w ten sposób pułapki, w której przykładowo tester manualny na poziomie seniora otrzymuje zadanie wykonania testów automatycznych, które wymagają umiejętności na poziomie juniora testów automatycznych, których jednak nasz tester manualny nie posiada. Jest to zdecydowanie nieefektywne wykorzystanie potencjału pracownika.

Testy w tym modelu są dostarczane na żądanie, czyli w momencie, kiedy jest taka potrzeba, powinny być skalowalne, posiadać wysoki poziom niezależności, a także nie obciążać usługobiorcy kosztami związanymi z narzędziami, sprzętem, oprogramowaniem, szkoleniem pracowników czy budowaniem środowisk testowych. Z założenia powszechne jest również wykorzystywanie w pracy narzędzi chmurowych.

Dzięki Software Testing as a Service możemy dostarczać wszystkie usługi związane z testowaniem: od testów manualnych, przez automatyczne, wydajnościowe, penetracyjne, czy doskonalenie procesu testowego, a także prowadzenie szkoleń dla pracowników klienta.

STaaS – jak to działa?

Sama forma świadczenia usługi z założenia powinna być jak najbardziej „bezproblemowa” dla klienta. Po zapytaniu o możliwość realizacji konkretnego zadania, podpisuje się odpowiednią umowę, oczywiście wcześniej ustalając szczegóły usługi. Następnie klient powinien przekazać wszystkie dokumenty, dostępy i inne artefakty konieczne do jej wykonania. Teoretycznie, w tym momencie jego rola powinna się skończyć. W praktyce, wygląda to trochę inaczej, gdyż Software Testing as a Service to wciąż klasyczne testy, więc wykonanie usługi nie może odbywać się bez jakiegokolwiek kontaktu między klientem a dostawcą usługi. Potrzebna jest sprawna komunikacja i wymiana wiedzy, aby dostarczana usługa była jak najwyższej jakości. Usługa STaaS finalizowana jest poprzez przedstawienie wyników w postaci raportu.

jpro-jcommerce-dlaczego-staas-in-text

Powyższy scenariusz jest oczywiście dość dużym uproszczeniem, jednak ideą Software Testing as a Service jest odciążenie usługobiorcy, tak żeby była to najbardziej wygodna i „bezproblemowa” forma współpracy.

Podsumowanie

Świat IT się zmienia, testowanie musi się zmieniać razem z nim. Nie jest możliwe, żeby stary model pracy w postaci testera rzemieślnika jako jednostki wykonującej testy, był czymś, co rozwiąże nasze problemy. STaaS chce być elastyczne, efektywne względem kosztów, a także dostarczać najlepsze rozwiązania, dostępne dla każdej firmy niezależnie od wielkości. Jest to duże wyzwanie, ale ostateczny efekt jest tego warty.


Już wkrótce pojawi się druga część tego artykułu. Aby być na bieżąco z nowymi publikacjami, zachęcamy do zapisania się do Bazy Wiedzy JPro.

Autorem wpisu jest

Leszek Zieliński, JCommerce

Quality Assurance Technical Solution Manager

Od 2011 roku realizuje i kieruje projektami QA. Ekspert w obszarze testów manualnych, zarządzaniu testami, doskonaleniu procesów testowych, mający również  doświadczenie w testach automatycznych. Posiada certyfikat ISTQB Full Advanced Tester. Zafascynowany metodologią Rapid Software Testing, jak i podejściem Software Testing as a Service. Absolwent Politechniki Śląskiej w Gliwicach. Po godzinach działacz społeczny.

Komentarze

  • Aktualnie brak komentarzy.

Skontaktuj się z nami