Redakcja
Testowanie jest ciągle istotną czynnością w cyklu rozwoju oprogramowania. Jest to akt uruchomienia oprogramowania w celu sprawdzenia, czy zachowuje się ono zgodnie z przeznaczeniem i zidentyfikowania możliwych usterek. Badania wykazują, że testowanie stanowi ponad 50% kosztów rozwoju produktu. Poza tym wiele wysiłku i nacisku położono obecnie na zadania związane z automatyzacją w celu obniżenia kosztów i udziału czynnika ludzkiego w działaniach testowania oprogramowania.
Testowanie jest jednak nadal czynnością w dużej mierze opartą na umiejętnościach człowieka. Dlatego też efektywne sposoby testowania produktów oprogramowania w celu zapewnienia jakości będą wymagały lepszego i bardziej wszechstronnego zrozumienia odczuć, percepcji i motywacji testerów określanych czasami jako doświadczenie testera (ang. Tester eXeprience - TX). Zatem im lepsze doświadczenie testera w trakcie procesu testowania oprogramowania, tym lepszy wynik. TX można zdefiniować jako sposób uchwycenia tego, jak testerzy myślą i czują w związku ze swoimi działaniami w środowisku testowania oprogramowania, przy założeniu, że poprawa doświadczenia testera ma pozytywny wpływ na kontrolę jakości.
Oczywiście postulat istnienia specyficznego TX wynika wprost z ewolucji doświadczenia użytkownika (UX), a skoro zapuszczamy się już w takie rejony, to musimy do równania dołączyć również doświadczenia programisty (DX).
User Experience (UX) – bada wszystkie aspekty interakcji osoby z danym systemem IT; często koncentruje się na interfejsie użytkownika i powiązanych koncepcjach; projektowanie wizualne, projektowanie interakcji itd.
Doświadczenie programisty (DX) – można postrzegać jako podzbiór UX (programiści to też użytkownicy) skupiający się na obniżeniu bariery dla programistów w integracji z danym systemem: dokumentacja, metadane, dostosowanie techniczne itd.
Doświadczenie testera (TX) – ma na celu zapewnienie testerom jak najlepszych wrażeń podczas testowania/debugowania systemu.
Nic dziwnego, że te trzy elementy w pewnym stopniu się pokrywają.
Musimy doprecyzować jeszcze aspekt samych kompetencji testerskich. Oczywiście doświadczenia testowanego produktu to jedno, ale ważnym aspektem jest również głębsze od standardowego użytkownika zrozumienie działania systemu. Testerzy często potrzebują wglądu w system „zza kulis”, którego zewnętrzni użytkownicy nie potrzebują i często nie powinni mieć.
Testerzy są (miejmy nadzieję) częścią podstawowego procesu i zespołu programistycznego i mają pełny wgląd w to, co testują od pierwszego dnia. Testerzy muszą oceniać wymagania biznesowe i techniczne zarówno z perspektywy użytkownika końcowego, jak i z perspektywy testowalności; tzn. często nie tylko oceniają jakość UX i DX systemu, ale również są od nich zależni w swojej własnej pracy.
Jako testowalność rozumiemy łatwość testowania produktu i można odwołać to do cech oprogramowania jak:
- modułowość - dobrze zmodularyzowany system pozwala na testowanie każdego modułu osobno – z możliwym mockingiem/stubbingiem zewnętrznych zależności
- transparentność - posiadanie wglądu w system i jego architektury jest kluczowe dla zrozumienia, jak działa i gdzie mogą leżeć potencjalne problemy
- obserwowalność - uzyskiwanie ciągłych informacji o stanie systemu podczas testowania jest kluczowe dla możliwości oceny wyników i warunków występowania defektów
- powtarzalność - możliwość niezawodnego odtworzenia zachowania zidentyfikowanego podczas testowania jest kluczowa dla raportowania i rozwiązywania problemów.
Istnieją też inne aspekty TX, które należy wziąć pod uwagę, na przykład:
- włączenie testerów i QA w cały cykl życia produktu: wymagania, architektura/rozwój i operacje
- umożliwienie testerom poświęcenia szczególnej uwagi wymaganiom
- jasne zdefiniowanie głównej persony (grupę użytkowników docelowych) i oczekiwane wykorzystanie systemu – pozwalając testerom zrozumieć, dla kogo przeznaczona jest aplikacja i kwestionować, czy ten cel zostanie osiągnięty
- pełny dostęp do kluczowych osób w zespole
- istnienie dedykowanych środowisk testowych.
Zauważmy, że wszędzie tam, gdzie zastępujemy TX przez narzędzia automatyzacji lub analizy statycznej i dynamicznej obniżamy szanse na wykrycie w procesie problemów, które mogą pojawić się później w ramach UX.
Można założyć, że zbudowanie poprawnego środowiska dla TX to zwiększenie szans na lepsze testowanie oprogramowania, a co za tym idzie pozytywne oceny w ramach UX.
