Napisane przez: futrzak | 10 września 2013

Cechy dobrego testera

Od jakiegos czasu jestem sobie czlonkiem pewnej spolecznosci sieciowej a mianowicie Software Testing Club.

Na forum wyplynela ciekawa dyskusja, a mianowicie jakie sa najwazniejsze cechy, ktore powinien posiadac dobry SQA (Software Quality Assurance Engineer).
Jeden z czlonkow (Hiszpan, pracujacy w branzy w Hiszpanii) zrobil u siebie na blogu nawet ankiete.
Wyszlo, ze najwazniejsza jest komunikacja. Technical skills byly dopiero na 4 miejscu.

Zgadzam sie z tym calkowicie. Nawet jesli tester ma wiedze na temat produktu w malym paluszku, nawet jesli jest bardzo detail oriented, to braki w komunikacji sprawią, ze bedzie zupelnie nieefektywny w swojej pracy.
Jakze to dalekie od obiegowej opinii dzialow HR, ktore skupiaja sie przede wszystkim na weryfikacji wiedzy technicznej. No ale coz, to jest najlatwiejsze, zwlaszcza jesli taką weryfikację da sie sprowadzic do prostej listy pytan z odpowiedziami, napisanymi przez kogos innego…

Tymczasem technical skills w wypadku kogos inteligentnego i samodzielnie myslacego sa chyba najlatwiejsze do nadrobienia…

Reklamy

