Prelegenci i referaty

Software Quality Assurance… Czy tylko Software? O nieaplikacyjnych testach niefunkcjonalnych

Jakub Bryl

Główne tematy poruszone w prezentacji to: testy niefunkcjonalne, Software Quality Assurance, 4P, podejście usługowe, ITIL

Czy budowanie możliwe jest bez zarządzania, a zarządzanie bez budowania?

Andrzej Brzeziński

Jeszcze koledzy i koleżanki, czy już podwładni/współpracownicy? Jak się zachować w momencie, gdy jedna z osób z zespołu awansuje? Jak motywować bez narzędzi motywujących? Jakimi sposobami wzmacniać i wspierać zaangażowanie zespołu? Kłody pod nogi, czyli jak radzić sobie z przełożonymi… Testerzy są z Marsa a developerzy z Wenus, a może odwrotnie… Nie ma równych zespołów, różnorodność jest wskazana i potrzebna, ale co zrobić z gwiazdorem? W jaki sposób dać odpoczywać, a równocześnie mieć z tego pożytek… Jak zgrać ze sobą własny zespół z posiłkami z innych zespołów? Co zrobić, żeby inni nie zniechęcili się do tej roboty? Czy da się skutecznie rekrutować? Czy da się uniknąć błędów i pomyłek przy rekrutacji? Czy miarą skuteczności budowania zespołu może być jego stabilność w dłuższym okresie czasu?

Krok po kroku do zarządzanego zespołu – studium przypadku

Patrycja Czarnul – Gutowska

Grupa testerów, liczne wymagania, napięty harmonogram, wysokie oczekiwania względem rezultatów i główne pytanie, jak temu sprostać? Jak zorganizować i zarządzać zespołem, który będzie mógł w efektywny sposób zmierzyć się z licznymi zadaniami i pojawiającymi się w trakcie ich realizacji problemami?
Bez wątpienia nie ma jednej, niezawodnej metody, aby uzyskać dobre rezultaty. Zarówno otoczenie jak i cechy zespołu, które zależą od pojedynczych osób tworzących dany zespół są bardzo różne. Aby zaplanować i wdrożyć własne, indywidualne podejście dobrze jest przyjrzeć się już wcześniej wykorzystywanym w takich warunkach rozwiązaniom i doświadczeniom, które mogą stać się doskonałą inspiracją lub też uchronić przed pewnymi błędami.
W niniejszym artykule przedstawione zostanie studium przypadku z firmy telekomunikacyjnej opisujące etapy formowania zespołu prowadzące do jego pełnego zarządzania.

TDD to nie tylko Unit Testy

Michał Gaworski

Test Driven Development ewoluował jako jedna z praktyk Extreme Programming. W swej pierwotnej formie koncentrował się na kodzie źródłowym, w związku z czym jego podstawowym narzędziem stały się testy jednostkowe. Bliskość obu pojęć sprawiła, że w świadomości wielu ludzi stały się one tożsame co jest przekonaniem błędnym, natomiast bardzo rozpowszechnionym. Z mojej praktyki jako osoby biorącej udział w rekrutacji wynika, że ponad połowa kandydatów na testerów nie jest w stanie precyzyjnie wyznaczyć granicy.
Praktykując TDD w sposób naturalny mocno inwestuje się w Unit Testy, ale sam fakt posiadania dużej ich ilości nic nie mówi na temat tego, czy korzystamy z TDD. Dodatkowo jestem zwolennikiem tezy, że podejście TDD można z powodzeniem zastosować na innych poziomach testów rozszerzając je poza klasycznie rozumiane testy jednostkowe.

Moja prezentacja ma na celu:

Krótkie wprowadzenie do Test Driven Developmentu: przedstawiam ogólną koncepcję, cykl TDD wraz z wyjaśnieniem znaczenia kolejnych jego faz
Przedstawienie korzyści płynących z jego zastosowania jak wysokie pokrycie kodu testami i wysoka jego testowalność
Poparte przykładami omówienie najważniejszych pułapek w jakie można wpaść stosując tę metodologię
Określenie zależności pomiędzy testami jednostkowymi a TDD wraz z przykładami, pokazanie różnic
Udowodnienie, że TDD może być stosowany na wyższych poziomach testów niż UT
Wskazanie obszarów, gdzie TDD nie znajduje zastosowania

Testowanie w oparciu o automatyczne wykrywanie ryzyka.

Artur Górski

Testowanie oparte o ryzyko jest najstarszą, najbardziej naturalną i jedną z najbardziej skutecznych strategii testowania, która niestety jest pomijana przez większość firm oraz zespołów podczas ustalania taktyki testowania, estymacji poszczególnych zadań i przypisywania zasobów ludzkich. Podstawowymi czynnikami ryzyka jest prawdopodobieństwo wystąpienia awarii oraz koszt, jaki poniesie organizacja w przypadku jej wystąpienia. Pierwszy z czynników zależy od spraw technicznych; drugi jest czynnikiem biznesowym. Jako inżynierowie możemy analizować ten pierwszy, natomiast, aby zbadać czynnik biznesowy wymagana jest wiedza sponsorów, użytkowników etc. W niniejszym artykule zostanie pokazane podejście oraz aplikacja, która oprócz zarządzania testami umożliwia automatyczne badanie poziomu ryzyka dostarczając nam informacji dotyczących najbardziej ryzykownych wymagań, obszarów, testów itd. Otrzymane dane są wynikiem analizy kilku różnych czynników (na różnych okresach czasu) i mogą posłużyć jako cenna informacja podczas m.in. ustalania planu testów, estymacji oraz prioretyzowania zadań, oceny gotowości produktu etc.

Zarządzanie Zespołem Testów w dużych projektach informatycznych dla administracji publicznej

Damian A. Jankiewicz Arkadiusz Gawkowski

Opisano doświadczenia wynikające z organizacji i zarządzania Zespołem Testów w dużych projektach realizowanych na zamówienie administracji publicznej w latach 2004-2012. Czynnikami decydującym o sposobie zarządzania testami są: umiejscowienie Zespołu Testów w strukturze organizacyjnej projektu oraz liczność Zespołu z uwzględnieniem doświadczenia testerskiego poszczególnych osób.

Historia udanej automatyzacji. Testowanie w oparciu o warstwowo zorganizowane słowa kluczowe

Piotr Januszek, Monika Januszek

Większość testerów zetknęła się w swojej karierze z problemem automatyzacji. W dzisiejszych czasach automatyzacja to nie tylko przydatna możliwość, ale wręcz wymóg, którego zignorowanie może zagrozić powodzeniu całego projektu.
W trakcie swojego życia aplikacje rozrastają się, sprawiając, że manualne testy regresji stają się niewydajne, a ilość pracy potrzebna do wykonania pełnego przebiegu testowego wzrasta w zastraszający sposób wraz z poszerzaniem zakresu aplikacji. Dzięki automatyzacji wysiłek konieczny do przetestowania danej aplikacji daje się utrzymać na akceptowalnym poziomie.
Niestety, automatyzacja przeprowadzona nieskutecznie może okazać się równym – o ile nie większym – zagrożeniem dla projektu, co jej brak. W wielu wypadkach automatyzacja przeprowadzana jest spontanicznie, bez gruntownego przemyślenia i zaplanowania strategii.
Najpoważniejsze problemy w skutecznym wprowadzaniu automatyzacji, z jakimi się zetknęliśmy to:
─ Brak przejrzystości – Wśród osób bez zaplecza technicznego automatyzacja może być postrzegana jako „czarna magia”. Zrozumienie testu automatycznego wymaga umiejętności programistycznych, konfiguracji środowiska developerskiego.
─ Bardzo często automatyzacja uważana jest albo za jedyne słuszne rozwiązanie, albo za zbędny wysiłek.
─ Trudne w użyciu narzędzia – Bardzo często tworzenie testów automatycznych wymaga pisania skryptów w jakimś języku programowania. Uniemożliwia to osobom nie umiejącym programować pracę nad testami automatycznymi i podtrzymuje reputację „czarnej magii”
─ Koszty utrzymania testów – Wiele projektów automatyzacji testów upadło, ponieważ koszty utrzymania testów przekroczyły zyski. Często nie modernizowane testy były wyłączane i automatyzacja dawała w efekcie końcowym fałszywe poczucie bezpieczeństwa.
─ Brak porozumienia pomiędzy programistami, testerami a analitykami – Każda profesja mówi odmiennym językiem, a ich cele różnią się od siebie. O ile nie zostanie ustalony wspólny słownik, ryzykujemy powstanie nieporozumień, które mogą doprowadzić do niezrealizowania celu projektu.
Nasze doświadczenia pokazały nam, że nie zaadresowanie powyższych problemów znacznie zwiększa ryzyko niepowodzenia projektu automatyzacji. Dodatkowo, uznaliśmy, że zapewnienie przejrzystości testów automatycznych na wszystkich poziomach oraz wprowadzenie członków zespołu nie związanych z testowaniem do pracy przy automatyzacji testów znacznie zwiększyłoby szanse powodzenia projektu.
Kiedy rozpoczynaliśmy pracę nad wprowadzeniem automatyzacji, firma miała już za sobą nieudane próby automatyzacji testów produktu techniką record – replay. Odziedziczyliśmy zestaw kilku tysięcy testów, które były zależne od siebie, i których utrzymanie kosztowało więcej niż były warte. Mieliśmy również doświadczenia z testami pisanymi w języku Java, które były czytelne wyłącznie dla piszących je programistów.
Testowanie w oparciu o słowa kluczowe wydawało się dobrą drogą, jednak samo w sobie nie zapewniało potrzebnej nam przejrzystości.
Dlatego też sięgnęliśmy po wiedzę od dawna wykorzystywaną przez programistów i potraktowaliśmy projekt automatyzacyjny jak każdy inny projekt informatyczny, przenosząc sprawdzone praktyki inżynierii programowania (takich jak wprowadzenie uporządkowanych bibliotek czy reużywalność komponentów) na grunt testów automatycznych.

