[TestWarez 2017] Mutacyjne testowanie oprogramowania w aspekcie Test Driven Development
•
0 likes•211 views
Test Driven Development opiera się na tworzeniu oprogramowania w sposób iteracyjny, gdzie test jest kluczowym elementem procesu. Tworzenie oprogramowania w tej metodyce podnosi naszą pewność odnośnie jakości kodu oraz tego, że testy go lepiej pokrywają. Niestety ta technika przerzuca odpowiedzialność za jakość kodu na testy. Jedną z odpowiedzi na ten problem mogą być techniki testowania mutacyjnego. Proponujemy zatem usprawnienie techniki TDD o testowanie mutacyjne (TDD+M). Wykażemy na podstawie eksperymentu porównującego TDD z TDD+M wpływ testów mutacyjnych na technikę Test Driven Development oraz pokażemy ogólne wrażenia zespołu programistów biorących udział w eksperymencie. Pokażemy także na konkretnych przykładach, że testowanie mutacyjne to nie tylko poprawa jakości testów, ale także dobre narzędzie do wychwytywania błędów czy słabości projektowych (numerycznych, algorytmicznych oraz ideowych), co może dawać nam pewnego rodzaju zautomatyzowaną alternatywę dla code review.
Report
Share
Report
Share
Download to read offline
Recommended
Jakakolwiek komunikacja odbywa się w relacji. Wywieranie wpływu, perswazja, przekonywanie odbywa się w ramach relacji. Praca analityka biznesu z klientem odbywa się w ramach utworzonych relacji. Kto opanuje sztukę perswazji zyskuje niezwykłą przewagę w procesie kontaktu z klientami. Przewaga ta jednak nie polega na znajomości jakiejś techniki, z którą wchodząc do klienta doprowadzamy go do współpracy i uzyskujemy niezbędne informacje. To nie jest technika, to idealne dopasowanie się do klienta, odkrycie jego potrzeby i zaspokojenie jej. Najważniejsze jest to, że liczą się niuanse, drobne szczegóły, a jednocześnie całość.Miękkie umiejętności w pracy analityka biznesu
Miękkie umiejętności w pracy analityka biznesuStowarzyszenie Jakości Systemów Informatycznych (SJSI)
The 7 Skills model helps IT projects to become more successful by addressing the key success factor of all teams: the soft skills of the team members. The model starts from two assumptions: (a) true success is a matter of good teamwork and (b) good teamwork is based on emotional interactions between individuals. The model is aligned along two axes: the ‘Customer facing’ - ‘Team facing’ axis and the ‘Problem facing’ – ‘Solution facing’ axis. In the center is ‘Communication’ as the fundamental skill that is the starting point for all interactions. Arranged around this core you find six key skills that are important for every IT project: ‘Empathize’ (customer/problem), ‘Explore’ (team/problem), ‘Collaborate’ (team), ‘Ideate’ (team/solution), ‘Tell’ (customer/solution) and ‘Sell’ (customer). The 7 Skills model serves as a road map to improve human interactions in development projects. To implement it, each skill has been substantiated by one or more simple but proven techniques. To mention some: communicate – Shannon-Weaver model; empathize – Personas; Explore – goal trees; Collaborate – Belbin team roles; Ideate – Wallas’ creativity model; Tell – storyboarding; Sell – Cialdini’s principles. These techniques of the 7 Skills model can easily be presented and explained. However, to make them work, one should exercise them. Therefore, a workshop is an excellent way to transfer the concept: you will learn most by actually doing it. In this workshop, you will work with other participants in a small team to design the outlines of a simple IT system. We will explain all techniques and give you some practical exercises with a challenging selection of them.7 Skills for highly effective teams - workshop
7 Skills for highly effective teams - workshopStowarzyszenie Jakości Systemów Informatycznych (SJSI)
As Business Analysts we encounter difficult customers every day. That is why we need a specific toolset to deal with such people and create win-win situations for our projects. The main goal of this workshop is to give you such an arsenal. The whole workshop will be divided into three parts: 1. How to identify different type of customers and how to negotiate with them – you will get familiarized with several different types of personalities and learn how to analyze your own stakeholders with these properties. For each type we will define the specific set of tools to be used during meeting and in day-to-day work. Afterwards I will ask you to characterize some of the people that you are working with to seek out the best approach to negotiate with them 2. Visualizing goals as a part of creating interactive meetings – you will learn how to create impact maps and how to use them in your work. As Impact Maps may be used not only in IT projects it’s a viable tool to be used even in your personal life. On this part we will also talk about design thinking and how it can be used to make your kick-offs/discoveries better. Therefore during this part of the workshop we will: a. Learn how to create good business goals b. Draw our own impact map (based on a created goal) c. Learn how to validate requirements using impact mapping technique d. Transform impact map into a backlog e. Learn about design thinking approach and how to use it in your work 3. Case studies and discussion – I will present several complex cases that I’ve encountered during my career and will describe business analysis techniques that I used. Afterwards we will analyze your own cases and try to find the appropriate solutions together.Dancing with the devil - how to cooperate with a problematic customer
Dancing with the devil - how to cooperate with a problematic customerStowarzyszenie Jakości Systemów Informatycznych (SJSI)
Recommended
Jakakolwiek komunikacja odbywa się w relacji. Wywieranie wpływu, perswazja, przekonywanie odbywa się w ramach relacji. Praca analityka biznesu z klientem odbywa się w ramach utworzonych relacji. Kto opanuje sztukę perswazji zyskuje niezwykłą przewagę w procesie kontaktu z klientami. Przewaga ta jednak nie polega na znajomości jakiejś techniki, z którą wchodząc do klienta doprowadzamy go do współpracy i uzyskujemy niezbędne informacje. To nie jest technika, to idealne dopasowanie się do klienta, odkrycie jego potrzeby i zaspokojenie jej. Najważniejsze jest to, że liczą się niuanse, drobne szczegóły, a jednocześnie całość.Miękkie umiejętności w pracy analityka biznesu
Miękkie umiejętności w pracy analityka biznesuStowarzyszenie Jakości Systemów Informatycznych (SJSI)
The 7 Skills model helps IT projects to become more successful by addressing the key success factor of all teams: the soft skills of the team members. The model starts from two assumptions: (a) true success is a matter of good teamwork and (b) good teamwork is based on emotional interactions between individuals. The model is aligned along two axes: the ‘Customer facing’ - ‘Team facing’ axis and the ‘Problem facing’ – ‘Solution facing’ axis. In the center is ‘Communication’ as the fundamental skill that is the starting point for all interactions. Arranged around this core you find six key skills that are important for every IT project: ‘Empathize’ (customer/problem), ‘Explore’ (team/problem), ‘Collaborate’ (team), ‘Ideate’ (team/solution), ‘Tell’ (customer/solution) and ‘Sell’ (customer). The 7 Skills model serves as a road map to improve human interactions in development projects. To implement it, each skill has been substantiated by one or more simple but proven techniques. To mention some: communicate – Shannon-Weaver model; empathize – Personas; Explore – goal trees; Collaborate – Belbin team roles; Ideate – Wallas’ creativity model; Tell – storyboarding; Sell – Cialdini’s principles. These techniques of the 7 Skills model can easily be presented and explained. However, to make them work, one should exercise them. Therefore, a workshop is an excellent way to transfer the concept: you will learn most by actually doing it. In this workshop, you will work with other participants in a small team to design the outlines of a simple IT system. We will explain all techniques and give you some practical exercises with a challenging selection of them.7 Skills for highly effective teams - workshop
7 Skills for highly effective teams - workshopStowarzyszenie Jakości Systemów Informatycznych (SJSI)
As Business Analysts we encounter difficult customers every day. That is why we need a specific toolset to deal with such people and create win-win situations for our projects. The main goal of this workshop is to give you such an arsenal. The whole workshop will be divided into three parts: 1. How to identify different type of customers and how to negotiate with them – you will get familiarized with several different types of personalities and learn how to analyze your own stakeholders with these properties. For each type we will define the specific set of tools to be used during meeting and in day-to-day work. Afterwards I will ask you to characterize some of the people that you are working with to seek out the best approach to negotiate with them 2. Visualizing goals as a part of creating interactive meetings – you will learn how to create impact maps and how to use them in your work. As Impact Maps may be used not only in IT projects it’s a viable tool to be used even in your personal life. On this part we will also talk about design thinking and how it can be used to make your kick-offs/discoveries better. Therefore during this part of the workshop we will: a. Learn how to create good business goals b. Draw our own impact map (based on a created goal) c. Learn how to validate requirements using impact mapping technique d. Transform impact map into a backlog e. Learn about design thinking approach and how to use it in your work 3. Case studies and discussion – I will present several complex cases that I’ve encountered during my career and will describe business analysis techniques that I used. Afterwards we will analyze your own cases and try to find the appropriate solutions together.Dancing with the devil - how to cooperate with a problematic customer
Dancing with the devil - how to cooperate with a problematic customerStowarzyszenie Jakości Systemów Informatycznych (SJSI)
Analityk biznesowy analizuje biznes? W większości przypadków – nie. Projekty wypadają nam jak z czarnej skrzynki. Czy mają sens? Czasem trafiają jak kula w płot. Czasem są jak armata na muchę. Czasem nie rozwiązują właściwego, najbardziej naglącego problemu. A czasem decydent chce zabawkę lub awans, zapominając o klientach i rozwoju firmy. Czy to problem analityka? Czy Twój projekt jest właściwy dla firmy? Przyjrzyjmy się temu, co dzieje się ponad projektem - analizie prawdziwie biznesowej, analizie organizacji i analizie strategicznej. Rozwikłamy zagadkę - skąd biorą się sensowne projekty i dowiemy jak definiować potrzebne firmie inicjatywy.Analiza prawdziwie biznesowa - skąd biorą się projekty
Analiza prawdziwie biznesowa - skąd biorą się projektyStowarzyszenie Jakości Systemów Informatycznych (SJSI)
If Internet of Things is all about connectivity and cooperation then Industry 4.0 is based on data. In fact - lots of data! We are no longer talking about GigaBytes or TeraBytes but rather such abstract ideas and units like ExaBytes. And that's the main topic of this presentation - how huge is IoT, what is the value of switching from reactive to predictive company and why we use lambda architecture in the first place. And even if the concept of security, ethics, rules and regulations regarding data itself is also interesting on its own, this time we will focus directly on Industry 4.0 itself. Fast paced and intense presentation dedicated for Analysts and people loving and caring about IoT. Internet of Things loves data - analysis of Industry 4.0
Internet of Things loves data - analysis of Industry 4.0Stowarzyszenie Jakości Systemów Informatycznych (SJSI)
Biznes się zmienia. IT się zmienia. Ale czy narzędzia i metody pracy analityka i architekta zmieniają się lub powinny zmienić się - w szczególności w czasach coraz powszechniejszej robotyzacji procesów? W prezentacji będę starał się spojrzeć na relacje występujące między analitykiem-architektem a robotami z dwóch różnych perspektyw – tj. czy musimy inaczej niż do tej pory podejść do analizy i architektury zrobotyzowanego biznesu i jak roboty mogą pomóc w pracy analityka/architekta. Okazuje się bowiem, że coraz częściej wiele firm patrzy na analityków/architektów jako koszt (który może i przynosi korzyści, ale mocno odroczone w czasie) i zastanawia się, czy jest jakieś podejście umożliwiające podniesienie efektywności pracy tych ról.Analityk i architekt w czasach automatyzacji i robotyzacji biznesu
Analityk i architekt w czasach automatyzacji i robotyzacji biznesuStowarzyszenie Jakości Systemów Informatycznych (SJSI)
Każdy nowy pomysł, który chcemy zrealizować korzystając czy to z zasobów firmy czy też wsparcia inwestorów, musimy umieć skutecznie przedstawić. Najczęściej decydenci nie mają zbyt dużo czasu, aby zapoznać się ze wszystkimi szczegółami projektu. Jak ich przekonać w ciągu 5 minut? Co ich najbardziej zainteresuje? Jak powinna wyglądać skuteczna prezentacja? Im lepiej ją przygotujemy, tym większą mamy szansę na decyzję zgodną z naszymi oczekiwaniami. Zapraszam do wspólnego przyjrzenia się modelowi krótkiego, skutecznego przedstawiana pomysłów, który przydaje się w kontaktach z decydentami korporacji, z klientami czy z inwestorami.Jak sprzedać swój pomysł w 5 minut, czyli pitch deck dla BA
Jak sprzedać swój pomysł w 5 minut, czyli pitch deck dla BAStowarzyszenie Jakości Systemów Informatycznych (SJSI)
Każdy z nas słyszał termin „testowanie techniczne”. Wielu z nas mówi o sobie z dumą „tester techniczny”. Rynek potrzebuje „testerów technicznych”. Czy jednak wszyscy zgadzamy się w rozumieniu tych terminów? Kto i na jakiej podstawie powinien decydować co jest, a co nie testowaniem technicznym?
Prezentacja na pograniczu filozofii i technikaliów próbuje usystematyzować terminologię i zamieszać w głowach słuchaczy.[TestWarez 2017] Skomplikowane testowanie, skomplikowane terminy. Testowanie ...
[TestWarez 2017] Skomplikowane testowanie, skomplikowane terminy. Testowanie ...Stowarzyszenie Jakości Systemów Informatycznych (SJSI)
Przychodzi tester do lekarza…
Można by tak rozpocząć opis tej prelekcji. Nie o lekarza jednak tu będzie chodziło, a o rozmowy rekrutacyjne i to, co na nich można usłyszeć. Jestem członkiem grupy rekrutacyjnej w mojej firmie. Przeprowadziłem naprawdę sporo takich rozmów. Jedne bardziej udane, inne trochę mniej. Zauważyłem jednak jeden trend, który ostatnio coraz częściej zaczął się pojawiać na rozmowach - chęć do rozwoju w kierunku automatyzacji testów. Czy jednak wiecie z czym to się je?
Prelekcja skierowana jest do ludzi mniej doświadczonych, którzy po okresie okrzepnięcia w zawodzie dopiero zaczynają zastanawiać się nad swoją przyszłością, nad ścieżką swojej kariery. Jako lider spotkałem się też z osobami, które nie były świadome, w jakich kierunkach może rozwijać się tester. A możliwości jest naprawdę wiele. Tylko co wybrać?
Sam przeszedłem bardzo ciekawą drogę. Zdobyłem bardzo różnorodne doświadczenie, miałem przyjemność obserwować ludzi, ich rozwój, wybory, które czasem nie były trafne. Chciałbym się zatem podzielić z wami moim doświadczeniem liderskim, pokazać jak wygląda droga w kierunku managera, test leada, jakie wyzwania czekają na tej drodze.
Chciałbym także opowiedzieć o tym, jak zostać testerem, który automatyzuje; pokazać jak wygląda dzień z życia takiego testera, jakie wyzwania czekają nas po drodze i czego potrzebujesz droga koleżanko, drogi kolego, aby być w tej działce kimś ciekawym, na kogo rekruter zwróci uwagę.
Chciałbym również porozmawiać trochę o motywacji, która sprawia, że ludzie wybierają właśnie tę drogę.Czy to tylko podążanie za modą? Wszak nie wszyscy będziemy automatyzować.
Powiem także kilka słów o innych ścieżkach kariery testerskiej, może mniej oczywistych, ale z życia wziętych, z pracy w moim zespole.
Wystąpienie to skierowane jest do ludzi dopiero rozpoczynających swoją karierę, lecz być może, że coś ciekawego znajdzie dla siebie doświadczony wędrowiec.[TestWarez 2017] Przychodzi tester na rozmowę...
[TestWarez 2017] Przychodzi tester na rozmowę...Stowarzyszenie Jakości Systemów Informatycznych (SJSI)
Mikroserwisy to słowo, wokół którego cały świat IT kręcił się w ostatnich latach. Nowe podejście do architektury miało zapewnić szybkie oraz wygodne budowanie modularnych, niezawodnych, a przede wszystkim łatwo skalowalnych systemów. Wszystko wskazuje na to, że faktycznie się udało. Idea mikrousług, która jeszcze kilka lat temu brzmiała jak odświeżone SOA (które przecież absolutnie się nie przyjęło), dziś nie jest już niczym dziwnym i jest powszechnie stosowana w wielu organizacjach.
Faktycznie, mikroserwisy zrobione dobrze rozwiązują wiele problemów, które pojawiały się w przypadku monolitycznych systemów. Niestety zrobione źle, o co nietrudno, mogą przynieść więcej problemów niż korzyści. Mimo że mamy coraz więcej doświadczenia z tym podejściem do architektury, cały czas spotykamy się z nowymi wyzwaniami, dla których rozwiązania sprawdzające się przy monolitach okazują się niewystarczające, nie tylko w przypadku samego kodu czy designu, ale także w obszarze zapewniania jakości.
Sprawdzenie wydajności pojedynczej aplikacji nie jest proste. Sprawdzenie wydajności dwustu aplikacji, które działają razem, zależą od siebie i komunikują się ze sobą, jest po prostu bardzo trudne. W swojej prezentacji chciałbym opowiedzieć, jak podchodzimy do tego tematu w Ocado oraz przedstawić narzędzie do automatycznych testów wydajnościowych - Gatling.[TestWarez 2017] A proper gun makes testing fun
[TestWarez 2017] A proper gun makes testing funStowarzyszenie Jakości Systemów Informatycznych (SJSI)
Przy rosnącym skomplikowaniu aplikacji ilość testów „niezbędnych” do wykonania może zwiększać się w wykładniczym tempie. Jak nad tym zapanować, czy w ogóle jest to możliwe? Czy można zachować dobre pokrycie testowe zmniejszając ilość testów? Jak nie zgubić celu testowanej funkcjonalności czy nawet całej aplikacji?
Na bazie swoich doświadczeń chciałbym przedstawić odpowiedzi na te pytania oraz pokazać drogę jaką przeszły nasze testy od szczegółowych „Przypadków Testowych” do testów opierających się na „Klienckich Przypadkach Użycia” („Customer Use Case”).
Wystąpienie będzie miało na celu przedstawienie koncepcji optymalizacji testów bazującej na „Klienckich Przypadkach Użycia”, gdzie „Kliencki Przypadek Użycia” rozumiany jest jako informacja na temat wykorzystania danej funkcjonalności bądź aplikacji przez końcowego odbiorcę. Zaprezentowane zostaną korzyści z położenia nacisku na testowanie kluczowych elementów z punktu widzenia klienta. Słuchacze zapoznają się z przykładami zoptymalizowanych i niezoptymalizowanych testów. Scharakteryzowane zostaną wady i zalety takiego podejścia.[TestWarez 2017] „Przypadek Testowy” a „Kliencki Przypadek Użycia”
[TestWarez 2017] „Przypadek Testowy” a „Kliencki Przypadek Użycia”Stowarzyszenie Jakości Systemów Informatycznych (SJSI)
equirements. And projects sometimes forgot about nonfunctional requirements.
How Performance tester can help in such situation?
In my presentation I’m presenting techniques, which I’m using – when project needs performance testing, and comes to my team when no performance requirements are specified:
• How we can learn how many users will work with the system?
• How can we know – what response times users will accept?
• What if users are located around the globe?[TestWarez 2017] Requirements for Performance Testing
[TestWarez 2017] Requirements for Performance TestingStowarzyszenie Jakości Systemów Informatycznych (SJSI)
Continuous Delivery enables us to deliver software quickly and with high quality, ideally keeping our application production-ready with each code change, allowing us to ship that change right away. It is not a trivial process to introduce in a project or organization though. But can something as complicated as Continuous Delivery get even more complex?
'Shift left' approach to testing, risk analysis, consistent environments and build processes thanks to Chef, Vagrant and Jenkins Pipelines and a backlog that is possible to deliver in such methodology - these are only a few of elements that help us reach that goal.
When going from monolithic architecture of our application to microservices realm a myriad of new challenges are born. How complicated our build pipelines get and how can we easily orchestrate them? What if your application is not as modular as you would like it to be? What if your client is not quite ready for the dynamics that CD brings? And most importantly, how to maintain the same quality level with the above problems?
I would like to share my thoughts regarding these questions and on the future of DevOps in the quality-focused world.
To gain the most from the presentation, the audience should be familiar with:
microservices and monolithic architecture
continuous delivery
shift-left approach to testing
the general idea about tools for configuration management, service discovery[TestWarez 2017] Continuous Delivery and beyond
[TestWarez 2017] Continuous Delivery and beyondStowarzyszenie Jakości Systemów Informatycznych (SJSI)
Moje wystąpienie będzie studium przypadku. Opowiem w nim o wyzwaniu w projekcie, przed jakim stanęliśmy razem z zespołem. Problem był dość duży - w projekcie nie było automatycznych testów funkcjonalnych, a aplikacja mobilna ciągle rosła i przybywało nowych funkcjonalności. Dodatkowo klient nalegał na częstsze dostarczenia kolejnych wersji. Postaram się nakreślić architekturę aplikacji oraz wymagania, jakie postawione zostały przed frameworkiem do testów automatycznych. Opowiem o powodach stojących za podjętą decyzją o nieskorzystaniu z istniejących narzędzi/frameworków (np. Appium, Calabash) oraz o dokonanym wyborze - narzędziu XCUITest od Apple. W kolejnej części pokażę problemy, jakie napotkaliśmy implementując własny framework oparty o XCUITest - te dotyczące samego narzędzia, ale także i egzekucji testów oraz raportowania. Wskażę na jakich etapach prac na nie natrafiliśmy oraz czy (i jak) je rozwiązaliśmy. Na końcu przedstawię aktualny status - gdzie jesteśmy prawie 2 lata później. W podsumowaniu chciałbym wspomnieć o tym, co zadziałało w naszym podejściu, jakie decyzje były dobre, z czego – jako zespół - jesteśmy szczególnie dumni, co moglibyśmy polecić innym oraz co zostało jeszcze do zrobienia.[TestWarez 2017] Framework testowy aplikacji mobilnej dla systemu iOS - czy ...
[TestWarez 2017] Framework testowy aplikacji mobilnej dla systemu iOS - czy ...Stowarzyszenie Jakości Systemów Informatycznych (SJSI)
Podejścia zwinne oparte są o zmiany – metamorfozę w wytwarzaniu i zarządzaniu operacyjnym (ludzie, procesy i technologie), umożliwiającą dostarczanie innowacyjnego oprogramowania tak szybko, jak to możliwe. Pomimo tych wszystkich przekształceń, jeden element wydaje się niezachwiany. To proces testowania oprogramowania. Według różnych badań, 70%-88% organizacji przyjęło zwinne podejście do wytwarzania oprogramowania, podczas gdy zaledwie 26%-30% z nich zaimplementowało na szeroką skalę automatyzację testów.
Innymi słowy, proces testowania zazwyczaj pozostaje w niezmienionej formie, mimo że organizacje inwestują mnóstwo czasu i pracy w transformację swojego procesu wytwórczego, by sprostał dzisiejszym i przyszłym potrzebom biznesowym. Większość narzędzi i procesów związanych z testowaniem, będących spuścizną po okresie przed przekształceniem, nie jest w stanie spełnić wymagań ciągłego testowania narzucanych przez podejście DevOps z kilku powodów:
Niezdolność do przesunięcia testowania „w lewo” – testy zwykle są wykonywane na koniec cyklu, gdy zakończona jest implementacja interfejsu użytkownika; poza tym brak wcześniejszych automatycznych testów API.
Testy są czasochłonne, więc rzadko są wykonywane w całości. Oznacza to brak pełnej informacji o wpływie zmian na wszystkie obszary systemu i na sposób, w jaki użytkownicy dotychczas postrzegali system.
Wysokie nakłady na utrzymanie, bowiem testy UI często wymagają znacznych przeróbek, aby odzwierciedlać nieustanne zmiany ze względu na dynamiczny proces wytwarzania. Automatyzacja w takim przypadku jest wyjątkowo pracochłonna i nierzadko zostaje porzucona.
Niestabilność środowisk testowych (spowodowana problemami z danymi testowymi, niedostępnością innych systemów itp.) zwykle powoduje opóźnienia, niekompletną realizację testów, fałszywe alarmy lub przeoczenia błędów, czy nieadekwatne wyniki, co uniemożliwia szybkie dostarczenie informacji o jakości systemu, tak we współczesnych podejściach niezbędne.
Aby umożliwić ciągłe testowanie, poziom automatyzacji powinien sięgać, a nawet przekraczać 85% wszystkich testów. Aby to osiągnąć, niezbędnych jest kilka zmian w podejściu do kontroli jakości:
Ograniczenie do minimum testów manualnych i zarządzanie pozostałymi z nich w formie odpowiednio dokumentowanych sesji testów eksploracyjnych, które można wykorzystać do jeszcze dalej idącej automatyzacji.
Oparcie testów o ryzyko biznesowe, aby zoptymalizować ilość testów i wdrożyć zautomatyzowane punkty decyzyjne.
Przesunięcie testów do warstwy API, gdzie to tylko możliwe.
Zintegrowanie testów funkcjonalnych w procesie Continuous Delivery.
Odpowiednie zarządzanie danymi testowymi oraz wykorzystanie wirtualizacji serwisów, umożliwiające powtarzalne i częste przeprowadzanie testów end-to-end.[TestWarez 2017] Od testowania do monitoringu jakości – wyzwania Continuous ...
[TestWarez 2017] Od testowania do monitoringu jakości – wyzwania Continuous ...Stowarzyszenie Jakości Systemów Informatycznych (SJSI)
Mało kto zastanawia się, jak przebiega proces produkcji układów mikroelektronicznych z punktu widzenia zapewnienia jakości finalnego produktu. Coraz większe projekty wymuszają ciągły i bardzo dynamiczny rozwój dziedziny znanej jako DFT (design for testability), ale i narzędzi wspomagających cały proces testowy. W ramach prezentacji przedstawione zostaną podstawowe koncepty wykorzystywane przez największe firmy produkujące układy mikroelektroniczne, jak i problemy, z którymi należy się zmierzyć, by zapewnić wysoką jakość komercyjnego oprogramowania.
Specyfika oprogramowania tworzonego do testowania układów mikroelektoronicznych wykorzystywanych w urządzeniach powszechnego użytku różni się od klasycznych aplikacji desktopowych, jak i mobilnych. Bardzo duża dynamika rynku, zgodna z prawem Moore’a powoduje, że z roku na rok wymagania stawiane przed narzędziami wspomagającymi proces implementacji ciągle się zmienia. Wszystko to warunkuje sposób, w jaki należy podejść do testowania tego typu programów, jak rozwijać w pełni zautomatyzowaną infrastrukturę testową, pozwalającą zarządzać dziesiątkami tysięcy testów regresyjnych analizowanymi codziennie.[TestWarez 2017] Okiem testera – tam gdzie hardware łączy się z softwarem
[TestWarez 2017] Okiem testera – tam gdzie hardware łączy się z softwaremStowarzyszenie Jakości Systemów Informatycznych (SJSI)
W prezentacji przedstawię rozwiązanie frameworka do automatyzacji testów, które zaprojektowałem, aby zapewnić wydajną i tanią w utrzymaniu automatyzację testów dla aplikacji webowej.
Największym wyzwaniem było to, że aplikacja składała się z wielu modułów, z których każdy był tworzony, podobnie jak testy dla niego, przez inną firmę. Rozwiązanie oparte o repozytorium binariów pozwala na szybkie dzielenie się wytworzonym kodem testów aplikacji pomiędzy wszystkimi
zespołami, co przyspiesza i obniża koszt utrzymania testów automatycznych, oraz umożliwia szybkie pisanie testów przechodzących przez wiele modułów aplikacji.
[TestWarez 2017] Architektura testów automatycznych dla wielomodułowej aplika...
[TestWarez 2017] Architektura testów automatycznych dla wielomodułowej aplika...Stowarzyszenie Jakości Systemów Informatycznych (SJSI)
More Related Content
More from Stowarzyszenie Jakości Systemów Informatycznych (SJSI)
Analityk biznesowy analizuje biznes? W większości przypadków – nie. Projekty wypadają nam jak z czarnej skrzynki. Czy mają sens? Czasem trafiają jak kula w płot. Czasem są jak armata na muchę. Czasem nie rozwiązują właściwego, najbardziej naglącego problemu. A czasem decydent chce zabawkę lub awans, zapominając o klientach i rozwoju firmy. Czy to problem analityka? Czy Twój projekt jest właściwy dla firmy? Przyjrzyjmy się temu, co dzieje się ponad projektem - analizie prawdziwie biznesowej, analizie organizacji i analizie strategicznej. Rozwikłamy zagadkę - skąd biorą się sensowne projekty i dowiemy jak definiować potrzebne firmie inicjatywy.Analiza prawdziwie biznesowa - skąd biorą się projekty
Analiza prawdziwie biznesowa - skąd biorą się projektyStowarzyszenie Jakości Systemów Informatycznych (SJSI)
If Internet of Things is all about connectivity and cooperation then Industry 4.0 is based on data. In fact - lots of data! We are no longer talking about GigaBytes or TeraBytes but rather such abstract ideas and units like ExaBytes. And that's the main topic of this presentation - how huge is IoT, what is the value of switching from reactive to predictive company and why we use lambda architecture in the first place. And even if the concept of security, ethics, rules and regulations regarding data itself is also interesting on its own, this time we will focus directly on Industry 4.0 itself. Fast paced and intense presentation dedicated for Analysts and people loving and caring about IoT. Internet of Things loves data - analysis of Industry 4.0
Internet of Things loves data - analysis of Industry 4.0Stowarzyszenie Jakości Systemów Informatycznych (SJSI)
Biznes się zmienia. IT się zmienia. Ale czy narzędzia i metody pracy analityka i architekta zmieniają się lub powinny zmienić się - w szczególności w czasach coraz powszechniejszej robotyzacji procesów? W prezentacji będę starał się spojrzeć na relacje występujące między analitykiem-architektem a robotami z dwóch różnych perspektyw – tj. czy musimy inaczej niż do tej pory podejść do analizy i architektury zrobotyzowanego biznesu i jak roboty mogą pomóc w pracy analityka/architekta. Okazuje się bowiem, że coraz częściej wiele firm patrzy na analityków/architektów jako koszt (który może i przynosi korzyści, ale mocno odroczone w czasie) i zastanawia się, czy jest jakieś podejście umożliwiające podniesienie efektywności pracy tych ról.Analityk i architekt w czasach automatyzacji i robotyzacji biznesu
Analityk i architekt w czasach automatyzacji i robotyzacji biznesuStowarzyszenie Jakości Systemów Informatycznych (SJSI)
Każdy nowy pomysł, który chcemy zrealizować korzystając czy to z zasobów firmy czy też wsparcia inwestorów, musimy umieć skutecznie przedstawić. Najczęściej decydenci nie mają zbyt dużo czasu, aby zapoznać się ze wszystkimi szczegółami projektu. Jak ich przekonać w ciągu 5 minut? Co ich najbardziej zainteresuje? Jak powinna wyglądać skuteczna prezentacja? Im lepiej ją przygotujemy, tym większą mamy szansę na decyzję zgodną z naszymi oczekiwaniami. Zapraszam do wspólnego przyjrzenia się modelowi krótkiego, skutecznego przedstawiana pomysłów, który przydaje się w kontaktach z decydentami korporacji, z klientami czy z inwestorami.Jak sprzedać swój pomysł w 5 minut, czyli pitch deck dla BA
Jak sprzedać swój pomysł w 5 minut, czyli pitch deck dla BAStowarzyszenie Jakości Systemów Informatycznych (SJSI)
Każdy z nas słyszał termin „testowanie techniczne”. Wielu z nas mówi o sobie z dumą „tester techniczny”. Rynek potrzebuje „testerów technicznych”. Czy jednak wszyscy zgadzamy się w rozumieniu tych terminów? Kto i na jakiej podstawie powinien decydować co jest, a co nie testowaniem technicznym?
Prezentacja na pograniczu filozofii i technikaliów próbuje usystematyzować terminologię i zamieszać w głowach słuchaczy.[TestWarez 2017] Skomplikowane testowanie, skomplikowane terminy. Testowanie ...
[TestWarez 2017] Skomplikowane testowanie, skomplikowane terminy. Testowanie ...Stowarzyszenie Jakości Systemów Informatycznych (SJSI)
Przychodzi tester do lekarza…
Można by tak rozpocząć opis tej prelekcji. Nie o lekarza jednak tu będzie chodziło, a o rozmowy rekrutacyjne i to, co na nich można usłyszeć. Jestem członkiem grupy rekrutacyjnej w mojej firmie. Przeprowadziłem naprawdę sporo takich rozmów. Jedne bardziej udane, inne trochę mniej. Zauważyłem jednak jeden trend, który ostatnio coraz częściej zaczął się pojawiać na rozmowach - chęć do rozwoju w kierunku automatyzacji testów. Czy jednak wiecie z czym to się je?
Prelekcja skierowana jest do ludzi mniej doświadczonych, którzy po okresie okrzepnięcia w zawodzie dopiero zaczynają zastanawiać się nad swoją przyszłością, nad ścieżką swojej kariery. Jako lider spotkałem się też z osobami, które nie były świadome, w jakich kierunkach może rozwijać się tester. A możliwości jest naprawdę wiele. Tylko co wybrać?
Sam przeszedłem bardzo ciekawą drogę. Zdobyłem bardzo różnorodne doświadczenie, miałem przyjemność obserwować ludzi, ich rozwój, wybory, które czasem nie były trafne. Chciałbym się zatem podzielić z wami moim doświadczeniem liderskim, pokazać jak wygląda droga w kierunku managera, test leada, jakie wyzwania czekają na tej drodze.
Chciałbym także opowiedzieć o tym, jak zostać testerem, który automatyzuje; pokazać jak wygląda dzień z życia takiego testera, jakie wyzwania czekają nas po drodze i czego potrzebujesz droga koleżanko, drogi kolego, aby być w tej działce kimś ciekawym, na kogo rekruter zwróci uwagę.
Chciałbym również porozmawiać trochę o motywacji, która sprawia, że ludzie wybierają właśnie tę drogę.Czy to tylko podążanie za modą? Wszak nie wszyscy będziemy automatyzować.
Powiem także kilka słów o innych ścieżkach kariery testerskiej, może mniej oczywistych, ale z życia wziętych, z pracy w moim zespole.
Wystąpienie to skierowane jest do ludzi dopiero rozpoczynających swoją karierę, lecz być może, że coś ciekawego znajdzie dla siebie doświadczony wędrowiec.[TestWarez 2017] Przychodzi tester na rozmowę...
[TestWarez 2017] Przychodzi tester na rozmowę...Stowarzyszenie Jakości Systemów Informatycznych (SJSI)
Mikroserwisy to słowo, wokół którego cały świat IT kręcił się w ostatnich latach. Nowe podejście do architektury miało zapewnić szybkie oraz wygodne budowanie modularnych, niezawodnych, a przede wszystkim łatwo skalowalnych systemów. Wszystko wskazuje na to, że faktycznie się udało. Idea mikrousług, która jeszcze kilka lat temu brzmiała jak odświeżone SOA (które przecież absolutnie się nie przyjęło), dziś nie jest już niczym dziwnym i jest powszechnie stosowana w wielu organizacjach.
Faktycznie, mikroserwisy zrobione dobrze rozwiązują wiele problemów, które pojawiały się w przypadku monolitycznych systemów. Niestety zrobione źle, o co nietrudno, mogą przynieść więcej problemów niż korzyści. Mimo że mamy coraz więcej doświadczenia z tym podejściem do architektury, cały czas spotykamy się z nowymi wyzwaniami, dla których rozwiązania sprawdzające się przy monolitach okazują się niewystarczające, nie tylko w przypadku samego kodu czy designu, ale także w obszarze zapewniania jakości.
Sprawdzenie wydajności pojedynczej aplikacji nie jest proste. Sprawdzenie wydajności dwustu aplikacji, które działają razem, zależą od siebie i komunikują się ze sobą, jest po prostu bardzo trudne. W swojej prezentacji chciałbym opowiedzieć, jak podchodzimy do tego tematu w Ocado oraz przedstawić narzędzie do automatycznych testów wydajnościowych - Gatling.[TestWarez 2017] A proper gun makes testing fun
[TestWarez 2017] A proper gun makes testing funStowarzyszenie Jakości Systemów Informatycznych (SJSI)
Przy rosnącym skomplikowaniu aplikacji ilość testów „niezbędnych” do wykonania może zwiększać się w wykładniczym tempie. Jak nad tym zapanować, czy w ogóle jest to możliwe? Czy można zachować dobre pokrycie testowe zmniejszając ilość testów? Jak nie zgubić celu testowanej funkcjonalności czy nawet całej aplikacji?
Na bazie swoich doświadczeń chciałbym przedstawić odpowiedzi na te pytania oraz pokazać drogę jaką przeszły nasze testy od szczegółowych „Przypadków Testowych” do testów opierających się na „Klienckich Przypadkach Użycia” („Customer Use Case”).
Wystąpienie będzie miało na celu przedstawienie koncepcji optymalizacji testów bazującej na „Klienckich Przypadkach Użycia”, gdzie „Kliencki Przypadek Użycia” rozumiany jest jako informacja na temat wykorzystania danej funkcjonalności bądź aplikacji przez końcowego odbiorcę. Zaprezentowane zostaną korzyści z położenia nacisku na testowanie kluczowych elementów z punktu widzenia klienta. Słuchacze zapoznają się z przykładami zoptymalizowanych i niezoptymalizowanych testów. Scharakteryzowane zostaną wady i zalety takiego podejścia.[TestWarez 2017] „Przypadek Testowy” a „Kliencki Przypadek Użycia”
[TestWarez 2017] „Przypadek Testowy” a „Kliencki Przypadek Użycia”Stowarzyszenie Jakości Systemów Informatycznych (SJSI)
equirements. And projects sometimes forgot about nonfunctional requirements.
How Performance tester can help in such situation?
In my presentation I’m presenting techniques, which I’m using – when project needs performance testing, and comes to my team when no performance requirements are specified:
• How we can learn how many users will work with the system?
• How can we know – what response times users will accept?
• What if users are located around the globe?[TestWarez 2017] Requirements for Performance Testing
[TestWarez 2017] Requirements for Performance TestingStowarzyszenie Jakości Systemów Informatycznych (SJSI)
Continuous Delivery enables us to deliver software quickly and with high quality, ideally keeping our application production-ready with each code change, allowing us to ship that change right away. It is not a trivial process to introduce in a project or organization though. But can something as complicated as Continuous Delivery get even more complex?
'Shift left' approach to testing, risk analysis, consistent environments and build processes thanks to Chef, Vagrant and Jenkins Pipelines and a backlog that is possible to deliver in such methodology - these are only a few of elements that help us reach that goal.
When going from monolithic architecture of our application to microservices realm a myriad of new challenges are born. How complicated our build pipelines get and how can we easily orchestrate them? What if your application is not as modular as you would like it to be? What if your client is not quite ready for the dynamics that CD brings? And most importantly, how to maintain the same quality level with the above problems?
I would like to share my thoughts regarding these questions and on the future of DevOps in the quality-focused world.
To gain the most from the presentation, the audience should be familiar with:
microservices and monolithic architecture
continuous delivery
shift-left approach to testing
the general idea about tools for configuration management, service discovery[TestWarez 2017] Continuous Delivery and beyond
[TestWarez 2017] Continuous Delivery and beyondStowarzyszenie Jakości Systemów Informatycznych (SJSI)
Moje wystąpienie będzie studium przypadku. Opowiem w nim o wyzwaniu w projekcie, przed jakim stanęliśmy razem z zespołem. Problem był dość duży - w projekcie nie było automatycznych testów funkcjonalnych, a aplikacja mobilna ciągle rosła i przybywało nowych funkcjonalności. Dodatkowo klient nalegał na częstsze dostarczenia kolejnych wersji. Postaram się nakreślić architekturę aplikacji oraz wymagania, jakie postawione zostały przed frameworkiem do testów automatycznych. Opowiem o powodach stojących za podjętą decyzją o nieskorzystaniu z istniejących narzędzi/frameworków (np. Appium, Calabash) oraz o dokonanym wyborze - narzędziu XCUITest od Apple. W kolejnej części pokażę problemy, jakie napotkaliśmy implementując własny framework oparty o XCUITest - te dotyczące samego narzędzia, ale także i egzekucji testów oraz raportowania. Wskażę na jakich etapach prac na nie natrafiliśmy oraz czy (i jak) je rozwiązaliśmy. Na końcu przedstawię aktualny status - gdzie jesteśmy prawie 2 lata później. W podsumowaniu chciałbym wspomnieć o tym, co zadziałało w naszym podejściu, jakie decyzje były dobre, z czego – jako zespół - jesteśmy szczególnie dumni, co moglibyśmy polecić innym oraz co zostało jeszcze do zrobienia.[TestWarez 2017] Framework testowy aplikacji mobilnej dla systemu iOS - czy ...
[TestWarez 2017] Framework testowy aplikacji mobilnej dla systemu iOS - czy ...Stowarzyszenie Jakości Systemów Informatycznych (SJSI)
Podejścia zwinne oparte są o zmiany – metamorfozę w wytwarzaniu i zarządzaniu operacyjnym (ludzie, procesy i technologie), umożliwiającą dostarczanie innowacyjnego oprogramowania tak szybko, jak to możliwe. Pomimo tych wszystkich przekształceń, jeden element wydaje się niezachwiany. To proces testowania oprogramowania. Według różnych badań, 70%-88% organizacji przyjęło zwinne podejście do wytwarzania oprogramowania, podczas gdy zaledwie 26%-30% z nich zaimplementowało na szeroką skalę automatyzację testów.
Innymi słowy, proces testowania zazwyczaj pozostaje w niezmienionej formie, mimo że organizacje inwestują mnóstwo czasu i pracy w transformację swojego procesu wytwórczego, by sprostał dzisiejszym i przyszłym potrzebom biznesowym. Większość narzędzi i procesów związanych z testowaniem, będących spuścizną po okresie przed przekształceniem, nie jest w stanie spełnić wymagań ciągłego testowania narzucanych przez podejście DevOps z kilku powodów:
Niezdolność do przesunięcia testowania „w lewo” – testy zwykle są wykonywane na koniec cyklu, gdy zakończona jest implementacja interfejsu użytkownika; poza tym brak wcześniejszych automatycznych testów API.
Testy są czasochłonne, więc rzadko są wykonywane w całości. Oznacza to brak pełnej informacji o wpływie zmian na wszystkie obszary systemu i na sposób, w jaki użytkownicy dotychczas postrzegali system.
Wysokie nakłady na utrzymanie, bowiem testy UI często wymagają znacznych przeróbek, aby odzwierciedlać nieustanne zmiany ze względu na dynamiczny proces wytwarzania. Automatyzacja w takim przypadku jest wyjątkowo pracochłonna i nierzadko zostaje porzucona.
Niestabilność środowisk testowych (spowodowana problemami z danymi testowymi, niedostępnością innych systemów itp.) zwykle powoduje opóźnienia, niekompletną realizację testów, fałszywe alarmy lub przeoczenia błędów, czy nieadekwatne wyniki, co uniemożliwia szybkie dostarczenie informacji o jakości systemu, tak we współczesnych podejściach niezbędne.
Aby umożliwić ciągłe testowanie, poziom automatyzacji powinien sięgać, a nawet przekraczać 85% wszystkich testów. Aby to osiągnąć, niezbędnych jest kilka zmian w podejściu do kontroli jakości:
Ograniczenie do minimum testów manualnych i zarządzanie pozostałymi z nich w formie odpowiednio dokumentowanych sesji testów eksploracyjnych, które można wykorzystać do jeszcze dalej idącej automatyzacji.
Oparcie testów o ryzyko biznesowe, aby zoptymalizować ilość testów i wdrożyć zautomatyzowane punkty decyzyjne.
Przesunięcie testów do warstwy API, gdzie to tylko możliwe.
Zintegrowanie testów funkcjonalnych w procesie Continuous Delivery.
Odpowiednie zarządzanie danymi testowymi oraz wykorzystanie wirtualizacji serwisów, umożliwiające powtarzalne i częste przeprowadzanie testów end-to-end.[TestWarez 2017] Od testowania do monitoringu jakości – wyzwania Continuous ...
[TestWarez 2017] Od testowania do monitoringu jakości – wyzwania Continuous ...Stowarzyszenie Jakości Systemów Informatycznych (SJSI)
Mało kto zastanawia się, jak przebiega proces produkcji układów mikroelektronicznych z punktu widzenia zapewnienia jakości finalnego produktu. Coraz większe projekty wymuszają ciągły i bardzo dynamiczny rozwój dziedziny znanej jako DFT (design for testability), ale i narzędzi wspomagających cały proces testowy. W ramach prezentacji przedstawione zostaną podstawowe koncepty wykorzystywane przez największe firmy produkujące układy mikroelektroniczne, jak i problemy, z którymi należy się zmierzyć, by zapewnić wysoką jakość komercyjnego oprogramowania.
Specyfika oprogramowania tworzonego do testowania układów mikroelektoronicznych wykorzystywanych w urządzeniach powszechnego użytku różni się od klasycznych aplikacji desktopowych, jak i mobilnych. Bardzo duża dynamika rynku, zgodna z prawem Moore’a powoduje, że z roku na rok wymagania stawiane przed narzędziami wspomagającymi proces implementacji ciągle się zmienia. Wszystko to warunkuje sposób, w jaki należy podejść do testowania tego typu programów, jak rozwijać w pełni zautomatyzowaną infrastrukturę testową, pozwalającą zarządzać dziesiątkami tysięcy testów regresyjnych analizowanymi codziennie.[TestWarez 2017] Okiem testera – tam gdzie hardware łączy się z softwarem
[TestWarez 2017] Okiem testera – tam gdzie hardware łączy się z softwaremStowarzyszenie Jakości Systemów Informatycznych (SJSI)
W prezentacji przedstawię rozwiązanie frameworka do automatyzacji testów, które zaprojektowałem, aby zapewnić wydajną i tanią w utrzymaniu automatyzację testów dla aplikacji webowej.
Największym wyzwaniem było to, że aplikacja składała się z wielu modułów, z których każdy był tworzony, podobnie jak testy dla niego, przez inną firmę. Rozwiązanie oparte o repozytorium binariów pozwala na szybkie dzielenie się wytworzonym kodem testów aplikacji pomiędzy wszystkimi
zespołami, co przyspiesza i obniża koszt utrzymania testów automatycznych, oraz umożliwia szybkie pisanie testów przechodzących przez wiele modułów aplikacji.
[TestWarez 2017] Architektura testów automatycznych dla wielomodułowej aplika...
[TestWarez 2017] Architektura testów automatycznych dla wielomodułowej aplika...Stowarzyszenie Jakości Systemów Informatycznych (SJSI)
More from Stowarzyszenie Jakości Systemów Informatycznych (SJSI) (20)
Analiza prawdziwie biznesowa - skąd biorą się projekty
Analiza prawdziwie biznesowa - skąd biorą się projekty
Internet of Things loves data - analysis of Industry 4.0
Internet of Things loves data - analysis of Industry 4.0
Analityk i architekt w czasach automatyzacji i robotyzacji biznesu
Analityk i architekt w czasach automatyzacji i robotyzacji biznesu
Jak sprzedać swój pomysł w 5 minut, czyli pitch deck dla BA
Jak sprzedać swój pomysł w 5 minut, czyli pitch deck dla BA
[TestWarez 2017] Skomplikowane testowanie, skomplikowane terminy. Testowanie ...
[TestWarez 2017] Skomplikowane testowanie, skomplikowane terminy. Testowanie ...
[TestWarez 2017] „Przypadek Testowy” a „Kliencki Przypadek Użycia”
[TestWarez 2017] „Przypadek Testowy” a „Kliencki Przypadek Użycia”
[TestWarez 2017] Requirements for Performance Testing
[TestWarez 2017] Requirements for Performance Testing
[TestWarez 2017] Framework testowy aplikacji mobilnej dla systemu iOS - czy ...
[TestWarez 2017] Framework testowy aplikacji mobilnej dla systemu iOS - czy ...
[TestWarez 2017] Od testowania do monitoringu jakości – wyzwania Continuous ...
[TestWarez 2017] Od testowania do monitoringu jakości – wyzwania Continuous ...
[TestWarez 2017] Okiem testera – tam gdzie hardware łączy się z softwarem
[TestWarez 2017] Okiem testera – tam gdzie hardware łączy się z softwarem
[TestWarez 2017] Architektura testów automatycznych dla wielomodułowej aplika...
[TestWarez 2017] Architektura testów automatycznych dla wielomodułowej aplika...
[TestWarez 2017] Mutacyjne testowanie oprogramowania w aspekcie Test Driven Development
- 1. TDD vs. TDD+M Test Driven Development kontra Test Driven Development + Mutacje Michał Mnich & Piotr Wawrzyniak 16-17.11.2017
- 2. PLAN PREZENTACJI 1. T.D.D. - Test Driven Development, definicje. 2. T.D.D. - Test Driven Development, wady i zalety. 3. T.D.D. - Test Driven Development + Mutacje, definicje, zalety oraz wady. 4. T.D.D. + M - Eksperyment testujący metodykę. 5. T.D.D. + M - Eksperyment Wyniki. 6. T.D.D. + M - Eksperyment omówienie wyników. 7. Podsumowanie. 8. Pytania.
- 3. T.D.D. - Test Driven Development
- 4. T.D.D. - Diagram Weryfikacji Poprawności Kod Testy Testy testów???
- 5. T.D.D. - Test Driven Development
- 6. T.D.D. - Test Driven Development + Mutacje Run Mutations
- 7. T.D.D. + M Eksperyment ● Jeden projekt. ● Jeden Java Doc. ● Dwa zespoły. ● Jeden zespół pracuje w technice TDD. ● Drugi zespół pracuje w technice TDD+M. ● Na koniec naprzemienne testy weryfikacyjne*. *(Kod zespołu w samym TDD poddajemy mutacji następnie sprawdzamy jak radzą sobie ich testy. Przenosimy testy na krzyż z TDD do TDD+M i sprawdzamy czy przechodzą. Sami piszemy testy i sprawdzamy czy nasze będą lepsze).
- 8. T.D.D. + M Eksperyment Wyniki TDD Reales CodeCoverage % MutationCoverage % Tests Mutants Methods Info 1 0 0 0 4 6 Puste metody 2 79,31034483 39,13043478 2 23 8 3 79,48717949 82,69230769 5 52 10 4 79,48717949 82,69230769 5 52 10 Poprawki w projekcie nie w kodzie 5 89,74358974 82,69230769 7 52 10 Agregacja żywych mutantów od wersji 3 6 66,66666667 63,23529412 8 68 16 Nowa niedokończona klasa brak testów stara bez zmian 7 41,86046512 41,34615385 8 104 16 Klasa Matrix bez zmian, Math bez testów nowe implementacje metod 8 60,46511628 64,42307692 11 104 16 Nowy test testMatrixSubtracting ubijamy dodatkowe 2 mutanty w Matrix. 2 nowe testy w math ubijają 22 mutanty CROS TEESTY z TDDM 86,76470588 75,96153846 16 104 16 W matrix zabija 48 mutantów o 3 więcej w math zabija 31 o 9 więcej mamy 1 test na metodę. Wymagane było komentowanie 2 testów które nie przechodziły wcale więcej info w doc.
- 9. T.D.D. + M Eksperyment Wyniki TDDM Reales CodeCoverage MutationCoverage Tests Mutants Methods Info 1 43,90243902 30,3030303 3 33 16 Matrix zaimplementowana częściowo math wcale 2 36,11111111 34,32835821 4 134 16 Math zaimplementowana ale bez testów matrix pokrycie wzrosło o 35% Pokrycie mutantów o 41% 3 39,81481481 38,05970149 6 134 16 Math bez testów rośnie pokrycie Matrix 4 39,81481481 39,55223881 6 134 16 Matrix 1 mutant ubity (poprawiony test) Math bez zmian 5 39,81481481 38,80597015 6 134 16 Matrix 1 mutant ubity (poprawiony test dążą do 100% w klasie matrix) Math bez zmian 6 47,22222222 44,02985075 7 134 16 Klasa matrix nowy test pokryta testami 96% mutanty ubite 100%. Jedyna niepokryta metoda robi set na ( data[row][column] = value) komurce w tablicy double Math brak testow nadal 7 49,07407407 44,02985075 8 134 16 Klasa matrix pokrycie 100% Mutacyjne 100% nowy test dla tego seta doubla. Klasa Math nie ruszona 8 93,51851852 87,31343284 12 134 16 Implementacja testów dla Math 4 nowe testy 9 81,4516129 73,58490566 12 134 16 Implementacja 2 metod w math matrixSubtracting, matrixTransposition brak nowych testów brak testów do nowych nowych mutantów Koniec projektu z względów na Deadline dlatego spadł scro nie pełny cykl w trakcie Development.
- 10. T.D.D. + M Eksperyment Wyniki TDDM Reales CodeCoverage % MutationCoverage % Test s Mutants Methods Info CROSS TESTY z TDD 39,51612903 40,25157233 12 134 16 Score dużo gorszy Testy Piotra W. 90,32258065 82,38993711 18 134 16 Wniosek nawet doświadczony programista nie był w stanie zrobić 100%
- 11. T.D.D. + M Wnioski 1. Łatwość popełniania błędów numerycznych a. Mutacje są dobrym narzędziem do weryfikacji poprawności numerycznej algorytmu. b. Nawet najbardziej doświadczony programista popełnia błędy c. Pisanie testów jednostkowych dla numeryki jest trudne i mało efektywne
- 12. T.D.D. + M Wnioski 1. Narzędzie do testowania dokumentacji. 2. Narzędzie do testowania spójności idei. 3. Wychwytywanie słabości projektowych. 4. Testowanie przepływów algorytmów.
- 13. T.D.D. + M Wnioski 1. Ubijanie mutantów dla samego ubijanie mutantów jest złe: Uczestnicy eksperymentu jako słabo doświadczeni programiści mieli tendencję do ubijanie mutantów nie patrząc czy dany mutant jest sensowny. Czasem dawało to odwrotny efekt od zamierzonego czasem naprawiano test tak żeby przechodził mimo że błąd nie był w teście a w kodzie.
- 14. T.D.D. + M Wnioski 2. Code review powinno analizować mutacje pod względem kodu programu jak i kodu testu.
- 15. T.D.D. + M Wnioski 3. Same mutacje są wstępem do review.
- 16. Q&A Q&A