Prezentacja AADays 2016: Bartłomiej Bugajny - Jak efektywnie implementować piramidę testów?

 

Jeszcze przed przewagą zwinnych metodyk takich jak Scrum, wiedzieliśmy że powinniśmy automatyzować nasze testy – ale tego nie robiliśmy. Testy automatyczne zostały uznane za drogie w pisaniu i często powstawały miesiącami a nawet w niektórych przypadkach parę lat po tym jak dana funkcjonalność została zaimplementowana. Skuteczna strategia automatyzacji testów wymaga automatyzacji na trzech różnych poziomach – unit, integration, UI.
Koncepcja zakłada, że będziemy tworzyć jak najwięcej testów jednostkowych, mniej testów integracyjnch i web serwisów, a najmniej testów na warstwie UI (end to end). Zdecydowaliśmy się na to podejście przede wszystkim po to, by poprawiać jakość naszych aplikacji, skrócić czas uzyskania informacji zwrotnej o tym czy kod działa prawidłowo oraz zmniejszyć ilość testów manualnych. Ponadto chcemy się wzajemnie uczyć dostarczać aplikacje lepszej jakości – dzięki temu deweloperzy zrozumieją lepiej pracę testerską, a testerzy dowiedzą się od programistów co może zostać przetestowane np. w unit testach czy web serwisach. Jakie zmiany niesie ona ze sobą? Przede wszystkim kładziemy większy nacisk na komunikację w zespole pomiędzy programistą, testerem i analitykiem. Po wspólnym przejrzeniu przypadków testowych, decydujemy o tym na których poziomach piramidy testów chcemy umieścić testy – możliwie jak najniżej: Unit>Integration>UI tests. Wszelkie ustalenia ze spotkań staramy się trzymać w jednym miejscu: w opisie historyjek użytkownika, gdzie każdy je widzi i może zmieniać kiedy zauważy, że scenariusz biznesowy nie został pokryty testem. Większy nacisk na testy automatyczne (pisane przez deweloperow i testerów) z podejściem piramidy powoduje, że wykrywamy mniej błędów po skończonej historyjce użytkownika. W konsekwencji testy regresji trwają o wiele szybciej, dzięki czemu szybciej dostarczamy klientowi oprogramowanie wysokiej jakości. Stosujemy piramidę testów w projekach od zera oraz w projektach gdzie stosunek testów jednostkowych, integracyjnych i systemowych miał niewłaściwe proporcje.

Podczas prezentacji chciałbym przeprowadzić słuchaczy przez „case study” jednego z toczonych obecnie projektów, pokazać jak krok po kroku „budowaliśmy piramidę”. Pokażę czego się nauczyliśmy, jakie błędy popełniliśmy oraz jak to w obecnej sytuacji działa i czy daje wartość.

O autorze: Bartłomiej Bugajny to ekspert testowania, który od 2013 r. wspiera swoim doświadczeniem zespoły w Objectivity. Jak sam mówi: Quality Engineering to nie jego zawód, ale życiowa pasja, gdzie najwiekszą satysfakcję daje mu skrupulatna dbałość o jakość dostarczanego produktu. Bartek specjalizuje się w testach aplikacji webowych oraz desktopowych; a oprócz manualnych wykonuje także testy automatyczne z wykorzystaniem Selenium Web Driver oraz testów BDD (SpecFlow). Jego umiejętności techniczne potwierdza m.in. certyfikat ISTQB Advanced Level Test Manager. W Objectivity jest głównym testerem w programie składającym się z ponad 50 osób. Jego profesjonalna postawa i umiejętności społeczne uczyniły go dodatkowo reprezentantem zespołu w kontakcie z Klientem – w tej roli Bartek odpowiada za ułożenie procesów testerskich i równoważenie potrzeb Klienta oraz zespołu wedle firmowej filozofii Win-Win.

