TABLE OF CONTENTS:
Nasz Klient – jedna z największych instytucji finansowych w Polsce, stworzył aplikację bankową dla klienta indywidualnego. Przed wdrożeniem konieczne było szybkie testowanie oprogramowania Klienta na wielu przeglądarkach oraz w wersji mobilnej. Dotychczas testowanie aplikacji i ich nowych funkcjonalności odbywały się manualnie. Postanowiliśmy zautomatyzować ten proces, żeby przyspieszyć wdrożenie nowego produktu klienta na rynek.
Aby testowanie automatyczne mogło przynieść oczekiwane efekty, zaczęliśmy od przeprowadzenia prac, które są niezbędne do skutecznego wykonania tego typu projektu, czyli:
Gdy zdefiniowaliśmy już zadania, które będziemy chcieli realizować, określiliśmy kamienie milowe i przystąpiliśmy do uruchomienia działania. Nasz projekt objął 22 sprinty w 3-tygodniowych cyklach.
W ramach każdego ze sprintów cały czas kontrolowaliśmy metryki, m.in.:
Dodatkowe metryki, które stosowaliśmy to:
W ramach każdego sprintu przygotowywaliśmy demo danej funkcjonalności. Dzięki temu mieliśmy większą kontrolę nad tym, czy nasza praca idzie w dobrym kierunku, a klient na bieżąco obserwował postęp prac.
Tego typu podejście zwykle stosuje się przy prac nad oprogramowaniem krytycznym, tzw. safety-critical, od którego często zależy ludzkie życie.
Opowiadaliśmy o tym podczas jednego z naszych webinarów. Dobre praktyki z tworzenia oprogramowania o wysokim stopniu bezpieczeństwa przydają się w każdym projekcie. Obejrzyj nagranie!
Poza automatyzacją testów, które dotychczas zespół klienta realizował ręcznie, przygotowaliśmy metodykę tworzenia scenariuszy, procesy pisania testów automatycznych i bibliotekę zautomatyzowanych scenariuszy testowych zgodnie z podejściem BDD czyli Behavior-Driven Development.
W tej metodyce, przy tworzeniu oprogramowania opisujemy je z perspektywy potencjalnego użytkownika. Używamy do tego języka Gherkin oraz słów kluczowych: Given – When – Then. Bardzo usprawnia to komunikacją na linii Biznes – Zespół Deweloperski , ponieważ eliminuje problemy z interpretacją wymagań biznesowych przez osoby techniczne.
Gdy opracowaliśmy już niezbędną dokumentację przeszliśmy do tego, co było głównym celem projektu – stworzenia testów automatycznych aplikacji (zarówno mobilnej jak i webowej).
W pierwszym kroku stworzyliśmy kod testu automatycznego zgodnie z przyjętymi wcześniej regułami „czystego kodu”. Taki sposób tworzenia kodu, eliminuje znaczącą liczbę zmian, które musiałyby być wykonane na etapie jego refaktorowania czy review.
W kolejnym kroku test automatyczny był przesyłany do pierwszego review. Po jego realizacji i poprawkach kolejnego przeglądu dokonywała już osoba ze stażem seniorskim.
Przyjęliśmy, że cały proces automatyzacji testu powinien zakończyć się jego uruchomieniem na środowisku testowym oraz wynikiem z jego uruchomienia. Był to dla nas niepodważalny dowód działania testu i realizacji jego celu. Taki wynik był weryfikowany przez osobę odpowiedzialną za utrzymanie testów automatycznych. Gdy prawidłowe działanie testu zostało potwierdzone wynikiem, został on ostatecznie dodany do cyklu testowego.
Ze względu na dużą liczbę testów automatycznych i konfiguracji do przetestowania, czas w którym są się one w stanie wykonać, zaczął odgrywać kluczową rolę.
Aby maksymalnie skrócić czas realizacji testów, postanowiliśmy tak przygotować środowisko, aby testy dla każdej z konfiguracji mogły być wykonywane niezależnie. Użyliśmy więc maszyn wirtualnych i fizycznych. Na tych pierwszych użyliśmy obrazów dockerowych dostarczonych przez Katalona (odpowiednio zmodyfikowanych na nasze potrzeby), a na drugich bezpośrednio przez aplikację Katalon.
Nie mogliśmy pominąć testów na maszynach fizycznych, ponieważ chcieliśmy sprawdzić działanie aplikacji zarówno w Internet Explorer jak i na urządzeniach mobilnych.
Ta metryka umożliwia ocenę poziomu pokrycia aplikacji przez testy oraz wskazania funkcjonalności, gdzie tego pokrycia brakuje. Jest to kluczowa metryka z punktu widzenia biznesu, bo częściowo odpowiada na pytanie – jak bardzo przetestowana jest aplikacja?
Jest to metryka umożliwiająca ocenę postępu prac oraz oszacowanie pozostałego zakresu. Informacja ta jest szczególnie ważna z punktu widzenia Project Managera.
Poza powyższymi wskaźnikami sprawdzaliśmy również trend zmian w metrykach. Pozwoliło nam to na ocenę projektu w dłuższej perspektywie, sprawdzenie zgodności postępu prac względem harmonogramu oraz wykrycie ewentualnych problemów, które mogły się pojawić.
Po każdym z trzytygodniowych sprintów na cyklicznym spotkaniu z klientem prezentowaliśmy demo z wykonanego etapu oraz status realizowanych zadań. Jest to dobra praktyka, nie tylko w projektach związanych z testowaniem. Zespołowi pomaga lepiej kontrolować postęp, a klientowi daje czytelną i rzetelną informację o efektach.
Automatyzacja testów znacząco przyspiesza proces wdrażania na rynek nowego oprogramowania.
Krótszy Time to Market to szybszy zysk. A przecież o to chodzi.
W ramach projektu zrealizowaliśmy:
Dodatkowo klient w ramach współpracy, poza akceleracją testów otrzymał materiały, które jego zespół może wykorzystać w pracy nad kolejnymi produktami. W dokumentacji projektowej znalazły się szczegółowe dokumenty na temat tego:
Solwit jest wieloletnim, Platynowym Partnerem International Software Testing Qualifications Board, dlatego każdą usługę testowania oprogramowania realizujemy zgodnie z surowymi normami, które wyznacza.
Według raportów Computerworld Top 200, od lat zajmujemy miejsca w pierwszej trójce największych dostawców usług testerskich w Polsce. Nasi testerzy dysponują certyfikatami ISTQB na poziomie Advanced & Foundation oraz kompetencjami trenerskimi. Dlatego we współpracy z klientem zawsze nadzorujemy przebieg wdrażanych procesów oraz planujemy zadania, również te dla zespołu klienta. Istotnym jest dla nas również, żeby komunikować się bezpośrednio z Właścicielem Biznesowym po stronie klienta na etapie tworzenia scenariuszy i ustalania priorytetów.
Technologie wykorzystane w projekcie:
