Zespoły programistyczne zarządzające się samodzielnie korzystają obecnie z szerszego zakresu narzędzi niż kiedykolwiek wcześniej. W typowym zespole programistycznym może być używanych dwadzieścia, a nawet trzydzieści narzędzi. Aby ułatwić Ci poruszanie się w tym wszystkim, w tym artykule omówimy:
- Narzędzia do testowania
- Architekturę narzędzi
- Zarządzanie testami
- Projektowanie testów
- Rozwiązania własnościowe czy otwartoźródłowe?
- Ćwiczenie dotyczące wyboru narzędzi
Na początek przyjrzyjmy się głównym typom narzędzi, których będziesz używać do testowania.
Narzędzia do testowania
Narzędzia istotne z punktu widzenia testowania można wygodnie podzielić na trzy typy:
- Narzędzia do współpracy: służą do rejestrowania pomysłów i wymagań, komunikacji w zespole oraz częściowej integracji ze zautomatyzowanymi procesami, czasami także z botami.
- Narzędzia testowe: szeroki wachlarz narzędzi obsługujących zarządzanie danymi testowymi, projektowanie testów, struktury testów jednostkowych, wykonywanie testów funkcjonalnych, testy wydajnościowe i obciążeniowe, testy statyczne, projektowanie testów, zarządzanie procesem testowym, przypadki testowe, rejestrowanie testów i raportowanie.
- Narzędzia DevOps lub zarządzania infrastrukturą: obsługują zarządzanie środowiskami i platformami, wdrażanie z użyciem infrastruktury jako kodu oraz technologii kontenerowych, a także rejestrowanie danych, monitorowanie i analitykę w środowisku produkcyjnym.
The Tools Knowledge Base to internetowy rejestr narzędzi, który różni się od większości rejestrów online tym, że obejmuje narzędzia do współpracy, testowania i DevOps. W tych trzech obszarach znajduje się ponad 1700 narzędzi. Strony internetowe narzędzi są indeksowane i można je przeszukiwać.
Witryna agreguje i indeksuje również ponad 300 blogerów, a także ponad 52 000 blogów, które można przeszukiwać. Udostępniliśmy adresy URL głównych kategorii narzędzi oraz skróty do wyszukiwania tych kategorii na blogach.
Istnieje ponad 1700 narzędzi wspierających współpracę, testowanie i DevOps.
W dalszej części tego artykułu przyjrzymy się najważniejszym kwestiom wpływającym na zarządzanie testami i wspierającym je.
Have an account? Log In
Architektura narzędzi
Na poniższej grafice zidentyfikowaliśmy zakres typów narzędzi używanych przez większość nowoczesnych zespołów programistycznych. Wyodrębniliśmy narzędzia, które zwykle są używane w środowiskach programistycznych, testowych i produkcyjnych.
Podstawą tych narzędzi są narzędzia infrastrukturalne zapewniające platformy, maszyny wirtualne i kontenery do obsługi środowisk, a także narzędzia realizujące automatyczne wdrożenia. Narzędzia używane do zarządzania wdrożeniami i wydaniami nazywa się narzędziami do orkiestracji wydań i potoków. Komunikacja w zespole, a także z wieloma zautomatyzowanymi procesami, jest zarządzana za pomocą narzędzi do współpracy lub ChatOps.
Chociaż przejście w kierunku DevOps napędza rozwój i wdrażanie narzędzi wspierających ciągły rozwój, niemal wszystkie te narzędzia są przydatne dla każdego zespołu zajmującego się tworzeniem oprogramowania lub operacjami.
Nie musisz działać w kulturze DevOps, aby korzystać z narzędzi „DevOps”.
Zarządzanie testami
Narzędzia do zarządzania testami są niezbędne we wszystkich projektach o dużej skali. Projekty zwinne zwykle wykorzystują narzędzie do zarządzania incydentami, a w przypadku testów w pewnym stopniu polegają na wykorzystaniu historyjek i scenariuszy biznesowych do śledzenia kluczowych przykładów, jeśli nie wszystkich testów. Narzędzia do zarządzania testami różnią się zakresem — od bardzo prostych, takich jak Microsoft Excel, po kompleksowe produkty do zarządzania cyklem życia aplikacji (ALM).
Ogólnie zakres narzędzi do zarządzania testami obejmuje kilka obszarów:
Model pokrycia testami: Większość narzędzi do zarządzania testami umożliwia zdefiniowanie zestawu wymagań, z którymi można powiązać przypadki testowe i/lub kontrole w testach. Wymagania te mogą czasami mieć strukturę hierarchiczną odzwierciedlającą spis treści dokumentu. Coraz częściej można również rejestrować inne modele, np. przypadki użycia lub przepływy procesów biznesowych. Zwykle dostępne są raporty dotyczące pokrycia planu testów i wykonania testów.
Zarządzanie przypadkami testowymi: Przypadkami testowymi i ich zawartością można zarządzać, aby zapewnić udokumentowany zapis testów. Zawartość przypadków testowych może być przygotowana przed rozpoczęciem testowania lub stanowić zapis wykonanych testów. Przypadki testowe mogą mieć format dowolnego tekstu albo być uporządkowane w kroki z oczekiwanymi wynikami. Importowanie dokumentów i obrazów do przechowywania przy testach lub krokach jest powszechne.
Planowanie wykonania testów: Testy można porządkować w hierarchię lub oznaczać tagami, aby zapewnić bardziej dynamiczną strukturę. Członkom zespołu testowego można przypisywać testy. Planowane czasy trwania testów mogą służyć do publikowania zsynchronizowanego harmonogramu testów do wykonania przez cały zespół. Można wybierać podzbiory testów w celu zapewnienia pokrycia wymagań, sprawdzenia wybranych funkcji oraz ponownego uruchomienia zestawów testów regresyjnych. Do wykonania można również wybierać testy oznaczone jako jeszcze niewykonane, zablokowane, zakończone niepowodzeniem lub mające inny status.
Wykonanie testów i rejestrowanie wyników: W miarę wykonywania testów przez zespół rejestrowany jest ich status. W przypadku każdego wykonanego testu identyfikowany jest tester, a także zapisywana jest data, godzina i czas trwania. Zakończonym powodzeniem testom można przypisać prosty status powodzenia. W przypadku nieudanych, zablokowanych lub nietypowych wyników testów można przypisać zrzuty ekranu i wyniki testów oraz utworzyć raport incydentu. Wiele narzędzi zapewnia integrację z narzędziami do wykonywania testów, które zarządzają testami i je uruchamiają, rejestrują wyniki, a nawet tworzą projekty raportów incydentów.
Zarządzanie incydentami: Niepowodzenia testów są rejestrowane w dzienniku wykonania. Zwykle wymagają one dalszego zbadania, debugowania i naprawy, jeśli przyczyną niepowodzenia był błąd. Niepowodzenia wymagające zbadania są zazwyczaj rejestrowane za pomocą raportów incydentów, obserwacji lub błędów. Raporty incydentów mogą zawierać dużą ilość dodatkowych informacji. Zwykle incydentom przypisuje się typ, testowany obiekt, priorytet i ważność. Niektóre firmy rejestrują ogromną ilość informacji i łączą ją z zaawansowanym procesem zarządzania incydentami.
Raportowanie: Raporty i analizy danych ze wszystkich powyższych funkcji, stosownie do potrzeb. Zakres raportów obejmuje między innymi porównanie planowanego i rzeczywistego pokrycia testami, status raportów incydentów służący do śledzenia trwających prac związanych z badaniem, naprawą i ponownym testowaniem, a także analizy czasu potrzebnego na naprawę różnych typów niepowodzeń według funkcji, ważności i pilności.
Najpopularniejszym narzędziem do zarządzania testami na świecie wciąż jest Microsoft Excel.
Projektowanie testów
Projektowanie testów opiera się na modelach. W przypadku testerów systemowych i akceptacyjnych typowymi modelami są dokumenty wymagań, przypadki użycia, schematy blokowe lub diagramy torów. Bardziej techniczne modele, takie jak modele stanów, diagramy współpracy, diagramy sekwencji i inne, również stanowią solidną podstawę projektowania testów.
W wielu projektach modele służą do rejestrowania wymagań lub projektów wysokiego poziomu. Gdy zostaną udostępnione testerom, mogą oni wykorzystać je do śledzenia ścieżek i bezpośredniego wybierania elementów pokrycia z modelu. Jeśli takie modele nie są dostępne, zespołowi testowemu często przydaje się zarejestrowanie na przykład schematów przepływu procesów lub diagramów torów. Pomagają one testerom prowadzić bardziej merytoryczne rozmowy z interesariuszami, szczególnie w kontekście podejścia do pokrycia.
Na rynku narzędzi własnościowych pojawiają się rozwiązania umożliwiające rejestrowanie modeli, takich jak schematy blokowe, i wykorzystywanie ich do generowania przypadków testowych poprzez śledzenie ścieżek zgodnie z określonym celem pokrycia, np. wszystkich połączeń, wszystkich procesów, wszystkich wyników decyzji, wszystkich par lub wszystkich ścieżek. Narzędzia te można łączyć z narzędziami do zarządzania i generowania danych testowych, aby generować kombinacje danych testowych do wykorzystania w testach ręcznych lub automatycznych.
Istnieją również narzędzia umożliwiające wykonywanie modelowania w narzędziach do wykonywania testów. Przykładowo narzędzia te pozwalają programiście testów przechwycić wszystkie pola na stronie internetowej, utworzyć połączenia w celu ich „zestawienia” oraz stworzyć model nawigacji dla strony — wszystko w formacie graficznym.
Model jest następnie wykorzystywany do tworzenia ścieżek nawigacji i zestawu testów spełniających określone kryteria pokrycia — podobnie jak w opisanych powyżej narzędziach do modelowania. Narzędzia wykonawcze mogą tworzyć automatyczne ścieżki testowe przy użyciu wybranych kryteriów lub generować je losowo, a także raportować pokrycie względem tych modeli.
Jest to obecnie dynamicznie rozwijający się obszar — warto śledzić narzędzia do modelowania obsługujące projektowanie i generowanie testów oraz narzędzia wykonawcze obsługujące modelowanie testowanego systemu, automatyczny wybór ścieżek testowych i raportowanie.
More Articles
Własnościowe czy otwartoźródłowe?
W ciągu ostatnich dwudziestu lat powszechne stało się korzystanie z bezpłatnych produktów o otwartym kodzie źródłowym (FOSS), zwłaszcza do obsługi infrastruktury. Koszt licencji na system operacyjny i powiązane oprogramowanie serwera internetowego firmy Microsoft, a także powszechna opinia, że Linux/Unix jest bardziej niezawodny i bezpieczny niż Windows, sprawiają, że w wielu środowiskach Linux/Unix jest systemem operacyjnym wybieranym dla serwerów.
Chociaż artykuł omawia zalety i wady narzędzi o otwartym kodzie źródłowym oraz narzędzi zastrzeżonych, jeśli szukasz konkretnie rozwiązań dobrze integrujących się z Jira, nasz kompleksowy przewodnik po narzędziach do zarządzania testami przeznaczonych dla Jira może pomóc Ci podjąć świadomą decyzję.
Dwie poniższe tabele (aktualizowane codziennie na stronie w3techs.com) pokazują względną popularność systemów operacyjnych i produktów serwerów internetowych. Około 85% witryn korzysta z najbardziej znanych produktów serwerów internetowych o otwartym kodzie źródłowym: Apache i Nginx.
Popularność tych produktów infrastrukturalnych o otwartym kodzie źródłowym dowodzi, że rozwiązania o otwartym kodzie źródłowym mogą być równie niezawodne, a nawet bardziej niezawodne niż produkty zastrzeżone.
Dla zespołu programistycznego potrzebującego dwudziestu lub trzydziestu narzędzi programistycznych do obsługi swoich działań istnieją niezawodne i funkcjonalne narzędzia FOSS oraz narzędzia zastrzeżone umożliwiające wykonanie każdego zadania. Jak wybrać między produktem zastrzeżonym a produktem FOSS?
Poniższa tabela podsumowuje niektóre kwestie, które możesz wziąć pod uwagę przy wyborze rodzaju narzędzia.
| Zastrzeżone | FOSS | |
| Dostępność | Narzędzia są dostępne dla każdego obszaru. | Niektóre obszary, szczególnie narzędzia programistyczne i infrastrukturalne, są lepiej obsługiwane niż inne. |
| Koszt zakupu | Często wysoki, szczególnie w przypadku produktów „dla przedsiębiorstw”. | Bezpłatne lub dostępne na licencji społecznościowej bez kosztów. W przypadku wersji dla przedsiębiorstw lub hostowanych mogą istnieć licencje komercyjne. |
| Dokumentacja | Zazwyczaj bardzo dobra. | Różna. Czasami doskonała, czasami nieistniejąca, a czasami plasująca się gdzieś pomiędzy. Często pisana przez programistów dla programistów, dlatego jest mniej użyteczna niż dokumentacja komercyjna. |
| Wsparcie techniczne | Bardzo dobre, ale odpłatne. | Różne. Niektórzy autorzy narzędzi zapewniają doskonałe wsparcie, a nawet dodają funkcje na życzenie. Wiele narzędzi ma fora internetowe – ale mogą one być bardzo techniczne. Inne narzędzia są słabo wspierane. |
| Niezawodność/jakość | Zazwyczaj bardzo dobra. | Zmienna. Produkty z wieloma użytkownikami, lokalizacjami i dużymi zespołami wsparcia mają zwykle doskonałą jakość. Niektóre narzędzia tworzone przez pojedyncze osoby, z niewielką liczbą współtwórców i użytkowników, mogą działać niestabilnie. |
| Zakres funkcji | Zestawy funkcji są zwykle zgodne z opublikowanymi planami rozwoju produktu i zazwyczaj kompleksowe. | Produkty ewoluują zazwyczaj w oparciu o zapotrzebowanie użytkowników oraz wielkość zespołu współtwórców. Współtwórcy zwykle dodają funkcje, których sami potrzebują, zamiast opierać się na przykład na ankietach klientów. |
| Częstotliwość wydań/łatek | Główne wydania pojawiają się zazwyczaj w odstępach kilku miesięcy, a czasami kilku lat. Regularnie wydawane są łatki. Ostrzeżenia i informacje o wydaniach są zwykle bardzo dobre. | Różna. Główne wydania dużych produktów infrastrukturalnych są podobne jak w przypadku produktów zastrzeżonych. Mniejsze i mniej popularne produkty są zwykle wydawane częściej. Często brak ostrzeżeń lub są one bardzo skąpe, informacje o wydaniach są słabe, a w niektórych przypadkach dochodzi do utraty wstecznej kompatybilności. |
Produkty FOSS mogą być tańsze w uzyskaniu, ale inne koszty i obowiązki mogą być znaczące. Decyzja między tymi dwoma rozwiązaniami zwykle zależy od połączenia kultury organizacyjnej, skłonności do ryzyka i możliwości technicznych.
Gdy kupujesz produkty zastrzeżone i umowy wsparcia, ryzyko związane z niekompatybilnością (z innymi produktami), niezawodnością, łatwością obsługi i uważnym wsparciem technicznym jest na ogół niskie, choć czasami wiąże się z wysokimi kosztami.
W przypadku produktów FOSS zazwyczaj musisz przeprowadzić znacznie dokładniejsze badania, zanim zdecydujesz się na korzystanie z jednego z nich. W końcu nie ma sprzedawcy, z którym można porozmawiać, a dokumentacja może być funkcjonalna, a nie wyczerpująca. Oczywiście okres próbny można łatwo skonfigurować i możesz korzystać z dowolnej liczby narzędzi, ale będziesz musiał dokładniej zbadać możliwości danego narzędzia.
Gorsza użyteczność i niekompatybilność z istniejącymi narzędziami mogą stwarzać problemy, dlatego może być konieczne napisanie oprogramowania interfejsowego lub wtyczek, a także narzędzi do raportowania oraz importowania i eksportowania danych.
Ponadto będziesz musiał przeszkolić siebie i swój zespół, aby podnieść ich kwalifikacje, a zazwyczaj także samodzielnie zapewniać wsparcie dla oprogramowania. Twój zespół będzie jednak lepiej znał sposób działania narzędzia i w dużej mierze będzie w stanie samodzielnie zapewniać sobie wsparcie.
Narzędzie FOSS może pomóc Ci zdobyć doświadczenie z nowym typem narzędzia niewielkim kosztem. Dzięki temu doświadczeniu będziesz w lepszej sytuacji, aby wybrać narzędzie własnościowe na dłuższy czas.
Ćwiczenie z wyboru narzędzia
Jeśli szukasz narzędzia do zarządzania testami, które wesprze Twój obecny lub niedawno realizowany projekt oraz znaną Ci aplikację, na podstawie obszarów funkcjonalnych omówionych powyżej w dyskusji na temat narzędzi do zarządzania testami utwórz listę 15–20 funkcji, które są:
- Obowiązkowe
- Pożądane
Może to obejmować możliwości funkcjonalne, integracje, nacisk na łatwość użytkowania, wsparcie lub dużą bazę użytkowników, a także fora internetowe i sekcje FAQ. Jeśli masz już wdrożone jakieś narzędzie, nie wybieraj właśnie jego.
Korzystając z treści swoich wymagań, przeszukaj Bazę wiedzy o narzędziach, aby znaleźć trzy narzędzia (w tym produkt własnościowy i produkt FOSS), które wydają się odpowiadać Twoim wymaganiom. Korzystając z opisów funkcji tych narzędzi, utwórz tabelę porównującą funkcje trzech produktów. Dodaj czwartą kolumnę dotyczącą narzędzia, którego faktycznie używasz — do celów porównawczych.
- Jak narzędzia wypadają pod względem funkcji?
- Jakich funkcji brakuje narzędziu lub narzędziom FOSS w porównaniu z narzędziami własnościowymi?
- Ile istnieje narzędzi, które w szerokim zakresie spełniają Twoje wymagania?
- Ile czasu, Twoim zdaniem, trzeba byłoby poświęcić na analizę narzędzi, aby przygotować krótką listę, powiedzmy, trzech z nich?
Zapisz się do biuletynu The QA Lead, aby otrzymywać powiadomienia o publikacji nowych części serii. Te wpisy są fragmentami kursu Paula Przywództwo w testowaniu — gorąco polecamy go osobom, które chcą dokładniej zgłębić ten i inne tematy. Jeśli się zdecydujesz, użyj naszego ekskluzywnego kodu rabatowego QALEADOFFER, aby otrzymać $60 zniżki od pełnej ceny kursu!
Ucz się od innych testerów, słuchając naszych podcastów lub zaglądając na nasze blogi. Oto jeden z materiałów, z którego — naszym zdaniem — dowiesz się bardzo dużo: JAK UMIEJĘTNOŚCI TESTOWANIA UCZYNIŁY MNIE LEPSZYM PROGRAMISTĄ AUTOMATYZACJI
