Tag: trojqa

News

41.Spotkanie Code coverage


Kamil Łepek –
Code coverage – definicja i zastosowania

Podczas procesu wytwarzania oprogramowania posiłkujemy się różnego rodzaju metrykami, które mają na celu wsparcie oceny jakości produktu. Pokrycie kodu (ang. code coverage) to metoda pozwalająca nam uzyskać zbiór metryk, za pomocą których często jesteśmy w stanie wyciągnąć wiele wniosków na temat procesu testowania. Postaram się przedstawić to pojęcie oraz przybliżyć jego zastosowania.

Kamil Łepek: Absolwent Politechniki Gdańskiej (Matematyka). Obecnie pracuję jako Software Development Engineer w Intel Technology Poland w Gdańsku, gdzie na co dzień zajmuję się testami automatycznymi oraz procesem ciągłej integracji.Zdjęcie: w załączniku 🙂

prelegent

“## 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ę.

prelegent

ADVAnce Hardware Testing – czyli jak testujemy sprzęt

Testowanie oprogramowania czy sprzętu jest obowiązkiem każdej szanującej się firmy. Bez tego jakikolwiek produkt, który zostanie wydany na rynek będzie mieć problemy z konkurencją, która zadbała o testowanie podobnego sprzętu. W końcu media społecznościowe dokończą dzieła zniszczenia.
Obecnie mnogość firm produkujących różne sprzęty naszpikowane elektroniką powodują, że trzeba testować swój produkt i to na wielu płaszczyznach. Od testowania nie ma odwrotu i testy są w dzisiejszym świecie absolutnie konieczne. Testy jednostkowe, integracyjne, modułowe, weryfikacyjne, kompatybilnościowe, długoterminowe są obecne na etapie produkcyjnym w wielu firmach. Testowanie sprzętu wymaga specjalistycznej wiedzy, narzędzi i wiedzy jak ten sprzęt będzie wykorzystywany przez klienta.

Tester z ponad 10 letnim stażem w firmie ADVA Optical Networking. Historyk amator, recenzent książek i redaktor portalu historycznego konflikty.pl

prelegent

Yet another (User) Story

Krótka historia o komunikowaniu wymagań w projektach zwinnych za pomocą dobrze znanych, ale czasem nie zawsze używanych zgodnie z przeznaczeniem, historyjek użytkownika.

Rafał Borowiec, IT professional, open source enthusiast, developer, team leader, occasional blogger (http://blog.codeleak.pl/) and knowledge sharer.