blog.testowka.pl

Testowanie Oprogramowania made in PL

opublikowany przez 24, Paź, 2011, w kategoriach Inne

(Zdielano w Polandii)

Minęło już trochę czasu od konferencji Test Warez 2011, w której miałem okazję brać udział jako prelegent, więc chyba najwyższa pora, by podzielić się moimi spostrzeżeniami.

Test Warez jest obecnie największa i prawdopodobnie najpopularniejszą konferencją skierowaną do testerów w Polsce. W zasadzie można śmiało stwierdzić, że nie ma żadnych konurencyjnych wydarzeń w tej tematyce na taką skalę… Właśnie to, że jest to jedyna taka konferencja w naszym kraju jest naszym największym problemem.

Sam poziom konferencji pomimo tego, iż na polskie warunki na prawdę bardzo wysoki niestety nie ma się co równać z konferencjami za granicą. Niemniej jednak wielkie podziękowania dla organizatorów za to, że próbują zrobić coś dla testerów w Polsce.

Nie będę się rozpisywał na temat wszystkich prelekcji i prelegentów, ale chciałem się skupić na dwóch, które pozwoliły mi zrozumieć jaki jest obecny stan Polskiego światka testerów oprogramowania.

Na pierwszy ogień panel dyskusyjny Radka Smilgina z Testerzy.pl zatytułowany: „Dokąd idziesz Testowanie? Co ważnego wydarzyło się w testowaniu w ostatnim roku i co wydarzy się w kolejnych latach”. Panel miał na celu wskazanie najważniejszych wydarzeń w polskim testowaniu oprogramowania, które miały miejsce w minionym roku. Do jednych z głównych wydarzeń roku zostały zaliczone:
– rozpoczęcie kierunku studiów „Testowanie Oprogramowania”
– start platformy crowdsourcingowej testuj.pl
Obydwa powyższe wydarzenia na prawdę są znaczące, niestety polskie testowanie oprogramowania jest daleko w tyle za innymi krajami. Gdy na całym świecie coraz większą popularność zyskuje Agile, a o czymś takim jak Waterfall wszyscy powoli zapominają u nas nadal wszyscy skupiają się na tym jak wykrywać błędy zamiast pracować nad tym jak tych błędów do oprogramowania nie wprowadzać. Platformy crowdsourcingowe skupiające testerów oprogramowania także nie są niczym nowym.
Chociaż akurat powstanie polskiej platformy powinno niektórym dać jasny sygnał do tego, że testowanie oprogramowania w wielu firmach w postaci takiej jak miało miejsce przez ostatnich wiele lat (klikanie) powoli ma się ku końcowi – po co utrzymywać dział klikaczy skoro zawsze można tą usługę dużo taniej wydzierżawić na zewnątrz płacąc tylko za efekty.
Niestety powyższe wydarzenia to tylko kopia tego co na całym świecie miało miejsce już wiele lat temu.

Kolejną prelekcja, która dużo mi uświadomiła był agile’owy wykład Moniki Konieczny na temat kontaktów między testerami a programistami w zespołach (głównie mniej, lub bardziej zwinnych zespołach), oraz o tym jak przy użyciu gemifikacji można te kontakty poprawiać. Podczas prelekcji na sali zaistniał pewien szum rozmów, a nawet śmiechów i pytań typu „o czym ona gada?, jakie konflikty z programistami?”. Dało mi to wiele do myślenia i w końcu po przeprowadzeniu kilku wywiadów środowiskowych przypomniałem sobie o potencjalnych przyczynach tego problemu. Mówienie o pozornie nieznaczących konfliktach między programistami a testerami w zespołach może nie docierać do wielu osób, które nigdy w zespole programistyczno-testerskim nie pracowały. Sam pamiętam czasy, gdy pracowałem w firmie, gdzie dział testerski znajdował się na pierwszym piętrze budynku, a programiści siedzieli na czwartym. Wielu z tych programistów nie spotkałem nigdy osobiście i nawet nie wiem o tym jak wyglądają, a co dopiero mówić o konfliktach i problemach komunikacyjnych w codziennej pracy face2face. To jeszcze jeden argument świadczący o tym, że niestety świadomość polskich firm IT o jakości oprogramowania i zapewnianiu tejże jakości jest dosyć niska w porównaniu do naszych kolegów i koleżanek z zagranicy.

Wisienką na torcie, a raczej kroplą, która przelała czarę goryczy była rozmowa z jednym z wysoko postawionych członków Stowarzyszenia Jakości Systemów Informatycznych (SJSI), który przy obiedzie opowiedział mi o swoich odczuciach po spotkaniu z Tom’em Gilb’em (jeden ze specjalistów od Lean Software Development), na którym Tom opowiadało o tym, że jakość oprogramowania wcale nie bierze się z jego testowania tylko jest zaszyta w nim dużo wcześniej. Testowanie oprogramowania a zwłaszcza wykrywane błędy to zwykły waste. Wspomniany przedstawiciel SJSI był pod wielkim wrażeniem powyższego stwierdzenia i niesamowicie zaskoczony jego trafnością (WTF!). Dlaczego dopiero teraz?! Mamy 2011 rok! 10 lat od opublikowania manifestu Agile, kilkanaście lat od powstania eXtreeme Programming, kilka lat od ogłoszenia Software Craftmentship Manifest, a w Polsce ludzie, którzy są odpowiedzialni za głoszenie informacji mających na celu poprawianie jakości wytwarzanego oprogramowania dopiero teraz odkrywają rzeczy, które na całym świecie są oczywiste od ponad dekady.

Tak jak kiedyś na moim blogu w komentarzu napisał Krystian Kaczor: „W tym roku jest konferencja TestWarez pod tytułem “Testować tradycyjnie, czy zwinnie?”. No co to za pytanie w ogóle? Może “Iść pod prąd, czy nie?””  Agile i wytwarzanie oprogramowania wysokiej jakości od samego początku jest faktem. To nie bajka, o której opowiadają gdzieś na mitycznym Zachodzie, to fakt, który bardzo szybko wykluczy polskie firmy IT, które nie będą w stanie sprostać wymaganiom narzucanym przez zagraniczną konkurencję.


7 Comments for this entry

  • Nick

    Jak byłem kiedyś na rozmowie w firmie gdzie pracuje aktualnie Monika pytali mnie co bym zrobił, żeby przekonać deva do poprawy błędu który zgłosiłem, a którego on nie zamierza poprawić.
    To było chyba jedyne pytanie z rozmowy kwalifikacyjnej którego w ogóle się nie spodziewałem i na które całkowicie ściemniałem.
    Ja od początku mojej pracy z testowaniem jestem w jednej firmie i przyzwyczajony jestem do tego, że jak jest błąd to należy Go poprawić. Oni tam w loopie muszą mieć chyba problem z komunikacją skoro Monika aż prezentacje na ten temat robi.

  • Krystian Kaczor

    Cześć Wiktor, dzięki za relację z TestWarez i zacytowanie mnie. Coś mi się wydaje, że napisałeś ten tekst dosyć powściągliwie 🙂 W tamtym roku słyszałem głównie „to jest fajne, ale u nas nie zadziała”, „tutaj jest Polska, nie zagranica”. Mentalnie nadal bliżej Rosji.
    Z ciekawości ściągnę sobie prezentację Moniki i zobaczę czy można jej pomóc.

  • BH

    „Ja od początku mojej pracy z testowaniem jestem w jednej firmie i przyzwyczajony jestem do tego, że jak jest błąd to należy Go poprawić. Oni tam w loopie muszą mieć chyba problem z komunikacją skoro Monika aż prezentacje na ten temat robi.”

    Też mam czasem wrażenie, że kwestia jest wydumana z lekka…
    To, jak dev podchodzi do sprawy usterki świadczy głównie o nim nie mniej ja, jako tester mogę podejść do tematu w taki sposób by obojgu nam miło i owocnie się współpracowało…bez eskalacji złych emocji. Wszakże cel jest wspólny.

  • Radek

    A ja z kolei mam wrażenie, że do tej pory środowisko testerów w Polsce było dość zamknięte i wszystko obracało się wokół kilku członków SJSI kilku firm (Wawa, Kraków, Wrocław) oraz testowania głównie webowego nieco aplikacji mobilnych.
    W tym roku (w porównaniu do zeszłego) po pierwsze liczebność „stada” była zdecydowanie większa, a ponadto pojawiły się osoby/firmy, których do tej pory nie było (vide Tieto z ciekawymi prezentacjami – głównie dla osób z telekomów). Nota bene w prezentacji Adama Marciszewskiego z Tieto było niezłe podsumowanie kiedy warto testować zwinnie, a kiedy tradycyjnie w odniesieniu do testów wydajnościowych. I nie zgodzę się, że w tym przypadku podejście klasyczne jest podejściem „pod prąd”…

  • Monika

    @Nick: pytaliśmy Cię o to jak przekonywałbyś deva, głównie po to żeby dowiedzieć się czy rozumiesz konsekwencje występowania konkretnych błędów w aplikacjach (== ocenić zagrożenie) oraz by dowiedzieć się czy kiedykolwiek miałeś do czynienia z kryzysowymi sytuacjami w projekcie. Idea prezentacji narodziła się podczas pracy przy projekcie nie realizowanym w iLoop – nie martw się, nie mamy problemów komunikacyjnych na linii Dev QA, zespoły z którymi pracuję są bardzo zgrane.

    @Krystian: bardzo dziękuję za zaoferowaną pomoc. Celem prezentacji było zwrócenieuwagi/podyskutowanie na temat problemów, z którymi zdarzyło mi się spotkać (podczas prezentacji opowiadałam m.in. jak niektóre z nich zostały rozwiązane). Wiem, że podobne problemy występują w zaskakująco dużej ilości firm (nie, nie będę podawała nazw 😉 ).

    @BH: wydumana? W jaki dużych zespołach pracujesz/pracowałeś? Częstotliwość występowania problemów komunikacyjnych rośnie wraz z wielkością zespołu (nie, nie ma na to wzoru mamtematycznego opisującego zależność). Stąd w Scrum Guide zalecenie by zespół składał się z 5-9 członków (bo powyżej 9 ryzyko chaosu komunikacyjnego jest bardzo duże).
    Podejście deva do usterki jest w pewnym stopniu zależne od tego w jaki sposób zostanie mu przekazana ta informacja. Odpowiedzialność za skuteczność przekazania komunikatu wg mnie spoczywa w dużej mierze na nadawcy (czyli QA/testerze). I niestety są projekty/zespoły w których cel nie jest wspólny (tak, life is brutal).

  • stack_0verflow

    Akogo obchodza watpliwosci programisty? przeciez to jest zwykly klepacz kodu. Albo specyfikajca czy raport wymagan mowi co ma byc, albo nie. Cos jest niejednoznacze? To uderzam do analityka. Produkt jest zawsze dla klienta!

  • Marcel

    To niech klient zrobi sobie sam 😛

Skomentuj