Wprowadzenie
Dzień dobry, użytkownicy Habr. Ostatnio rozwiązywałem zadanie rekrutacyjne na stanowisko QA Lead dla jednej firmy fintech. Pierwsze zadanie, stworzenie planu testów z pełną listą kontrolną i przykładami przypadków testowych do sprawdzenia czajnika elektrycznego, rozwiązuje się trywialnie:
Trudno wymyślić lepszy plan testów z pełną listą kontrolną.
Jednak druga część okazała się pytaniem: „Czy istnieją jakieś problemy, które są wspólne dla wszystkich testerów, utrudniające pracę z większą efektywnością?”.
Pierwsze, co przyszło mi na myśl, to wypisanie wszystkich zauważalnych problemów, z którymi się spotkałem podczas testowania, odrzucenie drobiazgów, a resztę uogólnienie. Szybko jednak zrozumiałem, że metoda indukcyjna odpowie na pytanie, dotyczące nie „wszystkich”, a w najlepszym przypadku jedynie „większości” testerów. Postanowiłem podejść do tego z drugiej strony, dedukcyjnie, i oto, co wyszło.
Definicje
Pierwsze, co zazwyczaj robię, rozwiązując nowe zadanie, to próba zrozumienia, o co w ogóle chodzi, a w tym celu muszę poznać znaczenie słów, którymi jest sformułowane. Kluczowe słowa, które wymagają analizy, to:
- problem
- tester
- praca testera
- efektywność pracy testera
Odwołajmy się do Wikipedii i zdrowego rozsądku:
(gr. πρόβλημα) w szerokim sensie - złożona kwestia teoretyczna lub praktyczna, wymagająca badań, rozwiązania; w nauce - sytuacja kontrowersyjna, występująca w formie przeciwstawnych stanowisk w wyjaśnieniu jakichkolwiek zjawisk, obiektów, procesów i wymagająca adekwatnej teorii do jej rozwiązania; w życiu problem formułowany jest w zrozumiały dla ludzi sposób „wiem co, nie wiem jak”, to znaczy wiadomo, co należy uzyskać, ale nie wiadomo, jak to zrobić. Pochodzi od późnolacińskiego problēma, z greckiego πρόβλημα „rzucone do przodu, postawione z przodu”; od προβάλλω „rzucać do przodu, wystawiać przed sobą; oskarżać”.
Niezbyt wiele sensu, w zasadzie „problem” = „cokolwiek, co trzeba wyjaśnić”.
— specjalista (nie będziemy dzielić na rodzaje, ponieważ interesują nas wszyscy testerzy), uczestniczący w testowaniu komponentu lub systemu, którego działanie skutkuje:
— zbiór działań związanych z testowaniem.
(łac. effectivus) — stosunek między uzyskanym wynikiem a użytymi zasobami (:2015).
— konsekwencja łańcucha (serii) działań (wynik) lub zdarzeń, wyrażonych jakościowo lub ilościowo. Możliwe wyniki obejmują korzyść, niedogodność, zysk, stratę, wartość i zwycięstwo.
Jak w przypadku "problemu", mało to mówi: coś, co powstało w wyniku pracy.
— ilościowo mierzalna zdolność do wykonywania jakiejś działalności przez człowieka lub ludzi; warunki umożliwiające za pomocą określonych przekształceń uzyskanie pożądanego rezultatu. Tester to człowiek, a zgodnie z teorią zasobów życiowych, każdy człowiek dysponuje czterema aktywami ekonomicznymi:
środkami finansowymi (dochodem) — zasób odnawialny;
energią (siłą życiową) — zasób częściowo odnawialny;
czasem — zasób stały i zasadniczo nieodnawialny;
wiedzą (informacjami) — zasób odnawialny, to część kapitału ludzkiego, która może zarówno rosnąć, jak i maleć..
Chcę zauważyć, że definicja skuteczności w naszym przypadku nie jest do końca poprawna, ponieważ im więcej wiedzy wykorzystujemy, tym niższa jest skuteczność. Dlatego redefiniowałbym skuteczność jako “stosunek między uzyskanym wynikiem a wydanymi zasobami”. Wtedy wszystko jest poprawne: wiedza przy pracy nie ulega wyczerpaniu, ale zmniejsza wydatki jedynego zasadniczo nieodnawialnego zasobu testera — jego czasu.
Rozwiązanie
Zatem szukamy globalnych problemów testerów, które pogarszają efektywność ich pracy.
Najważniejszym zasobem, który wydaje się na pracę testera, jest jego czas (pozostałe można w pewnym sensie do niego sprowadzić), a abyśmy mogli mówić o poprawnym obliczeniu efektywności, musimy również wynik przyporządkować do czasu.
Aby to zobaczyć, rozważmy system, którego żywotność tester zapewnia swoją pracą. Taki system to projekt, w skład którego wchodzi tester. Cykl życia projektu można w przybliżeniu przedstawić następującym algorytmem:
- Praca nad wymaganiami
- Tworzenie dokumentacji technicznej
- Rozwój
- Testowanie
- Wydanie do produkcji
- Wsparcie (przejdź do pkt 1)
Przy tym cały projekt można rekursywnie podzielić na podprojekty (funkcje) z tym samym cyklem życia.
Z punktu widzenia projektu, skuteczność jego realizacji jest tym większa, im mniej czasu na niego poświęcono.
W ten sposób dochodzimy do definicji maksymalnej możliwej efektywności testera z punktu widzenia projektu — to stan projektu, w którym czas na testowanie wynosi zero. A wspólnym problemem dla wszystkich testerów jest niemożność osiągnięcia tego czasu.
Co z tym zrobić?
Wnioski są dość oczywiste i od dawna stosowane przez wielu:
- Rozwój i testowanie powinny się zaczynać i kończyć niemal jednocześnie (tym zwykle zajmuje się dział ). Idealnym rozwiązaniem jest, gdy cała rozwijana funkcjonalność w momencie gotowości jest już objęta testami automatycznymi, zorganizowanymi w testy regresyjne (a jeśli to możliwe, to także w testy przed zatwierdzeniem) z wykorzystaniem jakiegoś .
- Im więcej w projekcie funkcji (im bardziej jest skomplikowany), tym więcej czasu trzeba poświęcić na sprawdzenie, że nowa funkcjonalność nie zepsuła starej. Stąd wynika, że im bardziej skomplikowany projekt, tym więcej wymaga automatyzacji .
- Za każdym razem, gdy przepuszczamy błąd do produkcji, a użytkownik go znajdzie, musimy poświęcić dodatkowy czas na przejście przez cykl życia projektu zaczynając od pkt 1 (Praca nad wymaganiami, w tym przypadku użytkowników). Ponieważ przyczyny przeoczenia błędu są w ogólnym przypadku nieznane, pozostaje nam tylko jedna droga optymalizacji — każdy błąd znaleziony przez użytkowników powinien być uwzględniony w testach regresyjnych, aby mieć pewność, że nie pojawi się ponownie.
Źródło: habr.com
