Agile & Automation Days 2018. Konkurs z wejściówką na konferencję. [aktualizacja - WYNIKI]

Agile & Automation Days 2018. Konkurs z wejściówką na konferencję. [aktualizacja - WYNIKI]
Ogłaszamy wyniki konkursu, w którym nagrodą jest wejściówka na konferencję Agile & Automation Days 2018!

[17.08.2018]

Konkurs na wejściówkę dobiegł już końca. Otrzymaliśmy od Was wiele ciekawych historii opisujących Wasze największe wyzwania testerskie - większość z nich na tyle interesująca, że wybranie jednej było dla nas nie lada trudnością! Niemniej jednak nasza Redakcja wyłoniła zwycięzcę, którym został p. Grzegorz.

Serdecznie gratulujemy, a zwycięską pracę zgodnie z obietnicą publikujemy poniżej.

 

Anna Jantar śpiewała, że „Najtrudniejszy pierwszy krok". Ktoś chyba jej słów za bardzo do serca sobotę nie wziął, bo mnie na początku mojej kariery testerskiej rzucono od razu na głęboką wodę. Moim pierwszym zadaniem było sprawdzenie, czy harmonogram zadań poprawnie uruchamia zadania zaległe. Brzmi trywialnie? To zanurzmy się nieco w ten temat. 

Wcześniej programowałem aplikacje okienkowe. Tak programowałem i w pewnym momencie przeniosłem się do innego zespołu, gdzie potrzebny był tester. Na pierwszy ogień musiałem przetestować coś, co śmiga poza interfejsem. Moduł ten był leciwy, więc ząb czasu skutecznie nadgryzł wszelką jego dokumentację wraz z programistami. Wiedziałem jedynie, że owe zadania zaległe to takie, które miały się wykonać, a z jakiegoś powodu do tego nie doszło. System powinien je wyzwolić przy najbliższej okazji. Przy czym jak już minie tyle czasu, że doszło do kolejnego uruchomienia zadania, to zapominamy o tych zaległych.

Moja programistyczna przeszłość dała mi złudną przewagę na resztą testerów, bo bez majstrowania zegarem systemowym mogłem oprogramować w bazie danych odpowiednie przypadki testowe. Wtedy chyba jeszcze nie wiedziałem, że tak to się nazywa. Problemy były dwa – ten moduł napisany był koszmarnie, więc buszowałem w kodzie, jak dziecko we mgle. Drugi, ważniejszy problem, to zupełny brak doświadczenia testerskiego, więc przypadki te były takie, że „u mnie działało”, a od klienta po pewnym czasie wróciło.

Na szczęście przez ten czas zagościłem na kilku konferencjach testerskich i temat jakości oprogramowania mnie zainteresował. Poznałem co to testy jednostkowe i wykorzystałem je do tego modułu. Ułatwiło to znacznie retesty i regresję.

W ciągu dwóch kolejnych lat zdobyłem solidną porcję wiedzy na szkoleniach. Spojrzałem jeszcze raz na przypadki w testach jednostkowych i tym razem rozpisałem je z głową – tak, by nie było ich ,ani za mało, ani za dużo, lecz w sam raz. Klasy równoważności i analiza wartości brzegowych bardzo mi w tym pomogły.

Na szkoleniach poznałem też temat testów eksploracyjnych. Zainwestowałem w kilka książek z tej tematyki („Expore IT” Elisabeth Hendrickson i „Exploratory software testing” James’a Whittaker’a). W tym czasie nasz zespół otrzymał zadanie napisania sławnego już harmonogramu od nowa. Testy jednostkowe napisałem z programistą. On dał mi kod, a ja mu dobrze przemyślane przypadki testowe. Całość uzupełniłem manualnymi testami eksploracyjnymi, gdzie skorzystałem przede wszystkim z mojego doświadczenia, a gdy skończyły się pomysły, zajrzałem na listę heurystyk testowych i jeszcze kilka defektów i znalezisk wyłowiłem.