Responses

  1. Trafiłaś w same sedno moich bolączek. Od czasu do czasu przypada mi w udziale testowanie oprogramowania i prawie zawsze mam ochotę skręcić karczek naszemu programiście za nieefektywną komunikację. Niestety kiepska robota testera w wyniku braku komunikacji programisty przekłada się na porażkę całego zespołu i niezadowolenie klienta.

  2. @Anetacuse:
    dokladnie tak. Programistow, ktorzy nie maja ochoty dokumentowac swojej pracy czy chociazby wyjasnic jak cos zrobili jest na pęczki – i niestety dobry tester musi jakos sobie radzic z pozyskiwaniem potrzebnych mu informacji.

  3. Ja bym dodał jeszcze inną cechę, która jest ważniejsza niż komunikacja. Umiejętność samodzielnego, krytycznego myślenia z postrzeganiem całości aplikacji i domieszką ciekawości. Tego mnie, jak programiście i kierownikowi projektów bardzo brakuje u testerów. Miałem prawdopodobnie takie nieszczęście, że testerzy pisali tylko minimalne scenariusze bez zastanowienia się (i często gęsto chęci sprawdzenia) czy przypadkiem ta zmiana nie wpłynęła jeszcze na jakiś inny obszar albo czy to co mówi im programista jest zasadne i spójne z resztą założeń (a nie tylko, aby przypadek testowy działał).
    Powyższe powoduje częste spięcia z kierownikiem testów po mojej stronie, jak później sam próbując coś zrobić w aplikacji wychwytuje błąd i na pytanie czemu nikt go nie zgłosił dostaje różne odpowiedzi.

  4. @maxio:
    ta cecha nie jest absolutnie niezbedna u zwyklych testerow. Od martwienia sie o zakres testow, startegie, approach jest QA lead/manager. To jego rola jest wziecie do ręki wszystkich testcases i ich sprawdzenie, pokazanie luk. To on musi miec zdolnosci prawidlowej oceny sytuacji i krytycznego myslenia, a nastepnie doskonale communication skills, zeby to przekazac podwladnym.

    To, o czym mowisz to jest kwestia posiadania i wykonywania regression test suit (ktory optymalnie powinien byc zautomatyzowany).

    To, ze dostajesz rozne odpowiedzi – to kwestia niezrozumienia tematu i zlej komunikacji…

    Wbrew pozorom znalezc dobych testerow jest bardzo trudno. Rowniez dlatego, ze wlasciwie w zadnej pracy nikt sobie nie zawraca glowy nauczeniem ich wlasciwego podejscia do zawodu, analizy i metodyki ORAZ komunikacji…

  5. Ciekawa obserwacja. Ale zgadzam się z maxsiem. I dodam, że dobry tester musi tylko umieć szukać dziury w całym. Taki modelowy tester pracował u nas w firmie i kombinował tylko „Jak by to zepsuć?”. Jak on powiedział „testy przeszły” to było wiadomo że jest OK.
    A co do communication skills: wydaje mi się że nie jest to niezbędne. Wystarczy „działa” / „nie działa” / „kiedy będzie fix?”:P

  6. @MK:
    umiejetnosc tzw. „szukania dziury w calym” to duzo, duzo za malo. Takie podejscie jest chaotyczne i zupelnie nieprzydatne np. w performance tests albo load stress. Podobnie w integration testing.
    Zreszta tak naprawde zalezy to od produktu. Inaczej podchodzisz do testowania oprogramowania do miedzybankowych transakcji finansowych a inaczej do sprzetu medycznego a inaczej do gry. Pierwszym krokiem zawsze jest positive testing, dopiero jak jest czas to mozna robic negative testing tudziez pobawic sie w sprawdzanie, do jakiego stopnia soft jest idiotoodporny….
    Dobry tester znajacy swoj soft WIE jak go rozwalic i doprawdy robienie tego na slepo dla zabawy naraza firme na koszty.

    „dziala/nie dziala/kiedy bedzie fix” sprawdza sie tylko w sytuacjach, gdzie masz maciupki zespol kilku osob, ktore siedza w tym samym pokoju, znaja sie jak lyse konie, a soft ktory przygotowuja to jest relatywnie prosta i nieskomplikowana aplikacyjka.

    Komunikacja staje sie essencial jesli pracujesz przy czyms wiekszym, masz kilka zespolow rozsianych w roznych lokacjach zajmujacych sie roznymi modulami czy serwisami, do tego masz kilka/kilkanascie roznych projektow idacych rownoczesnie codzien i do tego, zeby napisac testcases i oproacowac strategie potrzebna ci jest informacja, ktora musisz wydobyc od ludzi, z ktorymi nigdy sie na oczy nie widziales a masz do dyspozycji tylko email i telefon. I to nie sa tylko programisci, to sa tez ludzie z supportu, sales, marketingu a czasami i customers (jesli projektuje sie i pilotuje progam beta tests).
    Do tego dochodzi wisienka na torcie: jak masz pracowac z testerami co sa outsourcingiem w roznej strefie czasowej i kulturowej (np. ja mialam Boliwijczykow, Hindusow, Filipinczykow).

    Potem przychodzi faza testowania: tester, ktory ma kiepskie comunication skills nie bedzie mial zadnej credibility (wiarygodnosci). Bo co. Programista bierze jego buga, czyta i ops… nie potrafi zreprodukowac. To wyrzuca do kosza. Albo – wiekszosc programistow ma standardowy zestaw odpowiedzi pt. „u mnie dziala” „to jest corner case” „to jest enhancement” itd. Jesli tester jest dobrym musi umiec prawidlowo ocenic severity i priority, i przepchnac to dalej czyli wyrobic sobie SZACUNEK i wiarygodnosc. A do tego niezbedna jest wlasciwa komunikacja.

  7. Ale QA to chyba trochę co innego niż testowanie?
    Przynajmniej tak jest u mnie w firmie. Ja pracuję w dziale testów, i z działem QA mamy tyle wspólnego co wszystkie inne działy tzn. niewiele :). My odpowiadamy za swoją działkę, czyli testowanie, tak samo jak poszczególne zespoły programistyczne odpowiadają za produkcję swoich komponentów. Ludzie z QA są na poziomie „meta”: oni są od nadzorowania całego procesu produkcji systemu jako takiego, a nie od testowania, a nawet nie od układania strategii testowych (od tego sa test architekci, którzy są w naszym dziale). QA interesuje się liczba defektów, tym na ile są poważne i na ile mogą zaszkodzić klientowi i ocenia – w sytuacji gdy juz jest blisko deadline’u – czy dany defekt musi być poprawiony przed wypuszczeniem systemu, czy też mozna z tym zaczekać do następnego releasu, albo w ogóle (jeżeli np. defekt jest kosmetyczny albo objawia sie bardzo rzadko) zostawić go bez poprawki i tylko np. opisac klientowi w manualu workaround jeżeli taki istnieje. Robią tez analizy tego, ile zostało wykrytych defektów w testowaniu, a ile przeszło niewykrytych i ujawniły się w postaci zgłoszeń od klientów, i proponują jakies zmiany na poziomie procesowym na przyszłość, aby tę liczbe zmniejszyć.

  8. @raj:
    to zalezy jak jest firma zorganizowana. ja w sumie pracowalam w firmach, w ktorych dzal QA obejmowal to, co opisujesz oraz jeszcze mial szeregowych testerow.


Skomentuj

Wprowadź swoje dane lub kliknij jedną z tych ikon, aby się zalogować:

Logo WordPress.com

Komentujesz korzystając z konta WordPress.com. Wyloguj / Zmień )

Zdjęcie z Twittera

Komentujesz korzystając z konta Twitter. Wyloguj / Zmień )

Facebook photo

Komentujesz korzystając z konta Facebook. Wyloguj / Zmień )

Google+ photo

Komentujesz korzystając z konta Google+. Wyloguj / Zmień )

Connecting to %s

Kategorie

%d blogerów lubi to: