Napisane przez: futrzak | 9 września 2012

Automatyzacja testowania – jak to wyglada w corpo

Kiedys dawno dawno temu zawód w którym pracowałam nazywał się Software Quality Assurance albo automation tester. Praca polegala głównie na testowaniu, chociaz w jego ramach trzeba sobie bylo samemu pisac skrypciki i generalnie robic automatyzacje. Jednym wychodzilo to lepiej, innym mniej (nie kazdy tester jest swietnym programista, zreszta jakby byl, to pracowalby jako programista a nie tester) – pewne rzeczy dalo sie latwo zautomatyzowac (te oparte o open source rozwiązania), inne nie (rzeczy proprietary do ktorych za platforme do programowania trzeba bylo placic za licencje).

Generalnie jednak naczalstwo uwazalo, ze stuprocentowa automatyzacja to jest święty Graal testowania i że im wiecej automatyzacji, tym beda lepsze wyniki oraz taniej bedzie – bo wiadomo, zamiast 5 osob bedzie mogla pracowac jedna tylko. Uruchomi sie tesciki w nocy, rano przyjdzie, obejrzy gotowe wyniki, zaraportuje bugi – i JUZ!

Rzeczywistosc jak zwykle okazala sie bardziej skomplikowana, niz sie naczalstwu wydawalo. Po pierwsze, automatyzowac jest sens dopiero tzw. regression tests. Do tego trzeba miec juz w miare ustabilizowany produkt, z features ktore nie beda sie zmieniac w najblizszym czasie i tak dalej. Rzeczy zupelnie nowych, dopiero co dodawanych nie ma sensu włączać do ogólnej puli testow, bo będzie trzy razy wiecej roboty niz to jest warte: oprocz zwyklego testowania po pare razy jednej funkcjonalnosci trzeba bedzie jeszcze za kazdym razem zmieniac skrypt. Bez sensu.

Po drugie, odczytanie automatycznego raportu i wpisanie go do bugzilli (czy innego bug tracking tool) to zaledwie 1/5 sukcesu. Trzeba bowiem jeszcze dojsc do sedna problemu czyli sprawdzic, czemu skrypt zwrocil wynik negatywny i co go wlasciwie spowodowalo, a nastepnie opisac tzw. how-to-repeat.
Generalnie robota żmudna, upierdliwa i niewdzięczna – programiści bowiem zwykli QA taktować bardzo arogancko – wiadomo, nikt nie lubi ludzi przynoszących złe wiadomosci i pokazujacych co i rusz ze ten piekny kod, ktory napisales, znowu nie dziala i jeszcze na dodatek psuje kawalki cudzego…

To co powyzej opisalam dotyczylo tylko tzw. functionality testing. A gdzie stress, performance, integration i cala reszta?
Naczalstwo nie zaprzatalo sobie glowy faktem, ze dorzucanie wiecej i wiecej obowiazkow na glowy juz pracujacych testerow oraz ich straszenie nic nie da – bo doba ma tylko 24h.

W zwiazku z tym powstala potrzeba zatrudnienia kogos, kto zajmowalby sie tylko automatyzacja, a przynajmniej tylko automatyzacja regressions tests i maintenance istniejacej juz puli testow. Tylko, ze z opisu takiej pracy nie da sie wykluczyc… zwyklego testowania i raportowania bugow :).
Czyli, wchodzenia w konflikt z „prawdziwym developerami”. Na dodatek pozycja pod tytulem „automation tester” czy „automation engineer” brzmi uwlaczajaco i zle wyglada w CV – wiadomo – to nizsza kasta w porzadku dziobania w dziale eng firmy IT…

Na coz wiec wpadlo naczalstwo? Otoz, jak grzyby po deszczu, zaczely wyrastac fajne, nowe tytuly doczepione do tej samej job position: „Software Development Engineer in Test” albo po prostu „Software Developer” (dopiero na miejscu okazywalo sie, ze chodzi o to samo).
Na pozycje te lapali sie zwykle ludzie po szkole, bez doswiadczenia. Mysleli, ze sobie pare lat popracuja, a potem jak juz zdobeda doswiadczenie, to zalapia lepsza robote tj. „prawdziwy development”. Tymczasem tego typu robota (debugowanie cudzego kodu) jest znacznie trudniejsza niz programowanie od zera w/g gotowego, wymyslonego juz przez kogos schematu.