Problem harmonogramu przewijał się przez całą moją dotychczasową drogę testerską i dla mnie jest takim odzwierciedleniem tego, jak bardzo dla tej roli potrzebne jest zdobywanie wiedzy i doświadczenia. Moje testy z czasem stawały się coraz lepsze, między innymi: skuteczniejsze, a za razem mniej kosztowne. Rozwój w tej dziedzinie stał się moją zawodową pasją i cały czas widzę, że jeszcze sporo w tej dziedzinie mam do odkrycia. Cieszę się, że ktoś kiedyś zaprosił mnie do swego zespołu jako testera. Chyba nawet nie wiedział, jakie tego będą skutki :).

 

Choć zwycięzca może być tylko jeden, postanowiliśmy podzielić się również inną ciekawą pracą nadesłaną przez p. Jędrzeja. Za drugą inspirującą historię nasza redakcja postanowiła nagrodzić autora zestawem testerskich gadżetów.

 

Praca testera oprogramowania niesie w sobie wiele niespodzianek. Wydaje mi się, że najwięcej niepewności i wyzwań napotkałem kilka lat temu, jeszcze na początku swojej kariery jako QA w obszarze aplikacji internetowych. Otóż pełen entuzjazmu i energii wyszukiwałem dużo nietypowych błędów, wiele z pogranicza mało prawdopodobnych przypadków brzegowych - były one realne technicznie, ale szansa ich wystąpienia znikoma. Przykładowo: osoba korzystająca z systemu zwykle umieszcza na stronie komponent, ale jeśli umieści się jeden komponent w drugim, a ten w trzecim i dodatkowo specyficznie skonfiguruje - style zaczynają nawzajem na siebie wpływać i finalny wygląd strony się rozpada. Błąd jest oczywisty, do tego całkiem poważny. Z drugiej strony przeciętny użytkownik nie ma nawet świadomości, że komponenty można zagnieżdżać. Po wielu dyskusjach poczułem się rozczarowany i niepewny - błąd, z którego znalezienia byłem taki dumny nie został od razu naprawiony. A jakby tego było mało ostatecznie trafił na listę "known issues" stanowiącą zbiór znanych defektów akceptowanych przez klienta (do potencjalnej naprawy w okresie po wdrożeniu). To, że byłem zdziwiony to mało powiedziane. To klient akceptuje błędy? To aplikacja nie będzie perfekcyjna w momencie publikacji? Od razu zakładamy, że coś będzie wymagało poprawy? A gdzie ideały i nieskazitelna jakość? 

Po jakimś czasie okazało się, że dla przedstawicieli klienta kluczowy był czynnik czasowy - przygotowany serwis musiał wystartować konkretnego dnia za względu na reklamy telewizyjne wykupione w kilku krajach Europy. Wtedy zrozumiałem, że na jakość produktu trzeba patrzeć z dużo szerzej perspektywy niż ja wcześniej. Należy możliwie szybko poznać tzw. "big picture" (czasami określany też mianem "helicopter view"), by jak najlepiej wspierać klienta i jego cele. Jakość jest pojęciem subiektywnym. Paradoksalnie, dużo ważniejsze niż naprawienie pojedynczego defektu jest zrozumienie jego realnego wpływu na finalny produkt. Nawet najlepszy proces, nie zagwarantuje, że w aplikacji nie będzie żadnego błędu, co pokazują historie najmocniejszych zespołów dysponujących gigantycznymi budżetami (jak chociażby NASA). Dlatego świadomość ryzyka i jego monitorowanie to coś istotniejszego niż suche listy znalezionych usterek. 

Wówczas niepewność ustąpiła u mnie miejsca chęci nauczenia się, jak budować efektywny proces testowy. Zależało mi, by nie tylko gwarantować najwyższą jakość, ale też podążać za potrzebami użytkowników i celami biznesowymi. Z czasem zacząłem zagłębiać się w techniki testów oparte o ryzyku (risk-based analysis), które zaskakująco dobrze udało mi się wpleść w codzienną pracę w metodologii scrum. Analizę ryzyka każdy z nas wykonuje wiele razy dziennie - gdy przebiegamy przez ulicę, podejmujemy leczenie, kupujemy rzeczy w Internecie. Podobnie jak w tabeli ROAM, część z tych ryzyk akceptujemy, inne staramy się zmniejszyć (mitigate - np. zabierając parasol w pochmurny dzień), ale są też takie, których nie podejmiemy nigdy. Podobnie w testowaniu: warto uzależnić intensywność, narzędzia i techniki testów od ryzyk związanych z implementacją danej funkcjonalności. Przede wszystkim zaś należy znać ryzyko związane z tworzonym system. Równie istotne są oba jego komponenty: prawdopodobieństwo i wpływ. Rozumiejąc je jesteśmy w stanie świadomie i odpowiedzialnie wspierać osoby decyzyjne.

