[TestWarez 2017] Co z tą asercją?
•
0 likes•351 views
W swojej pracy zawodowej spotkałam się z różnymi podejściami do asercji - część osób tworzących automaty upiera się, że zgodnie ze starą szkołą unit testów powinno się mieć jedną asercję na test, na poziomie samego testu. Z drugiej strony jednak w przypadku, gdy mamy zautomatyzować dużą aplikację, gdzie nie możemy pozwolić sobie na przerwanie kodu po pierwszej asercji, musimy umieścić ich więcej. Równocześnie bardzo dużo osób ma też problemy z wyszczególnieniem co dokładnie powinno być sprawdzane w czasie testu i jak ważne jest to dla jego wyniku. W czasie swojej prezentacji przedstawię na przykładach z automatyzacji testów dużych aplikacji webowych, jak najlepiej według mnie potraktować asercje. Dodatkowo powiem o tym jak powinien wyglądać kod, aby był prosty do utrzymania i aby osoba posługująca się nim była w stanie w łatwy sposób używać go z wykorzystaniem fluent interfaces. W bardziej szczegółowy sposób zajmę się zagadnieniami takimi jak: Czym jest asercja? W tym punkcie przedstawię definicję asercji oraz opowiem o głównych założeniach z nią związanych. Różnica pomiędzy asercją w testach unitowych a funkcjonalnych Istnieje różnica pomiędzy sprawdzaniem poprawności kodu składającego się z kilku/kilkunastu linii, a kodu, który składa się na daną funkcjonalność w systemie (chociażby najprostsze rzeczy typu logowanie do systemu) – czy w takim razie w obu przypadkach powinniśmy tak samo stosować asercję? Czym są fluent interfaces? W powyższym punkcie przedstawię definicję i założenia fluent interfaces oraz przedstawię ich wykorzystanie w testach automatycznych. Podkreślę również zysk, jaki mamy z ich wykorzystania – głównie w trakcie pisania kodu i jego wykorzystywania. Jak to czasem wygląda? W swojej codziennej pracy spotykam się z różnymi wykorzystaniami asercji w testach. Nie zawsze są to podejścia sensowne – zaprezentuję parę przykładów, które pokażą, jak w łatwy sposób utrudnić sobie zarządzanie kodem i wprowadzanie do niego zmian tylko dzięki temu, że asercje mamy widoczne na poziomie testu. Jak to może wyglądać? Jak w poprzednim punkcie na przykładach pokażę wypracowane przez siebie podejście do asercji oraz opowiem, jak ułatwiło mi ono pracę z kodem. Czy wszystko powinno kończyć się failem? Czy na pewno powinniśmy przerwać wykonywanie kodu przy najmniejszym błędzie będącym nawet literówką w wyświetlonym komunikacie na stronie? Czy powinniśmy sprawdzać każdy najdrobniejszy szczegół czy tylko najważniejsze elementy? Na koniec postaram się odpowiedzieć na zadane powyżej pytania.
Report
Share
Report
Share
Download to read offline
Recommended
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)
More Related Content
More from Stowarzyszenie Jakości Systemów Informatycznych (SJSI)
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)
More from Stowarzyszenie Jakości Systemów Informatycznych (SJSI) (20)
Dancing with the devil - how to cooperate with a problematic customer
Dancing with the devil - how to cooperate with a problematic customer
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] Co z tą asercją?
- 1. CO Z TĄ ASERCJĄ? Agnieszka Kościuczyk
- 2. ABOUT ME TESTOWANIE AUTOMATYZACJA KREATYWNOŚĆ GÓRY PLANSZÓWKI
- 3. Asercja = ? 100 kcal snack
- 4. Co możemy sprawdzać? C z y w i d z i m y o c z e k i w a n y o b i e k t ? C z y d a n y c h e c k b o x j e s t z a z n a c z o n y c z y n i e ? C z y a l e r t z a w i e r a p o p r a w n y t e k s t ? i t d . . .
- 5. UNIT TESTY
- 6. END TO END TESTY
- 7. Tell Don't Ask vs Single Responsibility Principle
- 8. Demo
- 9. Dobre praktyki D R Y Z a s a d a p o j e d y ń c z e j o d p o w i e d z i a l n o ś c i S a m o d o k u m e n t u j ą c y s i ę k o d T e l l D o n ' t A s k
- 10. Questions?