Liczba krok\u00f3w generowa\u0142a wysok\u0105 ilo\u015b\u0107 b\u0142\u0119d\u00f3w skryptowych odkrywanych w trakcie przegl\u0105du test\u00f3w przez zesp\u00f3\u0142 walidacyjny. Nale\u017ca\u0142y do nich ma\u0142e liter\u00f3wki, ale tak\u017ce b\u0142\u0119dy zapis\u00f3w program\u00f3w do zarz\u0105dzania testami np. MF ALM.<\/p>\n\n\n\n
Testy skryptowe cz\u0119sto wymaga\u0142y tworzenia kopii dla r\u00f3\u017cnych typ\u00f3w test\u00f3w<\/strong>, kt\u00f3rych nie da\u0142o si\u0119 sparametryzowa\u0107. Pojedyncze testy regresyjne sprawdza\u0142y jedn\u0105 \u015bcie\u017ck\u0119 przej\u015bcia scenariusza testowego, wymagaj\u0105c tworzenia kilku podobnych scenariuszy dla r\u00f3\u017cnych kryteri\u00f3w akceptacji jednego wymagania.<\/p>\n\n\n\n Jak jednak przyst\u0105pi\u0107 do przedefiniowania test\u00f3w skryptowych, aby zwi\u0119kszy\u0107 wydajno\u015b\u0107 testowania w \u015brodowiskach walidowanych bior\u0105c pod uwag\u0119 wysokie ryzyka biznesowe i wp\u0142yw na zgodno\u015b\u0107 z procedurami?<\/p>\n\n\n\n Na to pytanie odpowiada Exploratory Testing<\/strong> zastosowany wraz z Risk Based Approach<\/strong>.<\/p>\n\n\n\n Testowanie eksploracyjne stawia nacisk na zwi\u0119kszenie wydajno\u015bci testowania, na eksplorowanie r\u00f3\u017cnych mo\u017cliwych \u015bcie\u017cek sprawdzenia kryteri\u00f3w akceptacji uwalniaj\u0105c kreatywno\u015b\u0107 tester\u00f3w i buduj\u0105c ich zaanga\u017cowanie.<\/p>\n\n\n\n Testy te dziel\u0105 si\u0119 w g\u0142\u00f3wnej mierze na:<\/p>\n\n\n\n Jak wiemy, wprowadzenie RBA generuje stworzenie szacunku ryzyk funkcjonalnych (FRA)<\/strong> dla ka\u017cdego wymagania, zar\u00f3wno biznesowego \u2013 User Story, jak i wymagania funkcjonalnego \u2013 Functional Requirement.<\/p>\n\n\n\n Opisz\u0119 ten proces w przyk\u0142adowym projekcie, w kt\u00f3rym (wraz z walidacj\u0105 i analitykiem biznesowym) wprowadzili\u015bmy podej\u015bcie eksploracyjne.<\/p>\n\n\n\n W projekcie tym wprowadzili\u015bmy wi\u0119cej zmian ni\u017c tylko bazowanie na podej\u015bciu eksploracyjnym. B\u0119d\u0105c konfigurowalnym, prewalidowanym systemem zewn\u0119trznego dostawcy, system ten by\u0142 podatny na wprowadzenie r\u00f3wnie\u017c dodatkowego wyznacznika ryzyka<\/strong> \u2013 typu implementacji konfiguracji systemu, okre\u015blanego przez programist\u00f3w.<\/p>\n\n\n\n Projekt, w kt\u00f3rym bior\u0119 udzia\u0142, opiera si\u0119 na \u015brodowiskach stworzonych i zwalidowanych pod k\u0105tem farmacji<\/strong> z ju\u017c stworzonymi komponentami dla klinicznych system\u00f3w zarz\u0105dzania.<\/p>\n\n\n\n Dokumentacja Veeva opisuje wszystkie wdro\u017cone funkcjonalno\u015bci i zatwierdza je podpisami walidator\u00f3w. System posiada bardzo du\u017c\u0105 cz\u0119\u015b\u0107 wymaganych, ju\u017c dzia\u0142aj\u0105cych, funkcjonalno\u015bci, kt\u00f3re mo\u017cna przyj\u0105\u0107 jako standardowe \u2013 Out of the Box. S\u0105 tak\u017ce funkcjonalno\u015bci konfigurowalne \u2013 niewymagaj\u0105ce tworzenia nowego kodu, tylko modyfikacj\u0119 ju\u017c istniej\u0105cych konfiguracji.<\/p>\n\n\n\n Maj\u0105c na uwadze ryzyka biznesowe, wp\u0142yw na \u017cycie pacjenta oraz typy implementacji mogli\u015bmy rozrysowa\u0107 poni\u017cszy schemat Functional Risk Assessment.<\/strong><\/p>\n\n\n\n Dzi\u0119ki prewalidacji oraz szerokiemu podzia\u0142owi typ\u00f3w implementacji mogli\u015bmy wprowadzi\u0107 nowe systemowe testy akceptacyjne oparte o podej\u015bcie eksploracyjne:<\/p>\n\n\n\n Dzi\u0119ki powy\u017cszym informacjom \u0142atwo okre\u015bli\u0107, kiedy wprowadzenie test\u00f3w eksploracyjnych jest mo\u017cliwe. Dotyczy to g\u0142\u00f3wnie niskich i \u015brednich poziom\u00f3w ryzyka, ale r\u00f3wnie\u017c wysokiego ryzyka przy prostej implementacji konfiguracji.<\/p>\n\n\n\n Mo\u017cna to przedstawi\u0107 w poni\u017cszy spos\u00f3b:<\/p>\n\n\n\n Implementacja konfiguracji w systemie prewalidowanym to tak naprawd\u0119 zmienianie ju\u017c istniej\u0105cych blok\u00f3w kodu (liczby znak\u00f3w w istniej\u0105cych polach, ich widoczno\u015bci, ich obowi\u0105zkowo\u015bci) lub nawet niezmienianie ich wcale (zwyk\u0142a konfiguracja), co sprawia, \u017ce ryzyko wprowadzenia test\u00f3w eksploracyjnych jest ni\u017csze ni\u017c w przypadku tworzenia nowego kodu. Co wi\u0119cej, gdy wymagania wymuszaj\u0105 stworzenie nowego kodu przy wysokich ryzykach matryca implementacji wskazuje na zastosowanie standardowego, skryptowego podej\u015bcia.<\/p>\n\n\n\n Najwa\u017cniejszym profitem jest czas, kt\u00f3ry zyskujemy na wczesne testowanie, dzi\u0119ki zmniejszeniu liczby powstaj\u0105cych test\u00f3w oraz dzi\u0119ki ich niskiemu skomplikowaniu.<\/p>\n\n\n\n Projekty mog\u0105 zyska\u0107 mn\u00f3stwo czasu dzi\u0119ki kr\u00f3tkim testom posiadaj\u0105cym maksymalnie kilka krok\u00f3w, \u0142atwym do przejrzenia zar\u00f3wno przez kierownika test\u00f3w jak i zesp\u00f3\u0142 walidacyjny.<\/p>\n\n\n\n Czas tworzenia test\u00f3w w moim projekcie zosta\u0142 zmniejszony nawet o 90%<\/strong>, dzi\u0119ki czemu zyskali\u015bmy cenne chwile na dok\u0142adne przyjrzenie si\u0119 wymaganiom i testowanie nieformalne przed g\u0142\u00f3wnym cyklem test\u00f3w akceptacyjnych.<\/p>\n\n\n\n Na pewno byli\u015bmy w stanie zauwa\u017cy\u0107 liczb\u0119 krok\u00f3w skryptowych w naszych projektach, wahaj\u0105c\u0105 si\u0119 od 10 do nawet 150 krok\u00f3w. Maj\u0105c na uwadze \u015brednio nawet 20 krok\u00f3w na test, przy pierwszym kroku testowym dla unscripted exploratory, wysi\u0142ek, kt\u00f3ry wk\u0142ada zesp\u00f3\u0142 testowy i kierownik test\u00f3w oraz walidacja, zmniejsza si\u0119 kilkukrotnie<\/strong>. Zyskujemy natomiast czas i energi\u0119 na dog\u0142\u0119bne testowanie wymaga\u0144, zamiast pisania tysi\u0119cy skrypt\u00f3w.<\/p>\n\n\n\n Testerzy s\u0105 w stanie sprawdza\u0107 kryteria akceptacji, dzi\u0119ki przeprowadzaniu eksploracyjnych sesji, kt\u00f3re s\u0105 du\u017co bli\u017csze procesowi u\u017cytkownik\u00f3w ko\u0144cowych, nie s\u0105 ograniczeni jedn\u0105 \u015bcie\u017ck\u0105 wykonywania testu. W zwi\u0105zku z tym s\u0105 w stanie odkry\u0107 du\u017co wi\u0119cej b\u0142\u0119d\u00f3w nieoczywistych dla analityk\u00f3w biznesowych i programist\u00f3w.<\/p>\n\n\n\n Zwi\u0119kszenie czasu na testowanie systemu zamiast d\u0142u\u017c\u0105cego si\u0119 i nu\u017c\u0105cego procesu tworzenia skrypt\u00f3w testowych, wp\u0142ywa pozytywnie na motywacj\u0119 zespo\u0142u, zwi\u0119ksza ich efektywno\u015b\u0107 i nie ogranicza wyobra\u017ani.<\/p>\n\n\n\n To wszystko wygl\u0105da a\u017c za dobrze, gdzie zatem le\u017cy ryzyko? Przyjrzyjmy si\u0119 temu blizej.<\/p>\n\n\n\n Jedn\u0105 z wi\u0119kszych trudno\u015bci w projektach mo\u017ce by\u0107 w\u0142a\u015bnie okre\u015blenie ryzyka dla poszczeg\u00f3lnych funkcjonalno\u015bci. Mo\u017cna bra\u0107 pod uwag\u0119 \u0142\u0105czenie ryzyka biznesowego z ryzykiem zgodno\u015bci (business + compliance risks >>> overall risk<\/strong>) oraz skomplikowanie implementacji danej funkcjonalno\u015bci, opisane przez deweloper\u00f3w.<\/p>\n\n\n\n Je\u015bli projekt nie posiada du\u017cej liczby niskich i \u015brednich ryzyk i\/lub posiada funkcjonalno\u015bci, kt\u00f3re wymagaj\u0105 implementacji skomplikowanego kodu, testy unscripted b\u0119d\u0105 zawarte w niskim procencie wymaga\u0144 i przez to nie zmniejsz\u0105 liczby test\u00f3w skryptowych a\u017c tak, jakby to by\u0142o mo\u017cliwe przy ni\u017cszych ryzykach.<\/p>\n\n\n\n Mitygacj\u0105 tego ryzyka mo\u017ce by\u0107 odpowiednie oszacowania ryzyk systemu wraz z zespo\u0142em walidacyjnym<\/strong>.<\/p>\n\n\n\n Innym ryzykiem jest jako\u015b\u0107 wymaga\u0144 systemowych. Jako \u017ce testy unscripted posiadaj\u0105 tylko jeden krok weryfikuj\u0105cy funkcjonalno\u015b\u0107, samo wymaganie musi by\u0107 wysokiej jako\u015bci<\/strong>, aby tester by\u0142 w stanie dok\u0142adnie sprawdzi\u0107 kryteria akceptacji w eksploracyjnej sesji testowej.<\/p>\n\n\n\n Gdy specyfikacja systemu jest niskiej jako\u015bci, testerzy mog\u0105 mie\u0107 problem z wykonywaniem test\u00f3w. Szczeg\u00f3lnie, gdy zesp\u00f3\u0142 testowy si\u0119 zmienia i nowi testerzy nie posiadaj\u0105 tak du\u017cej wiedzy o systemie. Na szcz\u0119\u015bcie odpowiednie wsparcie tester\u00f3w poprzez przygotowanie dem funkcjonalno\u015bci i wystarczaj\u0105cej ilo\u015bci nagra\u0144 przekaz\u00f3w wiedzy, mo\u017ce zmniejszy\u0107 ryzyko brak\u00f3w w wiedzy i zrozumienia systemu.<\/p>\n\n\n\n W mojej opinii podej\u015bcie eksploracyjne jest du\u017co bardziej op\u0142acalne ni\u017c podej\u015bcie tylko i wy\u0142\u0105cznie skryptowe. Dzi\u0119ki implementacji matrycy ryzyk \u0142atwo jest wskaza\u0107 odpowiedni typ testu dla danej funkcjonalno\u015bci.<\/p>\n\n\n\n Rezultatem poprawnego u\u017cycia test\u00f3w eksploracyjnych jest dostarczenie jak najlepszej jako\u015bci systemu przy jednoczesnym zachowaniu bezpiecze\u0144stwa, zwi\u0119kszeniu wydajno\u015bci i zmniejszeniu ilo\u015bci pracy nad dokumentacj\u0105.<\/p>\n\n\nPrzedefiniowanie test\u00f3w skryptowych<\/h2>\n\n\n\n
\n
Proces wprowadzenia podej\u015bcia eksploracyjnego<\/h2>\n\n\n\n
Czym jest prewalidowany system?<\/h3>\n\n\n\n
![\"Macierz](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2021\/11\/Ryc.-1-2.png\")
<\/a>Podej\u015bcie eksploracyjne w testach akceptacyjnych<\/h3>\n\n\n\n
\n
Kiedy wprowadzenie test\u00f3w eksploracyjnych jest mo\u017cliwe?<\/h3>\n\n\n\n
<\/a><\/figure>\n\n\n\nJak w praktyce wypada exploratory testing?<\/h2>\n\n\n\n
<\/a>Ryzyko zwi\u0105zane z wprowadzeniem test\u00f3w eksploracyjnych<\/h2>\n\n\n\n
Okre\u015blenie ryzyka dla funkcjonalno\u015bci<\/h3>\n\n\n\n
Jako\u015b\u0107 wymaga\u0144 systemowych<\/h3>\n\n\n\n
Podsumowanie<\/h2>\n\n\n\n