Pomimo wielu lat pracy jako QA, wciąż szukam nowy rozwiązań, pomysłów, technik, starając się uniknąć utknięcia w świecie szablonów. Myślę, że są trzy najważniejsze rzeczy, których dotychczas się nauczyłem. Po pierwsze, nie można skupiać się tylko na ticketach w bugtracerze, trzeba patrzeć dużo szerzej na całe ryzyko projektowo-produktowe. Po drugie, warto eksperymentować łącząc dziedziny i podejścia (np. wplatając analizę ryzyka w ceremonie scrumowe). Po trzecie, i najważniejsze, nauka to stały element pracy dobrego testera. To jednocześnie i wymóg, i przywilej, jaki niesie w sobie branża IT.

 

testerzy.pl są Partnerem Strategicznym Agile & Automation Days 2018. W imieniu własnym oraz Organizatorów konferencji dziękujemy wszystkim za nadesłane prace i udział w konkursie.

 

 

[6.08.2018]

Mottem tegorocznej edycji jest "Zmierz się z niepewnością, zintensyfikuj uczenie się". Dlatego też w ramach konkursu chcielibyśmy poznać Wasze doświadczenia związane z niepewnością i nauką z tego płynącą.

Opiszcie nam swoje największe wyzwanie testerskie - co było Waszą największą niewiadomą i wyzwaniem, z którą musieliście się zmierzyć? Jak sobie z tym poradziliście? Czego się nauczyliście?

Na pracę macie do wykorzystania pulę znaków w granicach między 3000 a 5000. Zgłoszenia prosimy przesyłać do 13 sierpnia br. na adres kontakt@testerzy.pl z dopiskiem "Konkurs - bilet na AA Days".

Zwycięzcę ogłosimy 17 sierpnia br. w samo południe!

 

Czy warto wziąć udział w naszym konkursie? Zapraszamy do zapoznania się z programem Agile & Automation Days, by poznać odpowiedź - http://aadays.pl/program-schedule/

Wejściówka o wartości 1200 zł netto obejmuje udział w dwóch dniach konferencji, w jednych wybranych przez siebie warsztatach oraz w przyjęciu integracyjnym.

 

Z ciekawością czekamy na Wasze zgłoszenia!

 

Zasady konkursu:

  1. Konkurs potrwa od 30 lipca br. do 13 sierpnia br., godz. 23.59.

  2. O wyniku konkursu poinformujemy na stronie testerzy.pl w poniedziałek 17 sierpnia br. o godzinie 12.00.

  3. Ze zwycięzcami skontaktujemy się mailowo najpóźniej do dwóch dni roboczych od daty publikacji wyniku.

  4. W celu otrzymania nagrody, rejestracji na konferencję Agile & Automation Days, zwycięzca powinien podać w korespondencji mailowej swoje dane osobowe (imię, nazwisko, adres mailowy, nr telefonu kontaktowego). 

  5. Uczestnicy konkursu wyrażają zgodę na publikację na stronie testerzy.pl informacji o wygranej i/lub treści nadesłanej odpowiedzi.

  6. Organizator zastrzega sobie prawo do publikacji wybranych prac oraz do nieprzyznania nagrody w przypadku prac, które nie spełniają wytycznych.

  7. Konkurs prowadzony jest tylko dla osób pełnoletnich.

  8. Nie ma możliwości wymiany nagrody na ekwiwalent pieniężny.

  9. Uczestnicy konkursu, poprzez swoją aktywność, akceptują postanowienia powyższych zasad.

 

 

To powinno Cię zainteresować