„## rzeczy które jako QA zrobiłem/robię źle” – czyli…

„## rzeczy które jako QA zrobiłem/robię źle” – czyli przyjrzenie się warsztatowi i podejściu do pracy QA poprzez popełniane błędy

Czytamy książki, jeździmy na konferencje, kształcimy się, w zasadzie ciągle ubogacamy nasz warsztat pracy. Zdarzają się nam porażki, niepowodzenia – i dobrze – wyciągamy wnioski i idziemy dalej, rozwijamy się dzięki nim. Jednak co w sytuacji kiedy wydaje nam się, że osiągnęliśmy szczyt możliwości i nie widzimy nic do poprawy w swojej pracy. A może skupiamy się tak na pchaniu przysłowiowej taczki, że nie mamy czasu jej ładować?

• Przyjrzyjmy się naszej pracy w krzywym zwierciadle, od rzeczy prostych przez trudne – czy mamy sobie coś do zarzucenia?
• Przedstawię subiektywne elementy pracy QA, które nie działały lub nie działają dobrze, oczywiście nie ucieknę od przyznania się do swoich porażek.

Innymi słowy, spróbujmy spędzić wspólnie czas i pouczyć się na swoich błędach.

Daniel Dec

Zawsze jest coś do nauczenia, nigdy nie wie się wszystkiego – dzięki takiemu podejściu udaje się od wielu lat współtworzyć projekty i organizacje IT. Uważa, że lepiej być niemile dociekliwym niż przemilczeć niewygodne niejasności. Brał udział w projektach różnej skali i technologii, jako tester, lider, odpowiedzialny też za projekty kilkudziesięcioosobowe. Stara się być agnostykiem technologicznym uważając, że są to tylko narzędzia. Fascynat BDD/ATDD/XP/Lean. W trakcie swojej kariery między innymi miał okazję zajmować się testowaniem, automatyzacją testów, testami wydajnościowymi, zarządzaniem zespołem, szkoleniem i mentoringiem, wspomaganiem zespołów i klientów z nim współpracujących, ewaluacją procesów organizacji i wytwarzania oprogramowania oraz budowaniem satelity. Jako współpomysłodawca współtworzył konferencję Quality Excites oraz założył lokalną społeczność testerską Quality Meetup. Prelegent i warsztatowiec na wielu konferencjach.

Jego personalną misją jest zbliżanie programistów i testerów oraz biznesu do zespołów IT, sądząc, że wąskim gardłem w projektach informatycznych jest komunikacja i marnowanie potencjału uczenia się od siebie. Jest świadom ryzyka, że najlepsze idee wymyślone przez mądrych ludzi mogą nie zostać zaimplementowane w 100% jednak uważa, że warto do niektórych z nich dążyć.

Poza pracą, chwilowo bardziej smakosz piwa, niż jego producent, perkusista amator którego chwilowo zespół (ma nadzieję) się zawiesił, biega za piłką próbując zbudować dom usypiając małego rozrabiakę.