Zwinne Sposoby na Trudnego Klienta. Czyli Jak Zmieszać Oliwę z Wodą?

Kinga Krajewska

Jest to prezentacją doświadczeń Zespołu ds. Testowania Oprogramowania po projekcie prowadzonym wewnątrz przy pomocy narzędzi i praktyk programowania zwinnego, a na zewnątrz wpisującego się w kaskadowy plan pracy Klienta. Przedstawię najważniejsze punkty pozwalające testerom poznać istotę Agile i zaadaptować się do nowego środowiska. Następnie pokażę które elementy programowania zwinnego pomagały nam w pracy, z jakich zasad korzystaliśmy oraz co finalnie udało się uzyskać z tej wybuchowej mieszanki. Zdradzę tylko, że nie będę zachęcać do karkołomnych prób ożenku Agile z Waterfall-em, ale pokażę jak wykorzystać praktyki jednego na randce z drugim.

User Group – czyli ucz się i dziel wiedzą

Aleksander Lipski, Zbigniew Moćkun

Chcemy zainspirować entuzjastów, osób którzy mają pasję w jakimś kierunku do wspólnych spotkań i dzielenia się wiedzą oraz doświadczeniem. Jednym z lepszych sposobów na rozwijanie się w jakiejś dziedzinie jest umiejętność przekazywania swojej wiedzy innym, gotowość na konfrontację i obronę swoich poglądów w trakcie spotkań z innymi ludźmi z branży oraz otwartość na nowe pomysły. Chcemy pokazać, że takie lokalne spotkania i tworzenie grup poza własnym czasem nie kosztują zbyt wiele a korzyści płynące z takich spotkań są przeogromne

Tester i QA jako role w zespole Scrumowym

Rafał Markowicz

Podstawowe zagadnienia poruszone w prezentacji:

Czym jest Scrum
Zespół Scrumowy
Typowe problemy
Tester i QA jako rola

Pomiędzy Scrumem a Kanbanem – proces testowy

Zbigniew Moćkun

Jeszcze nie tak dawno większość testerów szukała swojego miejsca w metodykach miękkich takich jak Scrum czy XP Programing. Jednak już teraz część zespołów dusi się w nich i stara się być jeszcze bardziej agile, często zaciągając ulepszenia z Kanbana. Mieszanie metodyk mimo, iż daje bardzo dobre rezultaty wymaga nieszablonowego podejścia również od działu QA. W artykule pokażę jak w Cognifide zdefiniowaliśmy proces testowy dla metodyk miękkich takich jak Scrum, Kanaban oraz ich kombinacji. Napiszę jak zarządzamy defektami, jak poradziliśmy sobie z widocznością statusu projektu na Taskboard (w tym części powiązana z testami), dlaczego zaufaliśmy testom eksploracyjnym, a w końcu jak mierzymy wydajność naszego procesu testowego.

Techniki transferu wiedzy w procesie wdrażania testera w projekt

