Dotarliśmy do kilku ostatnich artykułów z serii „Przywództwo w testowaniu”. Do tej pory omówiliśmy, jak planować i zarządzać projektem testowym od początku do końca, a także wiele związanych z tym narzędzi i procesów.
W tym artykule chcę omówić zapewnienie jakości procesów biznesowych w przedsiębiorstwie (EBPA) — czym jest i jak do niego podejść. Omówimy:
- Czym jest zapewnienie jakości procesów biznesowych w przedsiębiorstwie?
- Zrozumienie integracji i testowania systemów
- Testowanie poziome: podejście do testów E2E
- Ryzyko integracji i testy E2E
Jest wiele do omówienia, więc przejdźmy do rzeczy.
Czym jest zapewnienie jakości procesów biznesowych w przedsiębiorstwie?
Każda organizacja wdrażająca nowe systemy doświadczyła problemów podczas ich pierwszego użycia. Systemy, które choćby nieznacznie nie pasują do istniejącej infrastruktury i procesów biznesowych, mogą wywołać chaos i być trudne do naprawienia.
Praktyki iteracyjne, zwinne i oparte na większej współpracy pomagają, jednak wyzwania związane z integracją w całym przedsiębiorstwie można rozwiązać wyłącznie poprzez końcowy etap testowania.
Tę końcową fazę nazywamy zapewnieniem jakości procesów biznesowych w przedsiębiorstwie (EBPA). Sukces zależy od jednej lub kilku faz testowania, które wykażą, że systemy, procesy biznesowe i dane są zintegrowane oraz dostarczają obiecane usługi.
Istnieje niewiele opracowań naukowych na ten temat, mimo że końcowe etapy każdego projektu na dużą skalę są zdominowane przez tę działalność. Aby opracować naszą strategię EBPA, najpierw przyjrzymy się bliżej rodzajom integracji i testowania systemów, z którymi będziesz mieć do czynienia.
W projektach na poziomie przedsiębiorstwa złożoność rośnie wykładniczo. Dlatego wybór oprogramowania do zarządzania bazami danych klasy korporacyjnej może całkowicie zmienić skuteczność działań związanych z inżynierią jakości.
Zrozumienie integracji i testowania systemów
Integracja pionowa
Z technicznego punktu widzenia integracja oznacza połączenie różnych warstw architektury technicznej. Testowanie integracyjne wykonywane przez programistów polega głównie na sprawdzeniu, czy dane wprowadzone za pośrednictwem interfejsu użytkownika podczas transakcji aktualizującej są prawidłowo zapisywane w bazie danych.
W drugą stronę sprawdza się przechowywane dane, aby upewnić się, że na żądanie mogą zostać dokładnie zaprezentowane w interfejsie użytkownika. Połączenia i ścieżki w architekturze technicznej można postrzegać jako ścieżki pionowe lub pionowe testy integracyjne.
Integracja pozioma
Użytkownicy końcowi nie widzą architektury technicznej ani całej jej złożoności. Postrzegają system jako zbiór funkcji, z których korzystają różni użytkownicy w ramach czegoś, co można nazwać ścieżką użytkownika.
Ścieżki te odwzorowują przebieg procesów biznesowych użytkowników i na każdym etapie wykorzystują interfejs użytkownika do uzyskiwania dostępu do różnych systemów i funkcji.
Zespoły zwinne pracują nad historyjkami na mniejszą skalę i nie widzą większej całości. Programiści zwykle nie mogą śledzić ani testować dłuższych ścieżek użytkownika, ponieważ nie mają odpowiednich środowisk ani danych. Dlatego organizacje zazwyczaj polegają na testach przeprowadzanych na większą skalę oraz zespołach testerów, które je weryfikują.
Podróże użytkowników w naturalny sposób obejmują jednocześnie proces biznesowy i funkcje systemu. W ten sposób testy poziome sprawdzają integrację między systemami a procesem biznesowym.
Testowanie integracji pionowej przyjmuje bardziej techniczną perspektywę, natomiast testowanie poziome przyjmuje perspektywę użytkownika lub procesu biznesowego.
Wykorzystajmy teraz te koncepcje do stworzenia modelu, który pomoże nam zrozumieć i zaplanować EBPA. W modelu odwołamy się do podejść do integracji poziomej i pionowej.
Have an account? Log In
Model integracji i testowania
Integracja jest często niezrozumiałym pojęciem. Proces integracji faktycznie rozpoczyna się niemal w chwili rozpoczęcia kodowania. Można powiedzieć, że integracja zaczyna się, gdy mamy dwie linie kodu — druga linia kodu musi zostać zintegrowana z pierwszą. Integracja kończy się wraz z zakończeniem wszystkich testów funkcjonalnych podczas akceptacji użytkownika.
Skupmy się na przykładzie wykorzystującym gotowe moduły komercyjne (COTS) oraz moduły do planowania zasobów przedsiębiorstwa (ERP).
Firma programistyczna tworząca moduły COTS lub ERP przeprowadziła testy jednostkowe i funkcjonalne. Po dostarczeniu tych komponentów można zazwyczaj założyć, że działają i są zintegrowane pod względem technicznym. Zawsze jednak istnieje ryzyko, że zintegrowane komponenty pochodzące od różnych dostawców będą współdziałać w nieprzewidziany sposób.
Ponadto, jeśli komponenty zostaną dostosowane, ich zachowanie ulegnie zmianie, co ponownie może spowodować subtelne (i nie tylko subtelne) skutki uboczne w innych miejscach. Nadal istnieje potrzeba integracji pionowej w celu zweryfikowania wymiany sterowania i danych w stosie technologicznym oraz integracji poziomej między komponentami i procesem biznesowym.
Cztery działania integracyjne przedstawiamy w modelu czterech ćwiartek z dwiema osiami. Na osi X mamy skalę testowanego systemu — pojedynczy komponent lub podsystem działający niezależnie albo zintegrowane systemy w kontekście procesu biznesowego.
Prawa strona modelu jest zaznaczona na niebiesko i przedstawia EBPA. Testowanie naszego systemu w kontekście innych systemów (SIT) i procesu biznesowego (BIT) określamy jako zapewnienie jakości biznesowych procesów przedsiębiorstwa.
Przyjrzyjmy się po kolei czterem ćwiartkom.
Testowanie modułów, funkcji lub komponentów
Moduł musi zostać przetestowany funkcjonalnie, niezależnie od tego, czy został zbudowany na zamówienie, czy jest komponentem COTS. Doświadczenie użytkownika jest zawsze ważne, a moduł musi integrować się z pewnym krokiem lub działaniem w procesie biznesowym.
Testowanie integracji podsystemów
Integracja ma charakter przyrostowy. Gdy komponenty niskiego poziomu i funkcje stają się dostępne, są integrowane z coraz większym systemem i testowane aż do uzyskania kompletnego, spójnego systemu. Nazywamy to testowaniem integracji podsystemów.
Testowanie integracji systemów (SIT)
Żaden system nie istnieje w izolacji, dlatego gdy nasz system jest kompletny, musimy zintegrować go z innymi systemami. Instalujemy nasz system w środowisku wraz z systemami, z którymi się komunikuje, i testujemy działanie tych systemów jako „systemu systemów” za pośrednictwem tych interfejsów. Naszym celem na tym etapie jest zajęcie się technicznymi ryzykami integracji, dlatego nazywamy go testowaniem integracji systemów.
Testowanie integracji biznesowej (BIT)
Ostatni etap integracji ma na celu zapewnienie, że zbudowane systemy integrują się z procesami biznesowymi i (często manualnymi) procedurami użytkowników tych systemów. Uwzględniając zewnętrzne interfejsy systemu (jeśli nie zostały już przetestowane), sprawdzamy, czy systemy i procesy biznesowe, działając wspólnie, zapewniają spójne i wydajne ścieżki użytkownika oraz prawidłowo i konsekwentnie zarządzają danymi i przekazują je dalej. Zwykle nazywamy to testowaniem integracji biznesowej.
W dalszej części tego artykułu skupimy się przede wszystkim na poziomej stronie modelu, czyli EBPA.
Powiązany artykuł: 10 NAJLEPSZYCH NARZĘDZI DO ZARZĄDZANIA DANYMI TESTOWYMI
Testowanie poziome: podejście do testowania E2E
Integracja pozioma w największym stopniu opiera się na tym, co często nazywa się testowaniem od początku do końca (E2E).
Testowanie E2E to technika projektowania testów, która wywołuje serię połączonych transakcji, zazwyczaj obejmujących wiele systemów, w tym nasze testowane systemy. Testy te zwykle podążają ścieżkami użytkowników przez procesy biznesowe.
Mając model procesu biznesowego, wyznacza się ścieżki przez proces, aby utworzyć użyteczną serię transakcji symulujących sposób, w jaki użytkownicy będą korzystać z systemu w środowisku produkcyjnym.
Modele te mogą przyjmować postać znanych diagramów, takich jak schematy blokowe lub diagramy torów, albo bardziej technicznych reprezentacji, takich jak diagramy sekwencji lub współpracy UML. (UML to zunifikowany język modelowania używany przez wiele organizacji IT).
Testy E2E dotyczą konkretnych zagrożeń, którymi trudno zająć się podczas wcześniejszych testów podsystemów lub w środowiskach w dużym stopniu zależnych od zaślepionych interfejsów i wyłącznie syntetycznych danych.
W obszarze testowania poziomego podejście do testowania E2E jest często uzupełniane przez specjalistyczne oprogramowanie. Aby poznać wyselekcjonowaną listę programów, które mogą usprawnić ten proces, sprawdź te najwyżej oceniane rozwiązania do zarządzania testami
Akceptacja
Pojęcie „dopasowania” jest odpowiednie w przypadku integracji komponent-komponent, integracji system-system oraz integracji systemów z procesem biznesowym.
Akceptacja zwykle opiera się na wynikach poziomych testów E2E, ponieważ interesariusze biznesowi mogą ufać, że testy te pokazują, jak nowy system pasuje do ich sposobu pracy i go wspiera. Poziome testy E2E dają im pewność, że dostarczona usługa będzie działać.
Proces akceptacji systemów zwykle przynajmniej częściowo zależy od pomyślnego przeprowadzenia poziomych testów E2E. Wynika to z faktu, że tylko testy E2E sprawdzają system w realistycznym środowisku i symulują realistyczne działania użytkownika.
W wielu organizacjach dopiero na końcowych etapach testów można zademonstrować działanie systemów, co daje interesariuszom pewność, że system będzie działał zgodnie z wymaganiami.
Jeśli poproszono Cię o zaplanowanie testu akceptacyjnego, oczekujemy, że technika testów E2E będzie odgrywać dużą rolę w Twoim planowaniu.
Ryzyka integracji i testowanie E2E
Jak omówiono wcześniej, ryzyka integracji dotyczą integracji system-system lub integracji systemu z procesem biznesowym.
Niektóre organizacje decydują się podzielić testy dotyczące tych dwóch rodzajów ryzyka na testy integracji systemów (SIT) oraz testy integracji biznesowej (BIT). Często jednak ryzyka i testy są łączone w jeden etap testów określany jako E2E, akceptacja lub testy biznesowe.
Niezależnie od struktury testów szeroko wykorzystują one opisaną powyżej metodę testów E2E. W Twoim środowisku ryzyka, z którymi się spotykasz, mogą być odmianami tych zagadnień i może być konieczne odpowiednie dostosowanie celu testów oraz podejścia do testów.
Przedstawioną tutaj listę ryzyk należy traktować wyłącznie jako punkt wyjścia oraz przypomnienie, na czym należy skupić testowanie. Prawdopodobnie istnieją ryzyka charakterystyczne dla Twojej organizacji, branży lub technologii, które trzeba będzie dodać do tej listy początkowej.
W poniższej tabeli „systemy” oznaczają zbiór zintegrowanych systemów obejmujący nowy system lub systemy znajdujące się w fazie opracowywania, inne systemy starszego typu lub systemy infrastrukturalne oraz systemy zewnętrzne, np. banki lub organizacje partnerskie.
| Ryzyko | Cel testu | Podejście testowe |
| Systemy nie są zintegrowane (transfer danych). | Wykazać, że systemy są zintegrowane i prawidłowo wykonują transfer danych. | Test integracji systemów (SIT) |
| Systemy nie są zintegrowane (przekazywanie sterowania). | Wykazać, że systemy są zintegrowane (przekazywanie sterowania wraz z wymaganymi parametrami odbywa się prawidłowo). | SIT |
| Interfejsy zawodzą podczas użytkowania przez dłuższy czas. | Wykazać, że interfejsy mogą być używane w sposób ciągły przez dłuższy czas. | SIT (Kontrole te mogą być również wykonywane jako część testów niezawodności i/lub przełączania awaryjnego) |
| Systemy nie są zintegrowane (dane nie są uzgadniane między interfejsami). | Wykazać, że systemy są zintegrowane (dane przekazywane przez interfejs są konsekwentnie wykorzystywane, np. waluta, język, metryki, czasy, dokładność, tolerancje). | SIT |
| Systemy nie są zsynchronizowane (transfery danych nie są wyzwalane, są wyzwalane w niewłaściwym czasie lub wielokrotnie). | Wykazać, że transfery danych są wyzwalane prawidłowo. | SIT |
| Obiekty lub jednostki istniejące w wielu systemach nie są uzgadniane między systemami. | Wykazać, że stany obiektów biznesowych są dokładnie reprezentowane w systemach przechowujących dane dotyczące tych obiektów. | Test integracji biznesowej (BIT) |
| Systemy nie są zintegrowane z procesem biznesowym (łańcuchem dostaw). | Wykazać, że systemy integrują się z procesami biznesowymi i wspierają proces łańcucha dostaw. | BIT |
| Zaplecze procesów biznesowych nie obsługuje internetowych ani mobilnych interfejsów użytkownika. | Wykazać, że procesy łańcucha dostaw są wykonalne i wspierają cel biznesowy. | BIT |
| Zintegrowane systemy używane przez tych samych pracowników mają niespójne interfejsy użytkownika lub zachowanie podczas wykonywania podobnych albo powiązanych zadań. | Wykazać, że użytkownicy doświadczają spójnego zachowania systemów podczas wykonywania podobnych albo powiązanych zadań. | BIT (Kontrole te mogą być również wykonywane podczas sprawdzania UX) |
Uwagi dotyczące tabeli ryzyk
Niektóre z powyższych ryzyk wymagają nieco szerszego wyjaśnienia.
Problemy z transferem danych
Dane są często przesyłane między systemami za pośrednictwem sieci. Jeśli transfery te są wykonywane jako procesy wsadowe i zakończą się niepowodzeniem albo zawiodą podczas transferu w czasie rzeczywistym wywołanego przez użytkownika, firmę lub inne zdarzenie systemowe, w systemie docelowym zabraknie danych.
Nieprawidłowe przekazywanie sterowania
Przekazywanie sterowania ma miejsce wtedy, gdy działanie użytkownika lub proces systemowy przekazuje użytkownika albo proces do innej funkcji systemu.
Zazwyczaj istnieje możliwość wyboru docelowej funkcji i, w zależności od działania użytkownika lub zawartości danych transakcji, wybierana jest inna ścieżka przejścia przez aplikację.
Z perspektywy użytkownika następuje przekierowanie do niewłaściwego miejsca w aplikacji albo proces systemowy próbuje wykonać niewłaściwy proces i traci synchronizację.
Dane nie są uzgadniane
System może rozprowadzać dane dotyczące na przykład pieniędzy, lokalizacji zasobów lub pewnej wielkości fizycznej, która musi „sumować się” we wszystkich systemach.
Na przykład, gdy zakupiono i przeniesiono, sprzedano, wykorzystano w procesach produkcyjnych, uznano za wadliwe i zwrócono lub zezłomowano 100 sztuk zapasów, liczba sztuk znajdujących się w każdym podsystemie musi być zgodna z pierwotną liczbą 100.
Odmianą tego problemu są na przykład jednostki używane w systemach przechowujących dane. Należy uwzględnić wielkości partii lub agregacje zliczanych elementów albo zapewnić zgodność miar metrycznych i imperialnych w systemach itd.
Systemy nie są zsynchronizowane
Problem transferu danych opisany powyżej wiąże się z tym, że procesy systemowe realizujące transfery są zaplanowane do uruchamiania we właściwej kolejności, wyzwalane przez odpowiednio autoryzowane procesy lub osoby oraz uruchamiane w odpowiednim czasie i przez właściwe zdarzenie lub połączenie zdarzeń.
Niektóre procesy wsadowe muszą być uruchamiane co godzinę, codziennie, co tydzień, na koniec miesiąca, kwartału lub roku itd., dlatego należy je sprawdzać. Od względnego czasu realizacji transakcji lub wieku danych w różnych systemach zależy wiele zachowań funkcjonalnych, które również trzeba zweryfikować.
Obiekty nie są uzgadniane
Zamiast liczby obiektów, pieniędzy lub pomiarów fizycznych ryzyka te dotyczą stanu obiektów przechowywanych w systemach rozproszonych. Na przykład status pracownika w rekordzie personelu powinien być spójny we wszystkich systemach przechowujących kopie tego obiektu danych. Procesy rozpowszechniające zmiany stanu w systemach przechowujących kopie tego samego obiektu muszą być wyzwalane, a ich działania sprawdzane.
Systemy nie są zintegrowane z działalnością biznesową
Działanie systemów musi być zsynchronizowane z intencjami użytkowników. Typowe problemy występują wtedy, gdy system prezentuje informacje niekompletne, nieaktualne lub nieprawidłowe. Ich przyczyną jest nieprawidłowe działanie transferów lub synchronizacji danych, jednak problemy te ujawniają się za pośrednictwem interfejsu użytkownika.
More Articles
Procesy zaplecza nie obsługują warstwy interfejsu użytkownika
Ten rodzaj problemu przejawia się jako niespójność między systemami ewidencyjnymi a systemami interakcji. Procesy wsadowe zaplecza, które nie są uruchamiane wystarczająco często lub nie są uruchamiane wcale, nie udostępniają danych systemom interakcji warstwy interfejsu użytkownika. Podobnie transakcje użytkowników realizowane za pośrednictwem systemów interakcji nie są odzwierciedlane w systemach ewidencyjnych.
Niespójne interfejsy użytkownika
Gdy firma lub usługa jest dostępna za pośrednictwem interfejsów mobilnych, internetowych i kioskowych, interfejs użytkownika działa w różny lub niespójny sposób. Wszystkie te interfejsy mogły być testowane niezależnie, ale ich działanie się różni. Na przykład stosowane są różne reguły walidacji danych wejściowych, przechwytywane lub wyświetlane są różne pola danych albo kolejność wprowadzania danych jest inna.
Podsumowanie
Przedstawiliśmy model integracji i testowania, który kładzie nacisk na integrację obejmującą całe przedsiębiorstwo oraz na proces biznesowy. Podejście E2E jest jedynym, które wymaga pełnej integracji systemów i opiera testy na kompletnych ścieżkach użytkownika. Dzięki temu interesariusze mogą zobaczyć dowody prawidłowego działania systemów w realistycznym kontekście.
Wiele organizacji polega na użytkownikach, którzy stosują pewną formę testów E2E podczas testów akceptacyjnych i wykonują te testy ręcznie. Z mojego doświadczenia wynika, że lepsze jest bardziej systematyczne podejście oparte na ryzyku, które ułatwia automatyzację znacznej części pracochłonnego wykonywania testów.
W miarę jak organizacje wdrażają zwinne i bardziej dynamiczne podejścia do wytwarzania oparte na ciągłym dostarczaniu, przekazując zespołom zwinnym większą odpowiedzialność za testowanie podsystemów, łatwo zaniedbać późniejsze testy integracji i akceptacji obejmujące całe przedsiębiorstwo.
Podejście EBPA, zwłaszcza jeśli jest zautomatyzowane, rozszerza model ciągłej integracji z poziomu podsystemu na zapewnianie jakości biznesowych procesów przedsiębiorstwa.
Pakiety COTS i ERP umożliwiają wdrażanie niezwykle funkcjonalnych, lecz złożonych systemów przy mniejszym nakładzie prac programistycznych, jednak ryzyka integracji są równie istotne jak w przypadku tworzenia oprogramowania niestandardowego.
W większych środowiskach podejścia zwinne i oparte na ciągłym dostarczaniu cieszą się coraz większą popularnością, dlatego wraz ze wzrostem złożoności i skali rośnie również częstotliwość dostarczania oraz związane z nią ryzyko.
Rozwiązanie jest jasne: organizacje muszą poważnie potraktować EBPA. Powinny zrozumieć ryzyka integracji oraz sposób organizacji testów, aby im przeciwdziałać. Testerzy muszą zmierzać w kierunku nowoczesnego podejścia opartego na modelach, abstrahować swoje procesy biznesowe, systemy i testy oraz systematycznie wdrażać automatyzację testów.
Zapisz się do biuletynu The QA Lead, aby otrzymywać powiadomienia o publikacji nowych części serii. Te wpisy są fragmentami kursu przywództwa w testowaniu Paula, który zdecydowanie polecamy, aby lepiej zgłębić ten i inne tematy. Jeśli się zapiszesz, użyj naszego ekskluzywnego kodu kuponu QALEADOFFER, aby otrzymać zniżkę w wysokości $60 od pełnej ceny kursu!
Polecana lektura: 10 NAJLEPSZYCH NARZĘDZI O OTWARTYM KODZIE DO ZARZĄDZANIA TESTAMI