Wiedza domenowa w testowaniu. Przekleństwo czy błogosławieństwo?

Wiedza domenowa w testowaniu. Przekleństwo czy błogosławieństwo?
Na facebookowej grupie "Testowanie oprogramowania" pojawiła się ciekawa dyskusja o wiedzy domenowej w testowaniu. "Szkoły" testowania, takie jak oparta na kontekście szkoła certyfikacyjna (ISTQB) czy też eksploracyjna, dostrzegają znaczenie wiedzy domenowej w testowaniu oprogramowania. Nikt nie neguje, że doświadczenie i nauka w danej dziedzinie przydają się w przygotowaniu i uruchomieniu testów, ale czy jest to konieczne?

Istnieje wiele obszarów, w których tester może się rozwijać:

- od testera do lidera testów,

- od testera do specjalisty w testach niefunkcjonalnych (ekspert bezpieczeństwa),

- od testera do... Praktycznie wszystkie ścieżki kariery są otwarte.

 

Czy warto więc zamykać się w jednej domenie i być specjalistą od np. testów aplikacji bankowych? Czy warto tak silnie zawężać swoje możliwości rozwoju? Głosy w dyskusji pojawiają się dwa.

Kiedy ktoś staje się ekspertem w danej dziedzinie, z jednej strony w swoim wąskim obszarze staje się ikoną, ale przestaje być praktycznie zauważalny na zewnątrz tego obszaru. Istnieje dodatkowe niebezpieczeństwo, że dany "obszar" się zestarzeje i nie będzie wzbudzał zainteresowania zgodnie z gartnerowską hype cycle dla technologii.

 

Ilustracja Gartner Hype Cycle z wikipedia.org

 

Marek Bartosiewicz pyta: "Jak warto szkolić i motywować testerów do pracy jako specjalistów w danej dziedzinie?"

W odpowiedzi Radek Smilgin mówi: "Jestem wrogiem "wiedzy domenowej". Zakładam, że spłyca ona testowanie i utrudnia rozwój testera. Dlaczego nie ma takiego pojęcia jak programista aplikacji bankowych, ale jak zatrudnia się testera to musi mieć 2 lata doświadczenia w bankowości?"

"Specjalizowanie się" jest zawsze trudną decyzją i musi być solennie przemyślane. Pod uwagę trzeba wziąć stabilność rynku w danym obszarze, jak i potencjał jego wzrostu. Nie możemy koncentrować się na "tu i teraz". Aby nie popełnić błędu, decyzję należy oprzeć na rozważnej analizie przyszłości.

Dodatkowo Marek uważa, że tester może w tym wypadku pełnić rolę wyroczni testowej, czyli źródła oczekiwanego rezultatu dla zachowania się aplikacji.

Radek neguje takie podejście twierdząc, iż wyrocznia oznacza, że ktoś musiałby być jednocześnie dobrym testerem i ekspertem w dziedzinie, a to rzadki przypadek.

W dalszej dyskusji pojawia się negacja wyroczni jako człowieka, a zwrócenie uwagi na wytworzenie dokumentacji będącej produktem zespołu. Produkt, który jest możliwy do zrewidowania, poprawiania, powielania, itd. Produkt, który jest dowodem na wypracowany kompromis i może służyć jako kontrakt zawierany z klientem.

 

Zachęcamy do tej i innych dyskusji o testowaniu: http://www.facebook.com/groups/141683635854223/

 

To powinno Cię zainteresować