Od 2014 r. Bartek aktywnie współtworzy społeczność testerską angażując się w konferencje i inne wydarzenia branżowe. Do tej pory wystąpił m.in. na TestingCup 2014 (temat Współpraca egzotycznych ról, czyli jak na barkach BA, UX i QE oprzeć powodzenie projektu agile’owego, TestingCup 2015 (temat Od zera do bohatera), TestingCup 2016 (temat Applying Lean to Software Testing) oraz w 2015 r. na Agile & Automation Days z prezentacją How to automate Visual Testing.

Prezentacja AADays 2016: Tomasz Bonior Learning to Test, Testing to Learn

 

O tym jak rozwijać swoje umiejętności i jak wybrać tą najlepszą dla nas ścieżkę rozwoju.
Jakie możliwości rozwoju możemy mieć w pracy? Gdzie spotkać wiedzę dotyczącą pracy po pracy? Jak to wykorzystać żeby być spełnionym w pracy i nie „tracić” 8 godzin dziennie.
Będą przykłady z życia i dobre rady. Zapraszam jeśli chcesz posłuchać o tym, jak możesz usprawnić ten aspekt w Twojej codziennej pracy.

 

O autorze: Lider Quality Assurance z praktyką w zarządzaniu międzynarodowymi zespołami testowymi. Pasjonat i praktyk automatyzacji testów z doświadczeniem w projektowaniu, implementacji i utrzymaniu struktury testów automatycznych. Współorganizator KraQA – najlepszej inicjatywy lokalnych spotkań Testerskich ostatnich lat. Uważa, że ważnym elementem rozwoju jest wymiana doświadczenia, co intensywnie promuje. Wykładowca przedmiotu Techniki i narzędzia automatyzowania testowania oprogramowania na kierunku Testerzy Oprogramowania.

Podsumowanie konferencji Agile & Automation Days 2016

Temat przewodni tegorocznej konferencji czyli Mobile okazał się strzałem w dziesiątkę dla wielu z uczestników, ale pojawiły się głosy, że temat testów aplikacji mobilnych zbytnio zdominował agendę. Najczęściej pisaliście o tym, że chcielibyście jeszcze bardziej technicznych wykładów i warsztatów, prezentacji case study, konkretnych narzędzi i rozwiązań. Jeżeli chodzi o propozycje prelegentów, pojawiło się wiele nazwisk z zagranicy, ale też głosy, że chcielibyście ponownie usłyszeć Bartka Szulca i Piotrka Wicherskiego.

 



Czytaj więcej >>

Prezentacja AADays 2016: Piotr Wicherski - Laboratorium Urządzeń Mobilnych

Nowoczesne narzędzia skutecznie wspomagają proces wytwarzania oprogramowania mobilnego. Pomimo bardzo szybkiego wzrostu popularności aplikacji i stron mobilnych dojrzałość narzędzi i procesów jest wciąż na niższym poziomie niż w przypadku chociażby stron web. Już w maju 2015 roku raport Google inc. ostatecznie potwierdził, że liczba wyszukiwań mobilnych jest większa niż tych wykonywanych z komputerów osobistych. Jednym z najbardziej odstających obszarów jest testowanie mobilne. Narzędzia są niedojrzałe a sam proces i kryteria wymagają jeszcze sporo pracy. Prezentacja ta jest zbiorem pomysłów i sugestii, ma na celu wprowadzenie czytelnika w proces tworzenia projektu i budowania własnego laboratorium urządzeń mobilnych. Laboratorium urządzeń mobilnych ma być wsparciem procesu wytwarzania oprogramowania. Potencjalnie jest w stanie załagodzić jedne z głównych problemów, które napotykają testerzy w trakcie testowania aplikacji i stron mobilnych takich jak: fragmentacja, wysoki koszt urządzeń czy rozproszenie zespołów.

Przejdziemy przez wszystkie etapy procesu tworzenia laboratorium od planowania poprzez konfigurację środowisk po utrzymanie urządzeń. Nie zapominając o potencjalne, który niesie ze sobą posiadanie LUM. W trakcie prezentacji przedstawię proces projektowania i tworzenia LUM dla urządzeń opartych o system Android.

● Czym jest koncept laboratorium urządzeń mobilnych

● Jakie potencjalne zyski za sobą niesie

● Problemy i wyzwania w trakcie tworzenia farmy

○ Fragmentacja urządzeń

○ Koszt urządzeń

○ Potencjalne zalety posiadania własnego LUM

○ Potencjalne wady posiadania własnego LUM

● Analiza rozwiązań

● Możliwości rozwoju

 

SLAJDY PREZENTACJI >>

 

O autorze: Certyfikowany tester oraz pasjonat urządzeń mobilnych i systemów operacyjnych. W branży mobilnej od 8 lat. Pracował m.in. dla Samsung R&D i T­Mobile. Obecnie Senior Software Test Engineer w grupie Allegro pracuje z zespołami odpowiedzialnymi za aplikacje i środowiska mobilne.Jeden ze współorganizatorów WarszawQA (http://WarszawQA.pl). Jako członek zespołu The Mozilla Foundation uczestniczył we wdrażaniu Firefox OS na Polski rynek oraz wprowadzaniu pierwszego na świecie tabletu z FFOS. Administrator grupy Testowanie Oprogramowania na facebooku. Poza pracą zawodową czynnie wspiera organizacje i działania mające na celu propagowanie wiedzy i dobrych praktyk z obszaru jakości oprogramowania.

Prezentacja AADays 2016: Richard Bradshaw - Mobile - The Clue Is In The Name

 

It was once said to me that it’s a sin to test a mobile app at your desk, I suggested a slight alteration to ‘it’s a sin to only test a mobile app at your desk’. Mobile is difficult, mostly because, mobile. We will take a high level look at the challenges faced by mobile, and its technical challenges. There are tools we can take advantage of, they claim to make our mobile testing lifes easier, but is it the case? In this keynote we’re going to take a frank look at these tools, and how they can help us with our mobile testing, or not, as the case maybe.

So get your mobiles ready, take them of silent, let the journey commence.

 

O autorze: Richard Bradshaw – w swoich własnych słowach: doświadczony tester, konsultant i przyjacielski facet.

Dzieli się swoją pasją do testowania poprzez doradztwo, szkolenia i prelekcje na różne tematy związane z testowaniem. Fan automatyzacji wspierającej testowanie.

Dzięki ponad 10-letniemu doświadczeniu ma wiele spostrzeżeń na temat świata testowania i tworzenia oprogramowania. Richard jest aktywnym członkiem społeczności testerskiej i szefem Ministry of Testing. Pisze bloga thefriendlytester.co.uk, spotkacie go też na twitterze @FriendlyTester. Twórca własnego kanału YouTube Whiteboard Testing. Pracuje dla Friendly Testing dostarczając usługi doradcze i szkoleniowe. Można go często spotkać w barze z piwem w ręku dyskutującego na temat testowania.

Podczas Agile&Automation Days Richard wygłosił premierową prezentację keynote Mobile – the clue is in the name oraz poprowadził praktyczne warsztaty Technical Mobile Testing.

 

 

Prezentacja AADays 2016: Bartosz Szulc - Świeże spojrzenie na pokrycie testowe kodu

 

Każdy tester słyszał o pokryciu testami kodu produkcyjnego. O magicznym współczynniku, który w teorii powinien stwierdzać czy nasz kod produkcyjny jest w dobrej kondycji, bądź nie.
Badania naukowe dają niejednoznaczne wyniki. Kiedy już pojawi się badanie potwierdzające teorie, że lepsze pokrycie, to lepszej jakości kod, kolejnego dnia pojawia się kolejne dające odmienne wyniki.
Czy przy braku stanowczych dowodów na wpływ pokrycia testami na jakość kodu, powinniśmy o mierzeniu pokrycie zapomnieć? Wydaje mi się, że nie i podczas prezentacji zademonstruje informacje jaką można wyciągnąć z analizy pokrycia oraz do czego można ją wykorzystać.
Zaproponuje również świeższe spojrzenie na pokrycie kodu. Standardowo jako testerzy rozpatrujemy brak testu binarnie. Jest, dobrze, nie ma, żle. Takie czarno-białe spojrzenie powoduje problemy przy wyciąganiu wniosków i reagowaniu w oparciu o dane. Brakuje nam danych, które pomogłyby nam w odpowiedni sposób określić stratę jaka płynie z braku testu. W jaki sposób możemy tę stratę oszacować? Musimy zacząć spoglądać na raport z pokrycia oczami klienta i programisty.
W drugiej części wykładu pokaże w jaki sposób zebrać dane potrzebne do wyznaczenia wartości testu z punktu widzenia biznesu oraz wykonawcy, i jak te dane przełożyć na raport pokrycia kodu testami, tak aby wyciągnąć lepsze wnioski i w optymalniejszy sposób pokierować pracą przy naprawie aktualnej sytuacji.

 

SLAJDY PREZENTACJI >>

O autorze: Mentalnie tester. Sprawia mi niezwykła frajdę szukanie nietypowych przypadków i zadawanie nietypowych zadań, czy analiza złożonych problemów. Profesjonalnie nadal zielony. Przy wytwarzaniu oprogramowania pracuje ponad 6 lat. Zawsze mocno związany z testowaniem i jakością, chociaż często zmieniałem czapki, dzieląc czas pomiędzy eksplorację, a byciem liderem zespołu czy architektem.

Moją codzienną pracę mogę porównać jedynie do dziecka buszującego po sklepie ze słodyczami… ooo nowy commit, ooo nowy test automatyczny… ooo przyszły dane z produkcji… ooo nowy problem na produkcji… ooo nasz proces nie wydala.

Z jednej strony taki sposób pracy brzmi bardzo interesująco, z drugiej strony, ze względu na wachlarz zainteresowań, wątpię bym kiedykolwiek mógł siebie określić ekspertem w czymkolwiek. Co nie przeszkadza mi w dzieleniu się moją wiedza i przede wszystkim doświadczeniami podczas konferencji i meetup’ów. Sprawia mi to niezwykłą frajdę!

Prezentacja AADays 2016: Przemysław Libudzic - Równoległe testy automatyczne UI dla platformy iOS

W ciągu ostatniego roku dużo dobrego wydarzyło się dookoła platformy iOS. Jednak wiele rzeczy nadal jest trudnych do wykonania lub wdrożenia, jedną z nich jest zrównoleglenie działania automatycznych testów UI. Do najważniejszych zalet takiego rozwiązania należy oszczędność czasu (np. jeśli dobierzemy odpowiednią liczbę symulatorów tak, aby nie spowalniały one działania całego systemu MacOS, to długość trwania testów zależna będzie od najwolniejszego urządzenia, a nie od liczby urządzeń w kolejce do testów) i uzyskanie wyników testów z kilku urządzeń w podobnym czasie. Dzięki temu zwiększamy pokrycie platform przez testy, jednocześnie nie wzbudzając złości developerów (“Dlaczego to tyle trwa?!”). W trakcie prezentacji pokażę krok po kroku jak dla wybranego narzędzia do tworzenia testów UI można zrównoleglić testy poprzez: instalację potrzebnych zależności w systemie, dodanie odpowiednich skryptów do repozytorium aplikacji. Opowiem również jak dostosować rozwiązanie pod konkretne urządzenia oraz wersje systemów. Zaprezentuję też działanie w środowisku ciągłej integracji. Dodatkowo pokażę jak w ramach swojego samorozwoju rozwinąłem początkową ideę.
 

Slajdy prezentacji

 

O autorze: Tester aplikacji na iOS/Android/W10M, śledzący z zapartym tchem wszelkie nowinki technologiczne. Pracuje w Allegro na stanowisku Starszego Inżyniera Testów Oprogramowania i obecnie najwięcej czasu spędza przy testach automatycznych dla platformy iOS. Użytkownik smartfonów od 10 lat, świat testowania zgłębia od 5.