Ewa Nowicka, Łukasz Żebrowski

Infrastruktura informatyczna w dzisiejszych firmach stanowi sieć powiązań wielu współdziałających ze sobą systemów, nakładając na dział testowania konieczność posiadania dużej wiedzy o testowanych aplikacjach. Z drugiej strony presja otoczenia biznesowego na optymalizację kosztów zatrudnionych zasobów (np. poprzez outsourcing, zatrudnienie konsultantów), jak również małe bariery przy zmianie stanowisk pracy w ramach firmy lub pomiędzy firmami, zwiekszające rotację personelu, powodują, że kluczowymi kwestiami staje się zarządzanie wiedzą w organizacji oraz efektywność transferu wiedzy do nowych członków zespołu testowego. Niniejszy artykuł skoncentruje się na drugim zagadnieniu, czyli na efektywnym wdrożeniu testera
w projekt oraz skutecznym transferze wiedzy do nowego członka zespołu testowego. W oparciu o doświadczenia autorów w projektach dla firm z sektora telekomunikacyjnego, FMCG i administracji publicznej, przyjmując punkt widzenia Kierownika Testów w danym projekcie, zostanie zaproponowane jak efektywnie zaplanować proces przekazywania wiedzy, wdrożyć go, a następnie monitorować postępy w procesie transferu wiedzy.

Bezstratna kompresja listy przypadków testowych przeznaczonych do wykonania w testowaniu regresywnym

Piotr T. Piotrowski

Prezentacja opisuje metodę bezstratnej kompresji listy przypadków testowych przeznaczonych do wykonania w testowaniu regresywnym. Proponowane rozwiązanie jest znamienne tym, że składa minimum dwa przypadki testowe w jeden na podstawie analizy podobieństw między krokami wykonania każdego z tych przypadków, w tym, w zakresie zastosowanych identycznych rodzajów narzędzi testowych oraz ustawień narzędzia testowego, a także takiej konfiguracji narzędzia testowego, aby było możliwe jednoczesne zastosowanie różnych ustawień narzędzia testowego podczas jednego użycia narzędzia, bez zmiany kodu źródłowego tegoż narzędzia. Praca rozpoczyna się przeglądem dostępnych strategii testów regresywnych ze szczególnym uwzględnieniem postępowania z przypadkami testowymi. Następnie jest przedstawiona istota i przykład praktycznej realizacji tytułowej metody. Końcowa część zawiera głównie potencjalne korzystne skutki proponowanej odmiany strategii testów regresywnych.

Testowanie aplikacji webowych przy pomocy Selenium i TestNG

Jan Sabak

Warsztat ten ma za zadanie pomóc w zorganizowaniu testów aplikacji webowych przy pomocy narzędzi Selenium oraz TestNG. Zostaną na nim przedstawione te narzędzia oraz pokazany przykład organizacji i uruchamiania testów z ich użyciem.

Agenda warsztatów jest następująca:

Przedstawienie Selenium
Nagrywanie skryptów w Selenium
Eksport i edycja skryptów w Eclipse
PageObject
Przedstawienie bibliotegi TestNG
Konfiguracja uruchamiania skrytpów przy pomocy TestNG
Uruchamianie skryptów na różnych przelądarkach

Proszę o przyniesienie na warsztaty swoich własnych laptopów. Do wykonania wszystkich ćwiczeń będą wymagane następujące narzędzia:

Firefox
Selenium IDE
Eclipse + Maven

HP LoadRunner 11.00 – Protokół Ajax TruClient

Krzysztof Słysz, Michał Ziółek, Tomasz Osojca

HP LoadRunner jest zaawansowanym narzędziem do wykonywania testów wydajnościowych.

Pomimo faktu, że nowoczesne narzędzia testujące mają wbudowane mechanizmy nagrywania interakcji użytkownika, nadal pozostaje wiele czynności do wykonania, koniecznych aby skrypt nadawał się do użycia.

Nowa technologia TruClient upraszcza jedną z najbardziej czasochłonnych czynności związanych z wykonywaniem testów wydajnościowych jaką jest tworzenie skryptów.

Uczestnicy warsztatu nauczą się nagrywać, modyfikować i uruchamiać skrypty testów wydajnościowych.

