Nabywcy licencji naszego oprogramowania mogą skorzystać z następujących elementów Pakietu Usług Utrzymania Systemu (PUUS) typu MAINTENANCE:
gwarancja zapewniająca wsparcie kryzysowe,
wsparcie techniczne - na kłopoty służb IT,
pomoc doraźna - na kłopoty użytkowników,
aktualizacje - dla dotrzymania kroku innowacjom.
Gwarancja
Nabywcy otrzymują gwarancję niezawodność i stabilności naszego oprogramowania na poziomie najwyższych standardów obowiązujących dla porównywalnych rozwiązań technologicznych i programistycznych klasy MES, które są dostępne na rynku. Jesteśmy do bólu skuteczni w osobistych staraniach popartych rygorystycznymi procedurami korporacyjnymi, aby sprostać tym wymaganiom.
Wiadomo jednak, że pomimo najlepszych praktyk zawsze pozostaje pewien margines dla ukrytych wad produktu, które mogą dać osobie znać dopiero w trakcie eksploatacji przez końcowych odbiorców w rzeczywistych warunkach otoczenia informatycznego podlegającego zarówno zwykłej ludzkiej omylności, jak i gwałtownym przeobrażeniom technologicznym naszych czasów.
Dlatego na co dzień dajemy świadectwo najlepszej możliwej opieki serwisowej dla użytkowników Platformy CADAS.
W ramach gwarancji jakości oprogramowania otaczamy opieką każdego uprawnionego użytkownika Platformy CADAS w każdej sytuacji awaryjnej, to znaczy ofiarujemy nasze wsparcie kryzysowe zawsze, gdy natrafia on na kłopoty w korzystaniu z naszego oprogramowania, które wstrzymują normalny tryb jego pracy.
Zapewniamy w takich sytuacjach natychmiastowe rozeznanie: czy awaria została przez nas zawiniona (tzn. wynikła z ukrytej wady naszego Oprogramowania bądź z błędu popełnionego przez naszą obsługę), czy przyczyna tkwi gdzie indziej.
W przypadku naszej winy gwarantujemy nieodpłatne, bezzwłoczne i skuteczne usunięcie: (i) ukrytych wad konstrukcyjnych Oprogramowania lub (ii) błędów implementacji Oprogramowania w danym środowisku informatycznym lub (iii) błędów obsługi popełnionych przez naszych programistów, serwisantów lub wdrożeniowców.
natomiast
W przypadku, gdy diagnoza wskazuje na przyczyny tkwiące w informatycznym środowisku, które pozostaje poza naszą odpowiedzialnością - nie pozostawiamy użytkownika samemu sobie, lecz uruchamiamy tryb Wsparcia technicznego dla miejscowego Administratora IT. Ponadto wprowadzamy modyfikacje konstrukcyjne lub zalecenia eksploatacyjne zwiększające odporność naszego oprogramowania na zawirowania w otoczeniu.
Szczegółowe zobowiązania CADAS Software Sp. z o. o. dotyczące: okresu obowiązywania, dostępności, czasu reakcji, czasu likwidacji awarii oraz procedur egzekwowania gwarancyjnego wsparcia kryzysowego są uzgadniane w umowach odbiorcami licencji i usług towarzyszących.
Niezależnie od Wparcia kryzysowego zapewniamy naszym użytkownikom pakiet Usług Utrzymania Systemu obejmujący (i) wsparcie techniczne, (ii) pomoc doraźną i (iii) aktualizacje.
Wsparcie techniczne
Udzielamy daleko idącej pomocy Administratorowi IT lub bezpośrednio użytkownikom Licencjobiorcy jak również osobom trzecim działającym w imieniu lub na rzecz Licencjobiorcy w ich wywiązywaniu się z odpowiedzialności za sprawne funkcjonowanie Infrastruktury IT w której zostało zainstalowane nasze w Oprogramowanie.
Dotyczy zatem wszelkich działań naszego serwisanta lub wdrożeniowca w obrębie Infrastruktury IT Licencjobiorcy, które leżą poza zobowiązaniami objętymi gwarancją i jednocześnie przynależą do zakresu kompetencji lub odpowiedzialności użytkowników Licencjobiorcy. Są to w szczególności takie działania z naszej strony jak:
Pomoc w charakterze asysty w konfigurowaniu komponentów danej Infrastruktury, które są istotne dla stabilnej pracy Oprogramowania.
Pomoc w charakterze asysty w rozwiązywaniu sytuacji kryzysowych Licencjobiorcy – awarii, przestojów, itp., które przejawiają się wadliwym działaniem Oprogramowania lub jego funkcji, ale w wyniku diagnozy przeprowadzonej zgodnie z ustaloną w Umowie Procedurą Serwisowania została wykluczona wadliwość konstrukcji Oprogramowania lub błędy serwisu Licencjodawcy.
Doradztwo w czynnościach modernizacji lub rozbudowy Infrastruktury, dla zapobiegania niekompatybilności nowych elementów i dla optymalizowania pracy systemów zaimplementowanych w Infrastrukturze warz z Oprogramowaniem Licencjodawcy.
W wykonywaniu przez CADAS Software Sp. z o. o. usług Wsparcia Technicznego mają z reguły zastosowanie takie same procedury zgłaszania problemów, jak w przypadku Obsługi Gwarancyjnej.
Pomoc doraźna
Na potrzeby osób zatrudnionych w działach operacyjnych Licencjobiorcy pozostajemy stale w gotowości do udzielania im pomocy, gdy natrafią na kłopoty w wykonywaniu rutynowych czynności przy pomocy aplikacji klienckich SCU i QET Platformy CADAS Przynależy tutaj w szczególności udzielanie przez konsultanta serwisowego CADAS Software Sp. z o. o.: wskazówek dotyczących nowo wprowadzonych elementów lub funkcji Oprogramowania - w przypadku braku odpowiedniego opisu w plikach pomocy systemu lub w instrukcji użytkowania.
Aktualizacje
Platforma CADAS jest ustawicznie wzbogacana o nowe rozwiązania użytkowe i technologiczne, które na bieżąco dostarczamy naszym licencjobiorcom.
Dotrzymujemy przy tym kroku wszelkim branżowym innowacjom, które przysparzają przewagi konkurencyjnej, ponieważ BADACZE są autorami niemal wszystkich inspiracji dla prowadzenia prac rozwojowych, a Platforma CADAS jest użytkowana przede wszystkim przez osoby zawodowo trudniące się pozyskiwaniem zamówień oraz wykonywaniem badań rynkowych w komercyjnych agencjach bądź w korporacyjnych zespołach badawczych.
Szkolenia i certyfikaty
Posiadacze licencji naszego oprogramowania jak również odbiorcy usług inżynierii oprogramowania oraz usług hostingu korzystają z możliwości przeszkolenia swego personelu w potrzebnym zakresie (według indywidualnego uzgodnienia zakresu, czasu i miejsca realizacji).
Uczestnicy szkoleń otrzymują odpowiednie certyfikaty.
Plan W fazie planowania zespoły DevOps wymyślają, definiują i opisują funkcje oraz możliwości aplikacji i systemów, które tworzą. Śledzą postępy z uwzględnieniem niskiego i wysokiego poziomu szczegółowości — od zadań dotyczących pojedynczego produktu, po zadania obejmujące portfele wielu produktów. Tworzenie list prac, śledzenie usterek, zarządzanie zwinnym wytwarzaniem oprogramowania za pomocą narzędzi Scrum, używanie tablic Kanban oraz wizualizowanie postępów przy użyciu pulpitów nawigacyjnych to niektóre ze sposobów stosowanych przez zespoły DevOps do planowania z użyciem elastyczności i widoczności.
Dla deweloperów Faza programowania obejmuje wszystkie aspekty programowania — pisanie, testowanie, ocenę i wdrażanie kodu przez członków zespołu — a także skompilowanie tego kodu do artefaktów kompilacji, które mogą być wdrożone w różnych środowiskach. Zespoły DevOps dążą do tworzenia szybkich innowacji bez uszczerbku dla jakości, stabilności i produktywności. W tym celu wykorzystują bardzo wydajne narzędzia, automatyzują typowe i ręczne kroki oraz wykonują iteracje z małymi przyrostami z użyciem automatycznego testowania i ciągłej integracji.
Dostarczanie Dostarczanie to proces wdrażania aplikacji w środowiskach produkcyjnych w sposób spójny i niezawodny. Faza dostarczania obejmuje również wdrażanie i konfigurowanie w pełni nadzorowanej infrastruktury podstawowej, która składa się na te środowiska. W ramach fazy dostarczania zespoły definiują proces zarządzania wydaniami z jasnymi etapami ręcznego zatwierdzania. Tworzą także automatyczne bramy, które przenoszą aplikacje miedzy etapami do czasu, aż zostaną udostępnione klientom. Automatyzacja tych procesów sprawia, że stają się skalowalne, powtarzalne i kontrolowane. W ten sposób zespoły korzystające z metodyki DevOps mogą często dostarczać w sposób łatwy, pewny i bezstresowy.
W tym materiale postaram się Wam przybliżyć nieco temat środowisk, a w szczególności skupić się na środowiskach testowych. Na samym początku musimy sobie zadać podstawowe pytanie: „Czym w ogóle jest środowisko w kontekście pracy dowolnej aplikacji?”
Środowisko – to zbiór niezbędnych elementów infrastruktury technicznej / softwarowej, który stanowi podstawę do działania danej aplikacji.
Środowisko testowe jest jednym z kilku typów środowisk. Poza wspomnianym środowiskiem testowym są jeszcze inne, takie jak:
Środowisko testowe jak już mówi sama nazwa – powinno być przeznaczone do przeprowadzania testów aplikacji. Środowisko testowe jest jednym z punktów, które dostarczają nam informacji na temat jakości i zachowania testowanej aplikacji. Mówiąc prościej – środowisko testowe ma za zadanie zapewnić nam rozwiązanie – niezbędne do przeprowadzania testów danej aplikacji.
Dobre środowisko testowe powinno posiadać kilka charakterystycznych, specyficznych właściwości.
Po pierwsze powinno być stabilne – przynajmniej do tego stopnia, aby testerzy mogli swobodnie i bez nieplanowanych przerw (spowodowanych niedostępnością środowiska) testować manualnie lub automatycznie wskazaną aplikację. Dlatego też środowisko testowe powinno być jak najbardziej zbliżone do docelowego (produkcyjnego) środowiska, pod kątem jego funkcjonalności i konfiguracji zarówno hardwarowej, jak i softwarowej.
Oczywiście wierne odwzorowanie środowiska produkcyjnego (1:1) jest zwykle bardzo trudne, a często nawet nieosiągalne. Takiej praktyki nie stosuje się głównie również z uwagi na koszty, gdyż wierne odwzorowanie wszystkich parametrów środowiska produkcyjnego – byłoby po prostu bardzo kosztowne. Zwykle takie idealne odwzorowanie środowiska produkcyjnego jest również niepotrzebne, gdyż środowisko testowe służy jednak do innych celów, niż środowisko produkcyjne. Mogę tutaj, chociażby zwrócić uwagę na to, że na środowisku testowym będą pracowali tylko testerzy, czy też osoby zaangażowane w development.
Natomiast na środowisku produkcyjnym będą działać klienci, których często może być wiele tysięcy (pracujących jednocześnie) więc środowisko produkcyjne, musi być dużo bardziej wydajne i bogato wyposażone w zasoby.
Środowisko testowe powinno być wyizolowane. Co to konkretnie oznacza?
Oznacza to, że środowisko powinno być przeznaczone tylko do określonych celów – w tym przypadku do testów. Podążając tym tokiem myślenia – środowisko to powinno być przeznaczone tylko dla testerów manualnych, automatycznych i nie powinni na nim pracować developerzy. Środowisko powinno być bardziej stabilne, dopracowane i wydajne niż środowisko developerskie (na którym powinni pracować właśnie developerzy). Niestety to właśnie te cechy środowiska testowego jak stabilność i wydajność – często zachęcają programistów do działania właśnie na środowisku testowym – nie jest to jednak dobra praktyka i zwykle konsekwencje takiej pracy są bardzo negatywne.
Oczywiście zdarza się, że czasami drobne prace developerskie mogą być przeprowadzone bezpośrednio na środowisku testowym – gdyż czasami jest to jedyna, szybka możliwość na realizację pewnych zadań developerskich. Takie prace jednak trzeba przeprowadzać z głową, gdyż zdecydowanie nie powinny się zdarzać takie sytuacje, w których testerzy nie mogliby wykonywać testów z powodu prowadzenia właśnie prac developerskich.
Częste ingerencje programistów w środowisko testowe znacznie obniżają stabilności takiego środowiska. Z powyższego wywodu płynie jeszcze jeden bardzo ważny wniosek. Wszelkie niedoskonałości, problemy ze środowiskiem testowym mogą wpłynąć negatywnie na jakość całego produktu końcowego. Zachowanie poprawności i ciągłości działania środowiska testowego jest punktem kluczowym dla całego procesu testowego. Oczywiście to środowisko, jak i każde inne również będzie miało przerwy w działaniu podyktowane, chociażby pracami konserwacyjnymi, aktualizacyjnymi czy podgrywaniem nowej wersji aplikacji.
Ważne, aby takie przerwy były planowane z wyprzedzeniem i aby o ich ewentualnym zaistnieniu wiedzieli pracujący na nim testerzy. Dlaczego informacje o planowanej niedostępności środowiska, bądź jego czasowym niestabilnym działaniu są takiego ważne? Istnieją dwa główne powody takiego stanu rzeczy. Przede wszystkim – bywa tak, że samo przygotowanie do testu danych testowych, tekstyliów oraz samej aplikacji, często bywa dłuższe, niż samo wykonanie testu, dlatego musimy unikać sytuacji, w których przez nieplanowaną niestabilność środowiska tracimy naszą pracę, a przy tym nasz cenny. Po drugie – kiedy środowisko jest niestabilne, mogą pojawiać się błędy w aplikacji, które normalnie nie mają prawa się zdarzyć i przez to dajemy mylny obraz aktualnego stanu jakościowego aplikacji.
W jednym projekcie może istnieć więcej niż jedno środowisko testowe. Spotkałem się już z sytuacjami, w których testerzy manualni mieli swoje odseparowane środowisko testowe, testerzy automatyzującym mieli inne środowisko testowe, a klienci, którzy zamówili aplikację, mieli jeszcze inne swoje środowisko do swoich testów.
Główne elementy tworzenia środowiska testowego
Postawienie środowiska testowego wymaga wielu elementów, o których musimy pamiętać.
Najważniejsze punkty to:
Stworzenie danych testowych i poprawne ich zaimplementowanie
Bazy danych
Infrastruktura hardwarowa
Infrastruktura softwarowa
Konfiguracja sieci
Komunikacja z innymi wymaganymi rozwiązaniami, systemami
Pliki konfiguracyjne, dokumentacje
Frontendowe środowisko uruchomieniowe
Zarządzanie środowiskiem testowym
Bardzo ważnym elementem środowiska testowego jest jego zarządzanie. Zarządzanie środowiskiem skupia się głównie na pracach konserwacyjnych, aktualizacyjnych, rozwiązywaniem pojawiających się problemów, monitorowanie oraz utrzymywaniem ciągłości działania. Te czynności zwykle realizują dedykowani dla środowiska – administratorzy.
Lista zadań, które należą do administratorów środowisk to:
Utrzymanie centralnego repozytorium kodu
Zarządzanie środowiskiem zgodnie z wymaganiami i oczekiwaniami osób na nim pracujących
Monitoring, śledzenie aktywności i wszelkich anomalii
Aktualizacje oprogramowania, sprzętu
Koordynacja prac prowadzonych na środowisku
Informowanie o planowanych niedostępnościach środowiska
Jak zorganizować wiele środowisk do testowania
Moim zdaniem najbardziej efektywnym sposobem zarządzania środowiskami testowymi jest automatyzacja. Dzięki automatyzacji kompilacji i wdrażania możemy znacznie zoptymalizować pracę ze środowiskami – nie tylko testowymi.
Narzędzia do ciągłej integracji (CI), takie jak Jenkins, Bamboo, CircleCI, GitLabCI doskonale nadają się do tego celu. Tego typu narzędzia nie tylko pomagają zautomatyzować wdrożenia środowiskowe, ale także pomagają w uruchamianiu testów automatycznych.
Innym podejściem do zarządzania środowiskami testowymi jest posiadanie szczegółowej dokumentacji opisującej na przykład sposób tworzenia dokładnej repliki innego środowiska. Jednak to bardziej manualne podejście jest znacznie bardziej czasochłonne i narażone na błędy ludzkie – niż proces CI.
Autor: Tomasz Stelmach
Leave a Comment