Z drugiej strony zauważyłem, że istnieje wielu testerów, którzy wolą po prostu grzebać samemu "na czuja" niż zasięgnąć porady u eksperta. Wynika to, zapewne z wcześniejszych doświadczeń typu "nie mam czasu" jak i obietnicy ogromnej satysfakcji, "że sam odkryłem".
Oczywiście wybór drogi należy do każdego testera osobiście. Ja chciałem się tylko podzielić swoimi spostrzeżeniami na ten temat.
Bezpośrednia rozmowa z ekspertem ma niewątpliwie tę ogromną zaletę, że uczy bardzo szybko wielu rzeczy związanych z testowanym systemem. Z drugiej jednak strony ma tę ogromną wadę, że w sposób zasadniczy zależy od 'interfejsu' eksperta. Po prostu, kiedy spotykamy człowieka otwartego i gotowego do pomocy to pracuje się nam z nim przyjemniej niż z człowiekiem, którego trzeba wiecznie "błagać" o skrawek wiedzy. Powoduje to, że 'user-friendly' eksperci są bardziej oblegani niż Ci 'z konsolą znakową'. Często sami eksperci, przeciążeni pracą, zaczynają ograniczać swoją uprzejmość bo po prostu zajęci są swoimi obowiązkami.
Aby rozmowa z ekspertem była owocna, należy przede wszystkim się do niej przygotować (nas też denerwuje jak ktoś ciągle przychodzi do nas i zadaje pytania na które swobodnie możemy odpowiedzieć sławetnym "RTFM"). A jak się przygotować? Przede wszystkim przeczytać dostępna dokumentację aby upewnić się, ze mamy doczynienia z prawdziwym problemem
(zasada taka sama jak przy zgłaszaniu incydentów), następnie sprawdzić logi. Bardzo często ten krok jest pomijany a on tymczasem dostarcza w wielu wypadkach odpowiedzi na nasze pytania. Po to przecież logi są implementowane aby odpowiadać na pytania co poszło źle.
Jeśli pójdziemy do eksperta z pytaniem "dlaczego to nie działa" to jest to tak samo jakbyśmy zgłosili incydent "system nie działa". Zadając pytanie ekspertowi trzeba wiedzieć co konkretnie nie działa, umieć to nazwać. A jeśli nie potrafimy - bo n.p. jesteś w nowej organizacji - to należy zaznaczyć to na wstępie, że nie umiemy tego nazwać ale utknęliśmy na takim to a takim kroku (określić punkt w procesie).
Inną pomocną rzeczą są koledzy obok. Jeśli jest to zespół doświadczonych testerów to na pewno tam znajdziemy odpowiedź a jeśli nie to i tak warto zapytać bo prawdopodobnie, ktoś wcześniej trafił na podobny problem. Przynajmniej powie nam do kogo powinniśmy udać się z podobnym problemem.
Pozostaje jeszcze problem "wydłubywania" czegoś samodzielnie. Testerzy - chyba z natury rzeczy - są ludźmi uwielbiającymi dłubać. Jeśli napotykają problem n.p. z uruchomieniem jakiegoś procesu, to próbują na wszelkie znane im sposoby, uruchomić go. Problem polega na tym że:
- nawet jeśli uda nam się uruchomić taki proces to i tak nie wiemy do końca czy jest to poprawny sposób uruchamiania
- często po prostu nie udaje nam się go uruchomić bo brakuje nam wiedzy o jednym, małym, sekretnym parametrze
Tutaj jednak problemami, które przełamywać powinien przede wszystkim kierownik testów są:
- zwykła, naturalna nieśmiałość członków zespołu
- nieznajomość organizacji
- obawa przed dyskredytacją lub odsłonięciem naszej niewiedzy*
- przeszkody fizyczne, n.p. oddzielne lokalizacjae testerów i ekspertów
- postawa osoby odpowiedzialnej za testy
Czasami problemem bywa nieznajomość organizacji. Tester po prostu nie wie do kogo się udać. A nawet jak zdobędzie nazwisko danej osoby to nie wie gdzie może ją znaleźć. Jest to zasadnicze pole działania dla osoby kierującej testami. To ona powinna w takich sytuacjach przejmować obowiązek 'biura matrymonialnego' komunikując testera z odpowiednim ekspertem.
Testerzy nie są wszechwiedzący. Część funkcjonalności systemu znają lepiej na niskim poziomie a część - zwłaszcza tą której nie testowali bezpośrednio - znają na wyższym poziomie. Większość problemów przeważnie dotyczy tego wysokiego poziomu. Mamy więc sytuację kiedy człowiek z oględną wiedza na temat danej dziedziny usiłuje skonsultować się z ekspertem. Powoduje to, ze 'ekspert' czasami wykorzystuje sytuację dając do zrozumienia, ze pytanie jest głupie. Dzieje się tak gdyż 'ekspert' nie potrafi wyobrazić sobie świata bez swojego poletka, któremu przypisuje najprawdopodobniej mistyczne niemal przymioty. Jest to smutna sytuacja, która de facto obróci się przeciw 'ekspertowi'. W efekcie ekspert otrzyma gorzej przetestowany system, co wynika z reglamentowanie informacji.
Rozdzielenie lokalizacji ekspertów i testerów, jest w mojej opinii jednym z najpoważniejszych błędów. Pracowałem w projekcie, w którym testerzy siedzieli w lokacji oddalonej od ekspertów o setki kilometrów. Żadna telefonia, komunikatory ani maile nie są w stanie tego skompensować. Duża porcja informacji ginie co odbija się na jakości systemu.
Jeśli kierownik testów lub inna osoba odpowiedzialna za działa kontrolujące jakość systemów informatycznych jest mało komunikatywna powoduje to, ze i członkowie zespołu nie będą się komunikować z innymi zespołami. W skrajnych przypadkach kierownicy testów budują mit o jakości oprogramowania którą rujnują niedouczeni, niekompetentni, leniwi i gnuśni programiści. Jest to odwrócenie sytuacji eksperta z nieprzyjaznym 'interfejsem'. Skoro testerzy wykorzystują byle pretekst do pomstowania na ekspercie i jego rodzinie 7 pokoleń wstecz to dlaczego tenże ekspert ma być otwarty i uprzejmy. Posunę się nawet do twierdzenia, iż zarząd firmy w której funkcjonuje taki kierownik testów, powinien niezwłocznie usunąć taką osobę zanim ta choroba rozprzestrzeni się na cały zespól testów.
Reasumując chciałem powiedzieć, że wszyscy uczestnicy projektu powinni traktować się z szacunkiem bez względu na zajmowane w nim pozycje. Kierownictwo i zarząd firmy powinny dbać o kreowanie i rozwijanie takich postaw a napiętnować postawy zamknięte.
* Zdarzyło mi się pracować w środowisku, w którym tak zwani eksperci wykorzystywali niedoświadczenie testerów, drwiąc z nich. Zakończyło się to prawie całkowitym zerwaniem komunikacji testerzy - eksperci co z kolei - w mojej ocenie - było jedną z zasadniczych przyczyn niskiej jakości dostarczanego rozwiązania.
