Wprowadzenie
Dzień dobry, mieszkańcy Chabrowska. Właśnie rozwiązywałem zadanie testowe na stanowisko QA Lead w firmie fintech. Pierwsze zadanie, polegające na stworzeniu planu testów z pełną listą kontrolną i przykładami przypadków testowych do testowania czajnika elektrycznego, można rozwiązać banalnie:
Trudno wyobrazić sobie lepszy plan testów z pełną listą kontrolną.
Ale druga część okazała się pytaniem: „Czy są jakieś problemy wspólne dla wszystkich testerów, które uniemożliwiają im wydajniejszą pracę?”
Pierwsze co mi przyszło na myśl to wypisanie wszystkich mniej lub bardziej zauważalnych problemów, jakie napotkałem podczas testów, wyeliminowanie drobiazgów i podsumowanie reszty. Szybko jednak zdałem sobie sprawę, że metoda indukcyjna odpowie na pytanie, które nie dotyczy „wszystkich”, ale w najlepszym razie tylko „większości” testerów. Dlatego postanowiłem podejść do tego od drugiej strony, dedukcyjnie, i tak też się stało.
określić
Pierwszą rzeczą, którą zwykle robię, rozwiązując nowy problem, jest próba zrozumienia, o co w tym wszystkim chodzi, a aby to zrobić, muszę zrozumieć znaczenie słów, które go stawiają. Kluczowe słowa, które należy zrozumieć, to:
- problem
- próbnik
- praca testera
- wydajność testera
Przejdźmy do Wikipedii i zdrowego rozsądku:
(starożytne greckie πρόβλημα) w szerokim znaczeniu - złożone zagadnienie teoretyczne lub praktyczne, wymagające badań i rozwiązania; w nauce - sytuacja sprzeczna, która pojawia się w postaci przeciwstawnych stanowisk w wyjaśnianiu wszelkich zjawisk, obiektów, procesów i wymaga odpowiedniej teorii, aby ją rozwiązać; w życiu problem formułowany jest w formie zrozumiałej dla ludzi: „Wiem co, nie wiem jak”, czyli wiadomo, co trzeba uzyskać, ale nie wiadomo, jak to zrobić . Pochodzi z późn. łac. problem, z języka greckiego. πρόβλημα „rzucony do przodu, umieszczony z przodu”; od προβάλλω „rzucić do przodu, postawić przed siebie; winić".
W rzeczywistości „problem” = „wszystko, czym należy się zająć”, nie ma większego sensu.
- specjalista (nie będziemy dzielić na typy, bo interesują nas wszyscy testerzy), który bierze udział w testowaniu komponentu lub systemu, którego efektem jest:
— zestaw działań związanych z testowaniem.
(łac. Effectivus) - związek osiągniętego wyniku z wykorzystanymi zasobami (: 2015).
- konsekwencja łańcucha (serii) działań (rezultatu) lub zdarzeń, wyrażona jakościowo lub ilościowo. Możliwe wyniki obejmują przewagę, wadę, zysk, stratę, wartość i zwycięstwo.
Podobnie jak w przypadku „problemu”, znaczenie jest niewielkie: coś, co wyszło w wyniku pracy.
- ilościowo mierzalna możliwość wykonywania jakiejkolwiek działalności osoby lub osób; warunki, które umożliwiają uzyskanie pożądanego wyniku przy zastosowaniu określonych przekształceń. Testerem jest osoba i zgodnie z teorią zasobów witalnych każda osoba jest właścicielem czterech aktywów ekonomicznych:
gotówka (dochód) jest zasobem odnawialnym;
energia (siła życiowa) jest zasobem częściowo odnawialnym;
czas jest zasobem stałym i zasadniczo nieodnawialnym;
wiedza (informacja) jest zasobem odnawialnym, jest częścią kapitału ludzkiego, który może rosnąć i ulegać zniszczeniu.
Pragnę zauważyć, że definicja efektywności w naszym przypadku nie jest do końca poprawna, gdyż im więcej wiedzy wykorzystujemy, tym niższa jest efektywność. Dlatego zdefiniowałbym efektywność jako „stosunek osiągniętych wyników do wydanych zasobów”. Wtedy wszystko jest w porządku: wiedza nie jest marnowana podczas pracy, ale zmniejsza koszty jedynego zasadniczo nieodnawialnego zasobu testera – jego czasu.
decyzja
Szukamy więc globalnych problemów testerów, które pogarszają efektywność ich pracy.
Najważniejszym zasobem poświęcanym na pracę testera jest jego czas (resztę można w ten czy inny sposób sprowadzić do tego), a żebyśmy mogli mówić o prawidłowym obliczeniu wydajności, wynik również musi zostać sprowadzone do czasu .
Aby to zrobić, rozważ system, którego żywotność tester zapewnia swoją pracą. Taki system to projekt, w którego zespole znajduje się tester. Cykl życia projektu można z grubsza przedstawić za pomocą następującego algorytmu:
- Praca z wymaganiami
- Tworzenie specyfikacji technicznych
- Rozwój
- Testowanie
- Wpuść do produkcji
- Wsparcie (przejdź do punktu 1)
W takim przypadku cały projekt można rekurencyjnie podzielić na podprojekty (cechy), o tym samym cyklu życia.
Z punktu widzenia projektu, im mniej czasu nad nim poświęcono, tym skuteczniejsza jest jego realizacja.
Tym samym dochodzimy do definicji maksymalnej możliwej wydajności testera z punktu widzenia projektu – jest to stan projektu, gdy czas na testowanie wynosi zero. Częstym problemem wszystkich testerów jest niemożność osiągnięcia tego czasu.
Jak sobie z tym poradzić?
Wnioski są dość oczywiste i przez wielu stosowane od dawna:
- Rozwój i testowanie powinny rozpoczynać się i kończyć niemal jednocześnie (zwykle robi to dział ). Idealną opcją jest sytuacja, gdy cała opracowywana funkcjonalność jest już objęta autotestami, zanim będzie gotowa, zorganizowana w testy regresyjne (i, jeśli to możliwe, wstępne zatwierdzenie) przy użyciu pewnego rodzaju .
- Im więcej funkcji ma projekt (im jest bardziej złożony), tym więcej czasu trzeba będzie poświęcić na sprawdzenie, czy nowa funkcjonalność nie psuje starej. Im bardziej złożony projekt, tym większa automatyzacja jest wymagana .
- Za każdym razem, gdy przeoczymy błąd w produkcji i znajdzie go użytkownik, musimy poświęcić dodatkowy czas na przejście przez cykl życia projektu, zaczynając od punktu 1 (praca z wymaganiami, w tym przypadku użytkownikami). Ponieważ przyczyny pominięcia błędu są na ogół nieznane, pozostaje nam tylko jedna ścieżka optymalizacji - każdy błąd znaleziony przez użytkowników musi zostać uwzględniony w testach regresyjnych, aby mieć pewność, że nie pojawi się ponownie.
Źródło: www.habr.com