W ten sposob „rozwiazano” problem nie tam, gdzie istnial, ale tam, gdzie naczalstwu wydawalo sie, ze istnial. Dzieki temu cel glowny pracy testera – polepszenie jakosci produktu – znaczaco sie obnizyl co prawda, ale wazne, ze naczalstwo bylo zadowolone…

Niestety rozwiazanie najbardziej efektywne tj. wziac najbardziej doswiadczona osobe (i najlepiej znajaca produkt) z zespolu testerow, odjac jej wszystkie inne obowiazki, skierowac w trybie pilnym do automatyzacji i zaplacic wiecej za nadgodziny (a do pisania testow i wypelniania tabelek zatrudnic osobe junior) – nie miesci sie w modus operandi korporacji…

A potem ludzie dziwia sie, ze jakis tam soft udaje tylko, ze dziala, a tak naprawde jest totalnie spieprzony. Pokazcie mi jednak DZIS firme, ktora stawia na jakosc (w tej branzy) i jest w stanie z tego powodu przebic konkurencje.
Ha Ha…

Reklamy

Responses

  1. Apple nie stawia na jakosc przypadkiem?

  2. Attlasian … :)

  3. google, daje wiele darmowych rzeczy i nie wysypuje się za często ;]

  4. Większość baz danych, lub office (jeśli akurat nie robisz czegoś maksymalnie głupiego).
    tutaj oczywiście jeszcze wiele zależy co to za produkt, czy stand alone, czy w chmurze, czy też na przykład strona webowa…

    Ja jestem zdania, że testować trzeba zawsze i jak najwięcej… i tak jest tam pies pogrzebany, że trzeba wiedzieć, czego testować nie trzeba. Ponadto na potrzebę testowania wpływa jeszcze wiele takich śmiesznych czynników jak: stabilność zespołu programistów, wizja product managerów, poziom idiotyzmu szefa, ilość technologii zintegrowanych w projekcie, czy język jest słabotypowalny czy strongly typed….

    ale w ogólności się zgadzam.. testowanie to trudna temat być:)

  5. @wiwern:
    Apple to stawia na glupie patenty…

  6. Quality Assurance i testowanie to chyba jednak troche inne rzeczy. Przynajmniej u mnie w firmie testy to testy i odpowiedni dział ma wyraźnie słowo „test” w nazwie, a QA to co innego – to ludzie zajmujacy się raczej robota typowo biurowo-menedżerską związaną z jakością – ich narzędziem pracy są tabelki Excelowe i inne programy w których śledzą zgłoszone do produktów błędy, ile ich było, w którym releasie, jakich funkcjonalności dotyczyły, czy zostały poprawione i jeżeli tak to w którym releasie itp. Muszą też być obecni na review na których odbywa się formalne przekazanie kodu przez developerów testerom i pilnować tych wszystkich informacji. Jeżeli np. zbliża się termin wypuszczenia produktu, a testerzy jeszcze na krótko przed deadlinem znajdą błąd, to do zadań QA należy też uczestnictwo w podejmowaniu decyzji, czy ten błąd jest na tyle poważny, że trzeba opóźnić release i go poprawić, czy produkt może w takim stanie iść do klienta, a błąd się naprawi jakąś poprawką która zostanie wydana później. Generalnie papierkowa robota. Tak że testy to jedno, a QA to drugie.

    A co do sensu automatyzacji, to nawet bardziej niz testy regresyjne jest sens automatyzowac testy performance’owe, bo w zasadzie bez automatyzacji i odpowiednich narzędzi testów performance’owych nie zrobisz – jak chcesz np. obciążyć serwer pocztowy 10 tysiącami maili na godzinę? :)

  7. @raj:
    heh, to liczac w/g takiego podzialu przez prawie cala swoja prace w zawodzie wykonywalam dwa etaty…bo robilam i jedno i drugie…


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ń )

Zdjęcie na Facebooku

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

Zdjęcie na Google+

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

Connecting to %s

Kategorie

%d blogerów lubi to: