Jednym z kluczowych błędnych przekonań we współczesnym środowisku testowania jest to, że testowanie na produkcji wymaga tylko trzech zestawów umiejętności: znajomości procesów, znajomości narzędzi do testów automatycznych oraz zdolności zarządzania incydentami. Są one ważne, ale uderzający jest brak — nie tylko na tej liście, lecz także w świadomości osób rekrutujących — czegoś, co można uznać za najbardziej fundamentalne:
Umiejętność zaprojektowania praktycznego testu dla środowisk produkcyjnych.
Byłoby to komiczne, gdyby nie było tak alarmujące, że niemal żadna organizacja nie traktuje wiedzy z zakresu kluczowych umiejętności zapewniania jakości jako priorytetu podczas wdrażania strategii testowania na produkcji.
Niezależnie od tego, czy test jest wykonywany ręcznie, czy za pomocą automatyzacji w działającym systemie produkcyjnym, najpierw trzeba wiedzieć, jak go zaprojektować, aby dostarczał użytecznych informacji bez zakłócania doświadczenia użytkownika, prawda?
Byłoby to komiczne, gdyby nie było tak alarmujące, że niemal żadna organizacja nie traktuje wiedzy z zakresu projektowania testów jako priorytetu podczas wdrażania strategii testowania na produkcji. Niezależnie od tego, czy test jest wykonywany ręcznie w kontrolowanym środowisku, czy automatycznie w działającym systemie produkcyjnym, najpierw trzeba wiedzieć, jak go zaprojektować, aby dostarczał użytecznych informacji bez zakłócania doświadczenia użytkownika, prawda?
Wykluczenie wiedzy z zakresu projektowania testów z podejścia do testowania na produkcji wiąże się z jednym oczywistym problemem:
Czy nie jest niezbędne, aby osoba wdrażająca testy w środowisku produkcyjnym rozumiała, co składa się na wartościowy test?
Skoro automatyzacja źle zaprojektowanych testów na produkcji szybciej dostarcza niewiarygodnych danych i stwarza niepotrzebne ryzyko? A bycie „zwinnym” podczas niekompetentnego testowania na produkcji nie wydaje mi się rzeczywistym usprawnieniem — chyba że dla kierownika zespołu Scrum.
Znaczenie i dyscyplina projektowania testów, zwłaszcza w kontekście testowania na produkcji, od dawna czekają na przywrócenie należnego im miejsca. Niech ten tekst będzie moim wkładem w te działania.
Co jest niezbędne do skutecznego testowania na produkcji?
Pierwszym krokiem do opanowania testowania na produkcji jest wprowadzenie kilku istotnych rozróżnień, które większość osób zajmujących się zapewnianiem jakości niewątpliwie intuicyjnie już zna, lecz które rzadko są przedstawiane w sposób systematyczny w kontekście testowania produkcyjnego.
Przyjrzyjmy się tym fundamentalnym pojęciom, które odmienią Twoje podejście do testowania na produkcji.
Jawna a niejawna funkcjonalność w środowiskach produkcyjnych
Zacznijmy od kluczowego rozróżnienia między jawną a niejawną funkcjonalnością podczas testowania na produkcji.
Ta pierwsza to to, co większość z nas rozumie jako „funkcjonalność”. Odnosi się do funkcji i możliwości formalnie określonych przez dział produktu, których formalna specyfikacja wyznacza kierunek implementacji w dziale inżynieryjnym. Podczas testowania na produkcji te jawne funkcje są zazwyczaj przedmiotem monitorowania i działania narzędzi obserwowalności.
Z tego powodu testowanie jawnej funkcjonalności na produkcji może wydawać się proste, ale nawet w przypadku dobrze zdefiniowanych funkcji tak nie jest, co zobaczymy później. Przynajmniej poziom szczegółowości właściwy jawnej funkcjonalności ułatwia zbudowanie wokół niej szkieletu testów produkcyjnych (lub iluzji takiego szkieletu).
Niejawna funkcjonalność w środowisku produkcyjnym to zupełnie inna kwestia.
Obejmuje zachowania i reakcje na dane wejściowe pochodzące od użytkownika lub ze środowiska, które nie zostały formalnie zdefiniowane ani przewidziane. Brak odpowiedniego zaprojektowania testów dla tej niejawnej funkcjonalności na produkcji jest zdecydowanie najczęstszym źródłem większości krytycznych błędów wykrywanych po wdrożeniu produktu (drugim jest niewystarczające testowanie w nietypowych środowiskach sprzętowych, programowych i urządzeniowych).
Innymi słowy:
Testowanie niejawnej funkcjonalności na produkcji wymaga znacznej pomysłowości i wyobraźni. To prawdziwie kreatywna część strategii testowania produkcyjnego.
Testowanie niejawnej funkcjonalności w środowiskach produkcyjnych wymaga pewnej dozy diabelskiej przebiegłości, aby osiągnąć w nim biegłość, a niestety nie można się jej nauczyć za pomocą standardowych procesów zapewniania jakości.
Żadna ilość metodyki zwinnej ani automatycznych struktur testowych nie nauczy Cię skutecznego testowania niejawnej funkcjonalności na produkcji, ale właściwe projektowanie testów może temu sprzyjać.
Jak zatem zdefiniować strategię projektowania testów dla niejawnej funkcjonalności w środowisku produkcyjnym? Na szczęście jest to możliwe. Zanim jednak bezpośrednio przejdziemy do tego pytania, przyjrzyjmy się kilku kolejnym istotnym rozróżnieniom, które mają kluczowe znaczenie dla skutecznego testowania na produkcji.
Testowanie pozytywne a negatywne
Najważniejszy wniosek: Podczas testowania na produkcji zarówno testy pozytywne, jak i negatywne wymagają szczególnego podejścia, wykraczającego poza tradycyjne metody zapewniania jakości.
Większość osób pracujących w obszarze zapewniania jakości rozumie podstawową różnicę między tymi dwoma rodzajami testów:
- Testowanie pozytywne na produkcji: Weryfikowanie, czy funkcje działają zgodnie z założeniami w środowiskach produkcyjnych
- Testowanie negatywne na produkcji: Strategiczne testowanie reakcji systemu na nieoczekiwane dane wejściowe bez zakłócania pracy rzeczywistych użytkowników
Dlaczego testowanie na produkcji jest inne
Choć te rozróżnienia są jasne pod względem koncepcyjnym, testowanie na produkcji wiąże się z wyjątkowymi wyzwaniami:
- Wyższa stawka: Przypadki brzegowe dotyczą rzeczywistych klientów i operacji biznesowych
- Złożoność rzeczywistego świata: Zachowania użytkowników rzadko przebiegają według przewidywalnych wzorców
- Ciągłość działania firmy: Testowanie nie może zakłócać normalnego funkcjonowania
Poza specyfikacją
Specyfikacje rzadko dostarczają wszystkiego, co jest potrzebne do skutecznego testowania na produkcji:
Nadmierne uzależnienie od specyfikacji — niezależnie od tego, czy pochodzi ona od zespołu produktowego, czy inżynieryjnego — ogranicza sposób myślenia. Jest to szczególnie problematyczne podczas testowania na produkcji, gdzie wzorce rzeczywistego użytkowania często odbiegają od specyfikacji.
Ilustruje to zjawisko, które nazywam „błędem empirycznym”: oczekiwaniem, że coś wprost powie ci, co masz zrobić, zanim będziesz w stanie to zrozumieć.
Skuteczne projektowanie testów dla środowisk produkcyjnych wymaga:
- Odpowiedniej parametryzacji funkcjonalności
- Logicznego rozumowania o tym, co jest możliwe
- Uwzględnienia interakcji zarówno użytkownika, jak i środowiska
Przykład z rzeczywistego świata: nieoczekiwane zachowania
W czasach kredy w historii oprogramowania (czyli w latach 80.) testowałem oprogramowanie do konwersji dokumentów i odkryłem zaskakujące możliwości:
Pokaż obraz
Klasyczny przykład: W programie WordPerfect można było wstawić polecenie odstępu między wierszami w środku akapitu, wpływając tylko na kolejne wiersze i tworząc akapity z dwiema różnymi wartościami odstępu.
Współczesne odpowiedniki podczas testowania na produkcji:
- Nieoczekiwane kombinacje uprawnień użytkowników w aplikacjach chmurowych
- Nieprzewidziane sekwencje żądań API w architekturach mikrousług
- Wyścigi w środowiskach o wysokiej współbieżności
Przyjrzyjmy się teraz trzem kluczowym parametrom, które usprawnią podejście do testowania na produkcji:
1. Testowanie zakresu funkcjonalności
Definicja: Określanie, w jaki sposób użytkownicy mogą wdrażać funkcje w kontekstach lub w sposób, których nigdy nie przewidziano podczas projektowania.
Dlaczego ma to znaczenie podczas testowania
Nie wszystkie ograniczenia są przewidywane podczas tworzenia oprogramowania. W środowiskach produkcyjnych takie przeoczenie może mieć poważne konsekwencje.
Poza prostą walidacją
Podczas testowania na produkcji należy uwzględnić następujące granice:
Pamiętaj: Walidacja funkcji na produkcji nie polega tylko na potwierdzeniu, że działa ona zgodnie z założeniami, lecz także na sprawdzeniu, czy nie można jej użyć w niezamierzony sposób, który mógłby wpłynąć na stabilność lub bezpieczeństwo systemu.
Have an account? Log In
2. Testowanie przerwania przepływu pracy w systemach działających na żywo
Ostrzeżenie: To podejście zakłada, że już testujesz zdefiniowane przepływy pracy na produkcji. Jeśli nie, najpierw zajmij się tymi podstawami!
Poza „szczęśliwą ścieżkę”
Podczas testowania na produkcji przeanalizuj następujące krytyczne zakłócenia przepływu pracy:
✅ Przerwane przepływy pracy: Proces został rozpoczęty, ale nigdy go nie ukończono
✅ Anulowane operacje: Użytkownik jawnie anuluje proces w jego trakcie
✅ Procesy uruchomione ponownie: Użytkownik wielokrotnie próbuje wykonać tę samą czynność
✅ Cofanie się: Użytkownik wraca do wcześniejszych kroków, podając inne dane wejściowe
Wskazówki dotyczące wdrażania testów na produkcji
Stosuj techniki, takie jak przełączniki funkcji, aby bezpiecznie kontrolować zakres udostępnienia tych testów w środowiskach produkcyjnych.
Zastosowania w rzeczywistym świecie
Wskazówka eksperta: Te scenariusze rzadko są uwzględniane w specyfikacjach, ale odzwierciedlają rzeczywiste zachowania użytkowników na produkcji.
3. Sekwencyjność w testowaniu produkcyjnym
Wyzwanie: W systemach produkcyjnych z wieloma współbieżnymi procesami kolejność operacji może prowadzić do nieoczekiwanych awarii, które trudno odtworzyć w środowiskach testowych.
Dwa krytyczne wzorce sekwencyjności
Warunki poprzedzające przyczyniające się do awarii
Pokaż obraz
- Definicja: Zdarzenia, które muszą wystąpić przed procesem kończącym się awarią
- Charakterystyka: Mogą ujawnić się dopiero po określonych sekwencjach, których naturalne wystąpienie zajmuje kilka dni
- Przykład w środowisku produkcyjnym: Zmodyfikowanie uprawnień użytkownika → wygaśnięcie pamięci podręcznej → wywołanie określonego interfejsu API
Późniejsze warunki przyczyniające się do awarii
- Definicja: Awarie, które stają się widoczne dopiero w wyniku późniejszych interakcji
- Przejaw: Awaria pozostaje ukryta aż do wykonania późniejszej operacji
- Przykład w środowisku produkcyjnym: Uszkodzenie danych zachodzi po cichu, dopóki nie zostanie wygenerowany raport
Dlaczego jest to tak trudne?
Określenie zakresu testowania sekwencyjności w środowisku produkcyjnym wymaga:
- Dogłębnej znajomości interakcji między systemami
- Modelowania przejść stanów dla złożonych procesów
- Zrozumienia zarówno zamierzonych, jak i niezamierzonych kombinacji stanów
„Podobnie jak te dwie wartości odstępu między wierszami w jednym akapicie, te nieoczekiwane stany mogą siać spustoszenie w środowiskach produkcyjnych.”
Niezbędne narzędzia do testowania sekwencyjności w środowisku produkcyjnym
- Narzędzia do inżynierii chaosu służące do celowego wprowadzania kontrolowanych awarii
- Narzędzia do obserwowalności służące do śledzenia zmian stanów w różnych systemach
- Śledzenie rozproszone w celu monitorowania ścieżek żądań przechodzących przez mikrousługi
Najważniejszy wniosek: Problemy z sekwencyjnością są jednym z najbogatszych źródeł poważnych błędów we współczesnych systemach produkcyjnych. Nadaj temu aspektowi priorytet w swojej strategii testowania.
Najważniejszy wniosek
Przełączniki funkcji przekształcają testowanie w środowisku produkcyjnym z ryzykownej praktyki w kontrolowany proces oparty na danych. Dzięki oddzieleniu wdrożenia od wydania oraz zapewnieniu możliwości natychmiastowego wycofania zmian tworzą siatkę bezpieczeństwa, która umożliwia zespołom walidowanie oprogramowania w rzeczywistych warunkach bez pogarszania doświadczeń użytkowników ani stabilności systemu.
Platformy zarządzania funkcjami w testowaniu produkcyjnym
Platformy zarządzania funkcjami przekształciły testowanie w środowisku produkcyjnym z ryzykownego przedsięwzięcia w kontrolowany, systematyczny proces. Jednak wiele organizacji nie wykorzystuje skutecznie tych narzędzi w ramach swojej strategii projektowania testów.
Ewolucja zarządzania ryzykiem w środowisku produkcyjnym
Tradycyjne podejścia do testowania w środowisku produkcyjnym opierały się na decyzjach binarnych — funkcja była aktywna dla wszystkich albo dla nikogo. Platformy zarządzania funkcjami zasadniczo zmieniają ten paradygmat:
- Szczegółowa kontrola: Testowanie funkcji z określonymi segmentami użytkowników zamiast wdrożeń typu „wszystko albo nic”
- Natychmiastowe usuwanie problemów: Wyłączanie problematycznych funkcji bez wdrażania kodu ani wycofywania zmian
- Stopniowe zwiększanie zasięgu: Stopniowe zwiększanie liczby użytkowników korzystających z funkcji na podstawie danych o wydajności w czasie rzeczywistym
Więcej niż proste przełączniki funkcji
Choć podstawowe przełączniki funkcji istnieją od lat, nowoczesne platformy zarządzania funkcjami zapewniają kluczowe możliwości, które zmieniają testowanie produkcyjne:
Po prawidłowym zintegrowaniu ze strategią projektowania testów platformy zarządzania funkcjami umożliwiają:
- Ukierunkowane ograniczanie ryzyka — ograniczanie ekspozycji na nowe funkcje do określonych segmentów użytkowników
- Walidacja z udziałem rzeczywistych użytkowników — testowanie z rzeczywistymi użytkownikami zamiast z użyciem syntetycznych danych testowych
- Natychmiastowe usuwanie problemów — rozwiązywanie problemów bez awaryjnych wdrożeń ani wycofywania zmian
Integracja z narzędziami do obserwowalności
Prawdziwa siła platform do zarządzania funkcjami ujawnia się, gdy są one zintegrowane z systemami obserwowalności i monitorowania:
Tradycyjne podejście:
- Wykrywanie problemów po pełnym wdrożeniu
- Ręczna weryfikacja wyników testów
- Analiza po incydencie
Integracja z zarządzaniem funkcjami:
- Korelowanie aktywacji funkcji ze wskaźnikami systemowymi
- Automatyczne monitorowanie wydajności dla każdej flagi funkcji
- Wgląd w czasie rzeczywistym w wpływ funkcji
Wpływ w świecie rzeczywistym: transformacja testowania na produkcji
Organizacje wdrażające platformy do zarządzania funkcjami zgłaszają znaczące korzyści:
- Zmniejszenie dotkliwości incydentów: „Możemy testować funkcje na produkcji na długo przed premierą marketingową. A jeśli funkcja powoduje problemy w dniu premiery, możemy po prostu ją wyłączyć za pomocą przełącznika awaryjnego — bez wycofywania zmian.” — Chris Guidry, wiceprezes ds. inżynierii, O'Reilly Media.
- Przyspieszenie cykli wydań: Zespoły w IBM, TrueCar i innych wiodących firmach wykorzystują zarządzanie funkcjami do testowania na produkcji, czerpiąc korzyści z tego, co opisują jako „bezpieczne, pozbawione ceremonii wydania”.
- Lepsze pokrycie testami: Flagi funkcji ujawniają przypadki brzegowe, których nie da się zasymulować w kontrolowanych środowiskach.
Praktyczne wdrożenie w projektowaniu testów
Aby skutecznie uwzględnić platformy do zarządzania funkcjami w strategii projektowania testów:
- Zaprojektuj punkty weryfikacji zgodne z przejściami flag funkcji
- Utwórz scenariusze awaryjne dla każdego komponentu objętego flagą funkcji
- Ustal progi wydajności, które uruchamiają automatyczne wyłączenie funkcji
- Zdefiniuj przypadki testowe specyficzne dla segmentów, aby zweryfikować zachowanie w różnych populacjach użytkowników
- Udokumentuj zależności flag, aby zapobiec awariom kaskadowym
Platformy do zarządzania funkcjami nie zastępują przemyślanego projektowania testów — wzmacniają je. Jakość testowania na produkcji nadal zależy przede wszystkim od tego, jak dobrze zaprojektowano testy.
Typowe pułapki, których należy unikać
Nawet przy solidnym zarządzaniu funkcjami pozostaje kilka wyzwań:
- Dług technologiczny flag — porzucone lub zapomniane flagi tworzące dług technologiczny
- Niewystarczające monitorowanie — brak korelacji stanu flagi z wydajnością systemu
- Nadmierna pewność siebie — przedwczesne ograniczanie testów przedprodukcyjnych
- Wzajemne zależności flag — tworzenie złożonych relacji trudnych do prześledzenia i rozwiązywania problemów
Najważniejsze wnioski
Platformy do zarządzania funkcjami oferują zaawansowane możliwości testowania na produkcji, ale muszą być starannie zintegrowane z ogólną strategią projektowania testów. Organizacje czerpiące największe korzyści nie tylko wdrażają te narzędzia — zasadniczo na nowo przemyślają sposób projektowania testów w środowisku wykorzystującym flagi funkcji.
Odpowiednio wdrożone jako część kompleksowego podejścia do projektowania testów, zarządzanie funkcjami przekształca testowanie na produkcji z koniecznego zła w przewagę konkurencyjną.
Narzędzia do testowania na produkcji: wyzwania związane z wdrożeniem
Chociaż flagi funkcji i platformy zarządzania stanowią podstawę testowania na produkcji, szerszy ekosystem narzędzi wiąże się z własnym zestawem wyzwań wdrożeniowych. Wybór i konfiguracja odpowiednich narzędzi wymagają uważnego uwzględnienia możliwości zespołu, architektury systemu i potrzeb organizacji.
Narzędzia do monitorowania i obserwowalności
Skuteczne testowanie na produkcji zależy od kompleksowego wglądu w zachowanie systemu:
- Monitorowanie wydajności aplikacji (APM)
Korzyści: Zapewnia szczegółowy wgląd w wydajność w całym stosie aplikacji.
Wyzwania: Często wymaga znacznego oprzyrządowania i może generować nadmiar danych, które przytłaczają mniejsze zespoły. - Systemy zarządzania dziennikami
Korzyści: Niezbędne do debugowania i analizy kryminalistycznej podczas testowania na produkcji.
Wyzwania: Bez odpowiednich strategii filtrowania i indeksowania mogą generować przytłaczające ilości danych. - Śledzenie rozproszone
Korzyści: Zapewnia kompleksowy wgląd w architektury mikrousług, od początku do końca.
Wyzwania: Złożoność wdrożenia drastycznie wzrasta w heterogenicznych środowiskach wykorzystujących wiele stosów technologicznych.
Systemy zarządzania alertami
Właściwe alertowanie ma kluczowe znaczenie podczas testowania nowych funkcji na produkcji:
- Platformy agregacji alertów
Korzyści: Konsolidują powiadomienia z wielu systemów monitorowania.
Wyzwania: Doskonale sprawdzają się w zarządzaniu incydentami, ale mogą być uciążliwe, jeśli nie zostaną starannie skonfigurowane w celu uniknięcia zmęczenia alertami. - Systemy reagowania na incydenty
Korzyści: Usprawniają komunikację podczas incydentów na produkcji.
Wyzwania: Aby działać skutecznie, wymagają dobrze zdefiniowanych procedur operacyjnych i punktów integracji; mogą powodować dodatkowe obciążenie w przypadku prostych wdrożeń.
More Articles
Kwestie związane z wdrożeniem
Podczas wdrażania narzędzi do testowania na produkcji zespoły powinny ocenić:
- Wymagania dotyczące skalowalności - Czy narzędzie obsłuży wolumen ruchu i wzrost ilości danych?
- Możliwości integracji - Jak łatwo łączy się z istniejącym łańcuchem narzędzi?
- Zużycie zasobów - Jakie dodatkowe obciążenie wprowadza samo narzędzie?
- Kompetencje zespołu - Czy dysponujecie umiejętnościami potrzebnymi do maksymalnego wykorzystania wartości narzędzia?
- Stosunek sygnału do szumu - Czy można uzyskać wartościowe informacje bez utonięcia w danych?
Typowe problemy podczas wdrażania
- Rozrost liczby narzędzi - Gromadzenie zbyt wielu nakładających się na siebie rozwiązań
- Niepełna instrumentacja - Pomijanie kluczowych punktów monitorowania
- Zmęczenie alertami - Generowanie nadmiernej liczby powiadomień, które zespoły ostatecznie ignorują
- Niewystarczający kontekst - Brak korelacji między metrykami a wpływem na użytkowników
- Wyizolowane silosy danych - Tworzenie odizolowanych systemów monitorowania, które nie udostępniają sobie informacji
Znalezienie właściwej równowagi
Najskuteczniejsze wdrożenia testowania na produkcji zapewniają równowagę między:
- Kompleksowym monitorowaniem a możliwą do opanowania złożonością
- Szczegółowymi informacjami a przeciążeniem informacyjnym
- Zautomatyzowanymi reakcjami a punktami decyzyjnymi wymagającymi udziału człowieka
Wdrażając narzędzia do testowania w środowiskach produkcyjnych, zacznij od niewielkiego zakresu i jasno określonych celów, a następnie stopniowo rozszerzaj pokrycie w miarę zdobywania przez zespół doświadczenia zarówno w zakresie narzędzi, jak i interpretowania uzyskiwanych danych.
Obciążenie, złożoność, opóźnienie
Uwzględnij w projekcie testów makroczynniki systemowe: obciążenie, złożoność i opóźnienie. Czynniki te mogą wpływać na wykonanie lub ukończenie żądania, procesu, lub zdarzenia.
Znaczenie obciążenia systemu powinno być oczywiste. Sposób przetwarzania żądań lub transakcji w okresach wysokiego obciążenia systemu może prowadzić do awarii (na dowolnym etapie procesu transakcji).
Powinno to być standardowym elementem planowania testów. Jak wszyscy wiemy, obciążenie może być również generowane w wyniku samego żądania — na przykład zapytania o dane, które uruchamia przetwarzanie i przesyłanie ogromnych ilości danych.
Złożoność odnosi się tutaj przede wszystkim do złożoności żądań kierowanych do systemu. Złożoność ta może obejmować liczbę określonych warunków (wraz z ich wykluczeniami i wyjątkami), liczbę baz danych (wirtualnych lub innych) zaangażowanych w żądania lub samą topologię przetwarzania systemu.
W kontekście tej dyskusji używam terminu opóźnienie do wskazania przerw czasowych w procesie obsługi żądania, co nie jest jego typowym znaczeniem. Mam tutaj na myśli opóźnienie po stronie użytkownika, a nie opóźnienie odpowiedzi samego systemu.
Innymi słowy, jak zachowuje się funkcja lub możliwość, gdy użytkownik przejdzie do określonego kroku procesu, a następnie pozostaje w nim bezczynny? Czy system przekroczy limit czasu (prawdopodobnie powinien)? Czy powinien wyświetlić użytkownikowi monit? Czy powinien pozostać w tym stanie do końca czasu?
Odpowiedzi na te pytania mogą być zawarte w specyfikacji, ale testowany produkt może nie zachowywać się w ten sposób, co jest właśnie powodem, dla którego w ogóle testujemy.
Role użytkowników
Oczywiście użytkownicy końcowi mogą wchodzić w interakcję z systemami oprogramowania w różnych rolach. Ten sam użytkownik może wchodzić w interakcję z systemem w różnych rolach, zależnie od podejmowanych działań.
Jednak procesy i usługi mogą również mieć różne role i powiązane uprawnienia. W obu przypadkach należy upewnić się, że projektowanie i planowanie testów, niezależnie od tego, czy dotyczą funkcji, czy możliwości, uwzględnia i sprawdza wszystkie możliwe stany ról.
Co dalej?
Szukasz dodatkowych wskazówek dotyczących projektowania testów? Chcesz także rozwijać swoje umiejętności w zakresie rozwoju SaaS i przywództwa?
Zapisz się do naszego newslettera aby otrzymywać najnowsze spostrzeżenia od dyrektorów ds. technologii i aspirujących liderów technologicznych.
Pomożemy Ci skalować działalność w bardziej przemyślany sposób i skuteczniej przewodzić dzięki poradnikom, materiałom i strategiom przygotowanym przez czołowych ekspertów!