Warunkiem uczestnictwa w warsztacie jest posiadanie własnego komputera na którym zainstalowany jest HP LoadRunner w wersji 11.00.
Instalację należy wykonać nie wcześniej niż 7 dni przed terminem konferencji.
Po instalacji narzędzia należy sprawdzić poprawność działania aplikacji szkoleniowej (Programy -> HP LoadRunner -> Samples -> Web) Plik instalacyjny należy pobrać z serwera Testwarez z kontem testwarez_loadrunner i hasłem TestWarez2012

Illusions about Software Testing

Hans Schaefer

This presentation is intended to help you argue for the need to check and test software. Many stakeholders involved in the software industry have illusions about testing that hinder you to do a good job. There are management illusions, developer illusions, tester illusions and user illusions.

The most common are:

Management illusions
- What is testing, at all
- Anybody can test
- You can test in quality
- Some products need no testing
- Automated testing vs. exploratory testing
Developer illusions
- My software has no bugs (or too few to care)
- The testers are going to find all bugs anyway
- Thorough unit testing is enough
Tester illusions
- I am allowed to stop bad software
- I need to test everything
- I can test everything
- If it works, it is good enough
- Thorough system testing is enough
Customer / User illusions
- Buy it and forget it
- We do not need to test
- Testers do not need to communicate with us

Some of these illusions have been argued against for a long time and it should be known that they are wrong. However, as testers, we still run into them and this creates trouble in our work. The final illusion is that the ones mentioned here are the only ones. This is not true: There are many more of them.

Kompletne środowisko do rozproszonego testowania automatycznego

Bartosz Szulc

Zdarza się, że praca testera może być postrzegana jako mało rozwijająca, czy nieciekawa. Szczególnie, gdy tester pracuje z projektami zarządzanymi w oparciu o przestarzałe podejścia, w których grupa testerów tworzy odrębny zespół wykwalifikowanych małpek, którego celem, przed wypuszczeniem kolejnej wersji aplikacji, jest przebrnięcie przez listę przypadków testowych, nie rzadko utrzymywanych w postaci przepasłej dokumentacji, stosu papieru, i stwierdzenie czy nowa wersja zawiera błędy.
Człowiek spędzający czas tak pracując może zacząć kwestionować sens pracy. Ba, jeżeli zależy mu na rozwoju, wręcz powinien. Nie powinien stawiać się w roli robota, posłusznie wykonującego kolejne kroki przypadku testowego, zaznaczając czas wykonania kroku, notując rezultaty i błędne zachowania aplikacji.
W nowoczesnym świecie, gdzie triumfy święcą podejścia lekkie i giętkie, zadaniem testera powinno być zapewnianie jakości, nie tylko tworzonego produktu, ale również wewnętrznych procesów w zespole. Powinien szukać usprawniań w założeniach, dokumentacji projektu. Wyszukiwać graniczne przypadki, problemy na granicy integracji komponentów, systemów, interakcji produktu ze światem zewnętrznym, użytkownikiem, ale przede wszystkim czuć, że jest integralną częścią zespołu.
Wykonywanie nużących, powtarzających się czynności, takich jak przechodzenie przez stosty scenariuszy testowych przy wypuszczeniu nowej wersji oprogramowania, powinno zostać zlecone automatowi, a cały proces zautomatyzowany.

Automatyzacja testowania systemu Network

Marcin Tyman, Piotr Górecki

Prezentacja przedstawia pewne rozwiązania wykorzystywane w procesie automatyzacji testów w firmie Proximetry. Przedstawia produkt tej firmy oraz ilustruje wygląd części środowiska do testów automatycznych. Zostały przedstawione konkretne rozwiązania wykorzystywane podczas tworzenia środowiska testowego wykorzystywanego do testów interfejsu użytkownika oraz środowiska do testów urządzeń sieciowych. Nie omawiamy kompleksowo wszystkich zagadnień dotyczących automatyzacji testów. Powinien jednak pomoc w zrozumieniu pewnych problemów związanych z tą tematyką, jak również podsunąć ciekawe pomysły zainteresowanym.

Odwrócona Piramida Testów

Wiktor Żołnowski

Prezentacja poświęcona jest omówieniu tematu automatyzacji testów systemów już istniejących od jakiegoś czasu, które dotąd nie były testowane w sposób automatyczny, lub testy automatyczne nie były wystarczające. Proces automatyzacji testów takich systemów jest odmienny od automatyzacji testów wdrażanej w projektach dopiero startujących.