Większość nowoczesnych firm produkcyjnych korzysta z systemów PLM do dokumentowania danych produktowych i zarządzania nimi. Systemy PLM wspierają wiele kluczowych operacji w firmie: przede wszystkim administrowanie plikami CAD, dokumentami oraz danymi związanymi z zarządzaniem zmianą. Wszystkie te zależne od siebie funkcje są stale aktualizowane o nowe wymagania. Mały błąd, który pojawia się w jednym obszarze, może wpłynąć negatywnie na cały proces. Dlatego weryfikacja i kontrola jakości oprogramowania jest tak istotna. W poniższym artykule przedstawimy korzyści wynikające z testowania oprogramowania PLM.
Testowanie oprogramowania PLM okiem specjalisty
“Włączenie do projektu specjalistów QA to tylko dodatkowy koszt” – niestety często spotykamy się z taką opinią wśród osób odpowiedzialnych za wdrożenie w firmach systemu PLM. Testowanie oprogramowania bywa nadal traktowane jako przykra konieczność. Mało kto zwraca uwagę na realne korzyści wynikające z tego procesu. Tymczasem podczas wdrożenia czy developmentu oprogramowania PLM brak testów jest tylko złudną oszczędnością.
Customizacja – odpowiedź na specyficzne potrzeby organizacji
PLM to proces zarządzania całym cyklem życia produktu, od jego opracowania i wprowadzenia na rynek, poprzez rozwój, dojrzałość i schyłek. Wdrożenie systemu PLM jest inwestycją, która ma na celu przełamanie barier organizacyjnych. Pozwala zespołom projektowym na szybszą i dokładniejszą pracę oraz sprawną wymianę informacji dotyczących aktualnego stanu realizacji projektu.
Producenci systemów PLM ręczą, że ich oprogramowanie PLM (OOTB – out of the box) będzie gotowe do użytku natychmiast po zainstalowaniu. I tak właśnie jest, natomiast bez wstępnej, podstawowej konfiguracji, taki system nie ułatwi i nie zoptymalizuje pracy w organizacji wdrażającej system PLM.
“W rzeczywistości takie wdrożenie oparte o skonfigurowanie systemu powinno trwać od kilku tygodni do kilku miesięcy dla firm sklasyfikowanych jako SMB (Small and Medium-Sized Business). Wiąże się to z przeprowadzeniem kilku warsztatów w celu ustalenia aspektów związanych z konfiguracją modelu danych, dostępów użytkowników na podstawie zdefiniowanych ról, oraz dostosowaniem cyfrowych procesów biznesowych do niuansów panujących w firmie. Dla porównania, w przypadku firm klasy Enterprise, realizacja wymagań i wdrożenie systemu PLM obudowanego w paradygmat cyfrowego wątku (Digital Thread), wiąże się z kilkuletnim programem wdrożeniowym.”
-wyjaśnia Leszek Zborowski, Business Unit Manager w TT PSC, odpowiedzialny za obszar PLM. Jeszcze dalej idącą zmianą jest customizacja, obejmująca wszystko poza konfiguracją i wymagająca modyfikacji lub rozszerzenia kodu źródłowego (nowe akcje dla użytkowników lub integracja z innymi używanymi przez firmę systemami, które współpracują z PLM). Więcej na temat różnic związanych z implementacją systemów PLM przeczytasz w artykule:
Customizacja a testowanie oprogramowania PLM
Weryfikowanie wszystkich wprowadzanych zmian jest kluczowe dla poprawnego działania całego systemu. Testowanie oprogramowania PLM służy sprawdzeniu jego prawidłowego działania oraz zebraniu kluczowych informacji na jego temat. Im większa zgodność pomiędzy testami weryfikacyjnymi i walidacyjnymi, tym lepsza będzie jakość aplikacji i tym samym mniejsze ryzyko wystąpienia błędów, usterek i przestojów w przyszłości. A jeśli już wystąpi awaria, dzięki użyciu gotowego zestawu testów sprawdzających podstawowe funkcjonalności systemu można upewnić się, że po naprawie system działa bez zastrzeżeń.
W ramach podstawowych czynności testerskich przygotowujemy test plany i opisujemy kluczowe scenariusze. Wykonujemy testy, dokumentujemy ich rezultaty oraz raportujemy błędy. Dzięki dobrze zorganizowanemu procesowi testowania niedoskonałości systemu wykrywane są na jak najwcześniejszym etapie tworzenia oprogramowania. Co za tym idzie – korekta defektów czy usuwanie niespójności w dokumentacji wiąże się z relatywnie niskim nakładem pracy i zasobów. Dzięki temu w znaczący sposób optymalizujemy koszty.
Dlaczego testowanie systemów PLM jest tak ważne?
Systemy PLM to złożone oprogramowania, składające się z wielu zależnych od siebie modułów. Aby zagwarantować jakość oczekiwaną przez klienta, testy muszą być podzielone na kilka poziomów, takich jak testy:
- jednostkowe – weryfikują każdą metodę, funkcję, klasę, moduł czy element;
- integracyjne modułów – kontrolują, czy komponenty współdziałają ze sobą poprawnie;
- systemowe – badają, czy system działa jako całość, na tym poziomie przeprowadzane są testy e2e (end-to-end), które sprawdzają zgodność działania oprogramowania z wymaganiami i specyfikacją.
Przetestowanie zarówno poszczególnych części, jak i całości oprogramowania, jest niezbędne, aby:
- skontrolować, czy wszystko działa poprawnie;
- usprawnić miejsca, w których testy wykazały niedoskonałości;
- przewidzieć możliwość wystąpienia kłopotów w przyszłości.
Systemy PLM to setki tysięcy linii kodu, opracowanych przez wielu programistów, często pracujących w rozproszonych zespołach. Ten kod jest używany przez wiele różnych komponentów. Cechuje go złożona komunikacja i wielopoziomowy system kompilacji. Dlatego kluczem do sukcesu są testy, które gwarantują, że mimo zawiłych procesów, system działa, jak należy. Znacząco zmniejsza to ryzyko wystąpienia w przyszłości potencjalnych błędów oraz konieczność ich naprawy (im później odkryty błąd, tym większy koszt jego usunięcia).
Testowanie a kontrola dostępu i bezpieczeństwo danych
W systemach PLM występuje bardzo rozbudowana organizacja kontroli dostępu (access control rules). Do innych danych będzie miał dostęp inżynier, do innych pracownik produkcji, a jeszcze do innych menadżerowie różnych szczebli. Zatem to istotne, by bardzo dokładnie sprawdzać dostępy w ramach testowania całego procesu PLM, aby każdy widział wyłącznie te dane, do których jest uprawniony. Systemy PLM zapewniają bardzo zaawansowaną strukturę kontroli dostępu, ale aby wszystko działało prawidłowo, niezbędne jest zaangażowanie zespołu testerów.
Performance może powodować kłopoty. Przetestuj go!
W ramach testowania systemów PLM niezbędne jest też sprawdzenie niefunkcjonalnych wymagań naszego systemu. Ważne, aby nagły wzrost liczby użytkowników bądź też akcji nie spowodował niedostępności systemu, a co za tym idzie, konkretnych strat finansowych dla firmy. W ramach testów wydajności systemu bada się, jak długo system wykonuje poszczególne akcje, w szczególności przy kluczowych czy długotrwałych zadaniach.
Przykładowo w ramach badania performance’u możemy sprawdzić, jak przebiega operacja logowania dla różnej liczby użytkowników. Wykorzystajmy do tego kod z testów automatycznych logowania, napisany wcześniej w Selenium, a symulację różnej liczby logujących się userów uzyskamy dzięki użyciu JMetera.
Wyniki takich testów obciążeniowych systemu PLM możemy zwizualizować wysyłając uzyskane dane z JMetera do InfluxDB (to zestaw narzędzi dla szeregów czasowych), Chronografu (narzędzie zapewnia dashboard dla danych z InfluxDB) oraz Grafany (aplikacji do analizy i interaktywnej wizualizacji). W ten sposób zaprezentujemy liczbę logowań userów w poszczególnych sekundach, dla przykładowo ostatnich 5 minut.
Uzyskane w wyniku takich testów dane mogą być pomocne także przy podejmowaniu decyzji dotyczących infrastruktury systemu PLM. Dzięki temu istnieje możliwość przekonania się, ilu użytkowników może pracować na jednym serwerze, czy jak można skalować liczbę node’ów, w zależności od liczby użytkowników.
Testowanie oprogamowania PLM w ramach integracji systemów biznesowych
Oprogramowanie PLM zazwyczaj nie działa samodzielnie, ale współpracuje z innymi systemami – otrzymuje od nich dane wejściowe czy akcje, a następnie przesyła je dalej. W ten sposób, przy użyciu dedykowanej architektury i technologii integracyjnych, tworzymy integracje pomiędzy systemami.
PLM, ERP, IoT
Przykładem może być integracja rozwiązania PLM z SAP (przykład systemu ERP pozwalającego na kierowanie, planowanie, zarządzanie i kontrolowanie wszystkich działań w firmie). Jest ona kluczowa dla pełnego wykorzystania funkcji PLM. Warto wspomnieć też o integracji PLM z systemami IoT (na przykładzie z rozwiązaniami PTC, integracja pomiędzy systemem Windchill a platformą ThingWorx). Platformy Internetu Rzeczy zostały stworzone, aby łączyć, agregować, analizować i wyświetlać dane – począwszy od urządzeń rozsianych po całym świecie, maszyn na linii produkcyjnej w fabryce, poprzez inne systemy korporacyjne. Bardzo często systemy IoT oraz PLM wspierają się nawzajem.
Integracja, która często spędza sen z powiek całym zespołom
Sprawdzenie czy integracje innych systemów biznesowych z platformą PLM działają bez zarzutu to zadanie właśnie dla działu testerskiego. Współdziałanie wielu systemów może przysparzać problemów, a naprawa defektów związanych z integracją jest kluczowa dla poprawnego działania oprogramowania jako całości. To, czy systemy zostały zespolone ze sobą poprawnie, możemy zweryfikować wykonując testy typu end – to – end (które omówimy bardziej szczegółowo w dalszej części artykułu). Dzięki nim możliwe jest sprawdzenie, jak system PLM zachowuje się od samego początku do końca pracy, włączając w to też działanie systemów współpracujących.
Przeprowadzenie upgrade’u tak, by nie popsuł już działającego systemu
Tempo rozwoju technologii oraz ilość nowych rozwiązań informatycznych sprawiają, że upgrade systemu PLM z czasem bywa nieunikniony. Podczas takiego procesu niezbędne są systematyczne testy. Stanowią one gwarancję, że po aktualizacji wszystko zadziała poprawnie. Przykładem może być ostatni upgrade systemu Windchill z wersji 11.0 do 12.0. Po przeprowadzeniu tak istotnej aktualizacji konieczne jest przetestowanie systemu jako całości i sprawdzenie, czy nie pojawiły się żadne nowe defekty. Jako że system PLM jest mocno rozbudowany, można przeprowadzić testy manualnie (zajmie to sporo czasu), posiłkując się zestawem testowym regresji, ale o wiele szybciej i efektywniej jest je zautomatyzować.
Continuous integration i contiunous delivery na straży efektywnego deploymentu
Zmiany w systemie PLM dodawane są nie tylko przy okazji upgrade’u. Przy niektórych projektach to codzienność towarzysząca rozwojowi kodu z nowymi funkcjonalnościami (w ramach continuous integration and continuous delivery). W takich sytuacjach warto wykorzystać automatyzację przy użyciu narzędzia typu Jenkins. CI/CD pipeline automatyzuje cały proces dostarczania oprogramowania. Buduje kod, uruchamia testy i wdraża nową wersję aplikacji. Zautomatyzowane potoki usuwają błędy, jakie mogłyby powstać, gdyby proces deploymentu wykonywany był manualnie, a programista czy specjalista devops przez przypadek nie wykonał jakiejś niezbędnej czynności.
Wśród wielu etapów testów wykonywanych przez narzędzie Jenkins (pipeline), znajduje się sprawdzanie całości oprogramowania na wszystkich poziomach testów (jednostkowe, integracyjne modułów, systemowe). Jeśli więc nowości spowodują jakiekolwiek defekty systemu PLM, będzie to widoczne w jenkinsowym raporcie z regresji. Można zatem szybko podjąć kroki naprawcze. Im szybciej wykryty błąd w oprogramowaniu, tym mniejszy koszt jego naprawy.
Korzyści z testowania oprogramowania PLM
Dzięki różnym rodzajom testów, jakie wykonujemy w ramach rozwoju oprogramowania PLM, klient uzyskuje szereg korzyści, które w późniejszym czasie przekładają się na zyski dla firmy.
1) Identyfikacja ryzyka
W ramach aktywności testowych istnieje możliwość identyfikacji i zarządzania ryzykiem. Dzięki temu klient jest bogatszy o wiedzę, co w przyszłości może przysporzyć kłopotów w systemie PLM i co warto zrobić, by ominąć potencjalne pułapki lub efektywnie poradzić sobie z kłopotem. PLM, podobnie jak inne systemy klasy Enterprise, są mocno rozbudowane i skomplikowane, zatem i ryzyko błędu jest wysokie. Odpowiednie przygotowanie pozwoli zapobiec takiej sytuacji lub szybko zniwelować jej skutki.
2) Testowanie oprogramowania PLM a spełnienie oczekiwań klienta
Głównym zadaniem wszystkich czynności testerskich jest poprawa jakości oprogramowania. To nie tylko znacząca liczba napisanych przypadków, wykonanych testów czy znalezionych błędów, lecz określenie stopnia, w jakim dany moduł lub proces spełnia potrzeby i oczekiwania klienta. A to przecież najważniejsze w całym procesie wytwarzania oprogramowania. Dodatkowo w ten sposób znacząco ograniczyć można występowanie tzw. change requestów, które zgłasza klient, gdy dochodzi do wniosku, że coś powinno działać inaczej, mieć więcej funkcjonalności itp.
3) Identyfikacja niezgodności i braków
Należy rozróżnić dwie kwestie – czym jest system PLM oraz czy działa tak, jak klient tego oczekiwał. Sprawdzanie wszystkich wymagań krok po kroku, wyłapywanie luk czy niezgodności między nimi – to wszystko jest osiągalne w procesie testowania, podczas m.in. pisania przypadków testowych. Doświadczony tester wychwyci wszelkie niezgodności i braki, które są weryfikowane, a następnie uzupełniane lub zmieniane.
4) Zgodność z wymaganymi przepisami prawnymi
Dzięki testom łatwiej osiągnąć zgodność w zakresie bezpieczeństwa. W przemyśle, zwłaszcza w branżach kluczowych dla życia i zdrowia ludzkiego, istnieje mnóstwo regulacji prawnych (unijnych, krajowych, jakościowych) oraz dobrych praktyk, które muszą być spełnione, aby system był uznany jako bezpieczny i mógł być dopuszczony do używania.
5) Oszczędność kosztów
Dzięki dobrze zorganizowanemu procesowi testowania oprogramowania PLM błędy są identyfikowane na wczesnym etapie wytwarzania oprogramowania. Poprawa defektu czy usunięcie niespójności w dokumentacji niesie za sobą stosunkowo niskie nakłady sił i środków. Każdy projekt związany z wytwarzaniem oprogramowania można zrealizować bez testów. Wiąże się to z ryzykiem biznesowym, jakie jest w stanie podjąć dana organizacja. Niestety bardzo prawdopodobny jest wtedy scenariusz związany z niezgodnościami systemu z oczekiwaniami klienta, a koszty naprawy błędów spowodują nieopłacalność takiego podejścia. Dlatego warto mieć na uwadze, że im później odkryty zostanie błąd, tym większe środki są potrzebne na jego usunięcie.
Cały proces testowania oprogramowania PLM jest zorganizowany w taki sposób, aby klient otrzymywał na bieżąco informacje, na temat tego, co i dlaczego się dzieje oraz jak można zapobiec potencjalnym problemom. Klient ma świadomość, które elementy będą testowane w jakim czasie. Ponadto zostają określone tzw. kamienie milowe projektu. Kontrahent wie również, kiedy może spodziewać się zakończenia całego procesu i możliwości oddania systemu PLM do użytku. Zatem transparentność i mierzalność procesów IT na każdym etapie to ważny z punktu widzenia klienta aspekt.
6) Wzrost zaufania pomiędzy klientem, a dostawcą systemu
Z transparentnością ściśle wiąże się kwestia zaufania. Skoro klient wie, co i dlaczego dzieje się w ramach procesu wytwarzania oprogramowania, a wszystkie kroki są z nim konsultowane, to finalnie zaufanie do rozwiązania PLM, jak i to dostawcy rośnie. Dobre relacje i wzajemne zaufanie stanowią podstawę owocnej współpracy, której efektem jest wartościowy produkt, który spełnia oczekiwania klienta.
Automatyzacja i ciągłe testowanie przy współpracy z biznesem
Ponieważ systemy PLM są bardzo rozbudowane, przetestowanie manualnie absolutnie wszystkich elementów trwałoby długo i wymagałoby zaangażowania dużego zespołu testerów. Tutaj z pomocą przychodzi automatyzacja. Pokrycie najbardziej podatnych na błędy ścieżek oraz najczęściej wykonywanych czynności przez użytkowników systemu pozwala na uniknięcie krytycznych błędów.
Bardzo dobrze sprawdza się tu podejście Behavior-Driven Development (BDD): testy systemu PLM warto napisać z wykorzystaniem narzędzi Cucumber + Java. Stosując stosunkowo łatwą składnię języka Gherkin, gdzie mamy: “given” (początkowy kontekst), “when” (opis występującego zdarzenia) oraz “then” (potwierdzenie wystąpienia oczekiwanego rezultatu). Dzięki wykorzystaniu procesu BDD do tworzenia przypadków testowych, wzrasta zaufanie klienta do systemu. Opisanie przypadku użycia z perspektywy użytkownika końcowego pomaga zrozumieć potrzeby klienta. Dzięki temu dostaje on to, czego potrzebuje i za co zapłacił. System PLM w ten sposób przetestowany dostarcza realną wartość biznesową.
W przypadku automatyzacji testów regresji, które wykonywane są co pewien czas, testerzy nie muszą od nowa wykonywać wciąż tych samych, powtarzalnych operacji. Szczegółowe raporty z wynikami wykonania testów dostarczają konkretnych informacji, na temat tego, co przestało działać. Co więcej – testy wykonywane są za każdym razem w identyczny sposób, co eliminuje możliwe pomyłki (w przypadku, gdyby oprogramowanie było testowane manualnie).
Oszczędność czasu w dłuższej perspektywie przekłada się na redukcję kosztów. Testy automatyczne są bowiem wykonywane o wiele szybciej niż manualne i nie wymagają dodatkowego nakładu pracy wielu testerów jak podczas żmudnego procesu testowania manualnego. Zestaw testów można uruchomić wieczorem, a następnego dnia wyciągać wnioski.
Doskonałym przykładem automatycznego testowania oprogramowania PLM jest nie tylko regresja, ale też smoke czy sanity testy. Te testy wstępnie sprawdzają, czy aplikacja/środowisko w ogóle nadaje się do głębszej eksploracji przez testerów. Dzięki testom automatycznym otrzymujemy informacje czy system jest gotowy do dokładnego testowania, nie angażując w to pracowników.
Sprawdzamy system od początku do końca, czyli testujemy end-to-end
Automatyzacja jest wręcz nieodzownym elementem we wszelkiego rodzaju testach end-to-end w PLM. Są one długotrwałe i pracochłonne, ponieważ obejmują cały proces biznesowy, włączając w to systemy współpracujące oraz nierzadko dużą liczbę danych wejściowych.
Praca nad testami end-to-end zaczyna się od dokładnego wyspecyfikowania zakresu testów z klientem – tworzone są scenariusze testowe z krokami napisanymi zgodnie z zasadami BDD. Następnie przygotowywana jest dokumentacja dla każdego kroku, z opisem weryfikacji sprawdzanych w systemie. Tak przygotowany zestaw danych (scenariusze testowe w języku Gherkin oraz dokumentację) dostaje klient jeszcze raz do weryfikacji i akceptacji, aby mieć pewność, że tematy zostały dobrze zrozumiane.
Zaakceptowane przypadki testowe dla testów end-to-end umieszczane są w repozytorium kodu i rozpoczyna się automatyzowanie każdego z kroków za pomocą Javy i JUnit lub Selenium. Po ukończonym procesie automatyzacji następuje konfiguracja Jenkinsa, aby zautomatyzowane testy były uruchamiane w trakcie budowania środowiska testowego.
Testowania oprogramowania PLM – ciągłe zapewnianie jakości
Rozwój coraz bardziej złożonego oprogramowania wymaga tworzenia, wdrażania i utrzymywania dużej liczby przypadków testowych. Od ponad 15 lat systematycznie wdrażamy procesy testowe zarówno dla średnich firm, jak i globalnych graczy. Oprócz zdobytego praktycznego doświadczenia, staramy się zawsze włączać do naszych usług nowe rozwiązania technologiczne. Zrealizowaliśmy ponad 1000 projektów Product Lifecycle Management dla klientów z całego świata i różnych branż: aerospace&defence, automotive, costumer goods, energy, telco and machine builders.
W naszych projektach wdrażamy automatyzację, wspieraną przez continuous integration i continuous delivery. Tak, aby wszelkie błędy wykrywać jak najszybciej. Także by tworzone przez nas oprogramowanie PLM było pod stałą kontrolą zestawu testów, przy jak najmniejszym koszcie dla klienta i zaangażowaniu pracowników.
Jeżeli masz pytania odnośnie do sposobów zapewnienia jakości oprogramowania lub potrzebujesz wsparcia procesu testowego w swojej firmie, napisz do nas lub sprawdź ofertę testowania oprogamowania PLM.