Wystąpienie złożone będzie z 3 zasadniczych części. W części pierwszej omówię kilka mechanizmów psychologicznych o niezwykle silnych implikacjach praktycznych dla pracy testerów. Pokażę z jakich zasad psychologicznych (!) wynika efektywność formalnych technik projektowania testów. Postaram się również uzasadnić empirycznie, dlaczego tak ważne jest porozumiewanie się z klientem w języku biznesu. Zobaczymy również dlaczego jedną z kluczowych cech testera musi być kreatywność, nieszablonowe myślenie i znajomość… logiki!
ATUAÇÃO FONOAUDIOLOGIA NA ÁREA DA AUDIOLOGIA VOLTADA A SAÚDE DO TRABALHADORUnoeste
As condições de saúde auditiva no ambiente de trabalho tem sido objeto de muitos estudos no campo da saúde pública, uma vez que, a exposição a elevados níveis de ruído pode provocar danos irreversíveis à audição como a Perda Auditiva Induzida por Níveis de Pressão Sonora Elevado (PAINPS).
Prezentacja ukazuje od podstaw procesy związane z testowaniem bezpieczeństwa aplikacji webowych, z uwzględnieniem najpopularniejszych narzędzi, metodyk, zasobów wiedzy oraz standardów weryfikacji bezpieczeństwa. Na bazie ponad 10 letniego doświadczenia w przełamywaniu zabezpieczeń, zostaną przedstawione dobre praktyki i najczęściej popełniane błędy związane z wykonywaniem testów bezpieczeństwa. Zostanie omówiona m.in. lista kontrolna standardu Application Security Verification Standard wspomagająca proces tworzenia oprogramowania już na etapie definiowania wymogów formalnych oraz dodatkowa przydatna dokumentacja projektu Open Web Application Security Project (OWASP).
To explore strange new worlds, to seek out new life and new civilisations, to boldly go where no man has gone before.” Just like the crew of the USS Enterprise, we explore the IT universe – seeking out new solutions, new technologies, and frameworks – from which we can learn to help us work better and more efficiently. We do this to create more functional and usable software for our customers, to put a big smile on their faces, and maybe – if we do our job really well – to make them stand back and admire what we have crafted. I was lucky enough to work in BDD (Behaviour Driven Development) quite early in his career, but I also had the misfortune to see how this great idea so often tends to fail. In my presentation I wanted to show what it is like working with BDD and what value can it give to business people. Finally I would like to propose an effective, alternative solution for well-known BDD tools, which is „Spock” – a convenient, lightweight framework, based on the Groovy language.
ATUAÇÃO FONOAUDIOLOGIA NA ÁREA DA AUDIOLOGIA VOLTADA A SAÚDE DO TRABALHADORUnoeste
As condições de saúde auditiva no ambiente de trabalho tem sido objeto de muitos estudos no campo da saúde pública, uma vez que, a exposição a elevados níveis de ruído pode provocar danos irreversíveis à audição como a Perda Auditiva Induzida por Níveis de Pressão Sonora Elevado (PAINPS).
Prezentacja ukazuje od podstaw procesy związane z testowaniem bezpieczeństwa aplikacji webowych, z uwzględnieniem najpopularniejszych narzędzi, metodyk, zasobów wiedzy oraz standardów weryfikacji bezpieczeństwa. Na bazie ponad 10 letniego doświadczenia w przełamywaniu zabezpieczeń, zostaną przedstawione dobre praktyki i najczęściej popełniane błędy związane z wykonywaniem testów bezpieczeństwa. Zostanie omówiona m.in. lista kontrolna standardu Application Security Verification Standard wspomagająca proces tworzenia oprogramowania już na etapie definiowania wymogów formalnych oraz dodatkowa przydatna dokumentacja projektu Open Web Application Security Project (OWASP).
To explore strange new worlds, to seek out new life and new civilisations, to boldly go where no man has gone before.” Just like the crew of the USS Enterprise, we explore the IT universe – seeking out new solutions, new technologies, and frameworks – from which we can learn to help us work better and more efficiently. We do this to create more functional and usable software for our customers, to put a big smile on their faces, and maybe – if we do our job really well – to make them stand back and admire what we have crafted. I was lucky enough to work in BDD (Behaviour Driven Development) quite early in his career, but I also had the misfortune to see how this great idea so often tends to fail. In my presentation I wanted to show what it is like working with BDD and what value can it give to business people. Finally I would like to propose an effective, alternative solution for well-known BDD tools, which is „Spock” – a convenient, lightweight framework, based on the Groovy language.
Model-based testing is an increasingly popular trend in the world of quality assurance. The aim of such an approach is to focus on a working system model and automatically generate test cases. However, how can it become useful in the work of a business or system analyst? The essence is in the model. It is called an executable specification. In this approach, it can take the form of code, gherkin syntax or UML graphs and diagrams. The latter is something that analysts use every day. In my presentation, I would therefore like to show how model-based testing can be used in the work of analysts. And how this approach can improve the work of the project team.
Did you know, that 65% of our average workday is COMMUNICATION with our colleagues? Communication is really essential in our daily life. It can make or break a project we are working on! Bad communication makes us not only lose valuable time, but money and resources as well. Let’s have a look at the style different people use to communicate, and on the different approaches we can use to make our communication more effective, and stop wasting time in meetings, that we never needed to have if we communicated properly. I will teach you the best tips and tricks to succeed in communication with your colleagues and partners to make your project great again!
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ść.
Wiele lat temu podczas rozmowy rekrutacyjnej prezes jednej firmy powiedział do mnie: błędy popełniane na etapie analizy są najdroższe dla firmy. Wtedy była to dla mnie teoria, którą rozumiałam, ale za dużo na sobie nie doświadczyłam albo też nie potrafiłam ocenić skali czy wczuć się w powagę tych słów ☺ Każdy projekt, w którym brałam udział, każde doświadczenie dokładał kolejny kawałek do pewności co robię dobrze, a co źle, przyczyniał się do zmniejszenia ryzyka popełnienia błędu. Zazwyczaj uczymy się na własnych błędach, ale wiemy też, że najtaniej uczyć się na cudzych. Tylko nie zawsze to działa ☺ Zapraszam do edycji drugiej mojego wystąpienia „Błędy w analizie, co robić, i czy da się ich uniknąć” ☺ Opowiem o kilku kolejnych typowych potknięciach, które się zdarzają każdemu i o tym, jakie ja mam sposoby na przeciwdziałanie pojawieniu się podobnych kolejnych.
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.
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.
Although there are few absolute truths in software development, I have discovered several requirements principles that apply almost universally to software projects. These principles emphasize the critical contribution that excellent requirements make to a project's success, and the critical contribution that customer involvement makes to excellent requirements. You'll hear several suggestions for practices that can help any team build a more effective customer-developer partnership. These cosmic truths can help your organization produce and manage accurate, consistent, and unambiguous sets of requirements.
Zagraj w zaangażowanie czyli jak dzięki grywalizacji angażować zespół projektowy. Graczy nie trzeba dodatkowo motywować do tego by chcieli osiągać kolejne poziomy w grze – dlaczego więc nie wykorzystać mechanizmów z gier do angażowania naszych zespołów projektowych by ułatwić im osiąganie celów? Możesz to zrobić dzięki grywalizacji, która w Polsce staje się coraz bardziej popularna. Fabuła, punkty, ranking, odznaki – to tylko niektóre ze stosowanych mechanizmów, które z codziennych zadań pracowników tworzą ich zawodową przygodę. Jak wpleść je w pracę naszego zespołu projektowego? Podczas wykładu nie tylko dowiecie się więcej o grywalizacji, ale będziecie mieli okazję sami zbudować koncepcję gry. Jakiej? Przyjdź i przekonaj się.
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.
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.
Accessibility is a legal requirement in almost every country in the world. WCAG 2.1, Section 508 of the Rehabilitation Act, Equality Act 2010 these are examples how serious accessibility is. Accessibility means the ability of everyone regardless of their condition to have access to digital product, transport, physical products. The web and internets in whole is an increasingly resource in many aspect of our life, so it is important that the digital product be accessible to everyone in order to provide equal access and opportunity. Accessible is easy & low-cost if you as BA think about it on the early stage
The spread of Agile raises demanding challenges. If you’re a BA who’s faced with the situation when your organization is undergoing “agile” transformation, you might be looking for information about what this transformation means. There are some misconceptions about agile adoption and even more hype. The lecture introduces my personal experience of reaching organization’s Agile maturity from a Business Analyst perspective.
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.
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.
Despite years of efforts to improve the professional approach to developing software systems, many of these projects continue to fail. Investigations into these failures invariably denote poor interactions between humans, both within development teams and with customers and users, as a key factor. Recent evolution in development approaches, like human-centered design and extreme programming, try to address this problem, but until now, an overall view was missing. In this presentation we integrate these initiatives into a simple model, that arranges six key skills along two axes (customer–team and problem–solution) around communication as a core. Many techniques are available to implement these skills in development teams, so failure will no longer be the usual outcome.
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.
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.
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.
Dobry system musi być przetestowany pod względem wydajnościowym. Takie testy są zupełnie inne niż testy funkcjonalne: zamiast binarnego rezultatu (pass, fail), mamy ogromne ilości danych do zebrania, zaprezentowania i zinterpretowania. Podczas wystąpienie prelegent omówi cały cykl testów wydajnościowych: od przygotowania warunków testu, środowisk i danych testowych, poprzez przeprowadzenie testów, zebranie danych, ich prezentację i interpretacje, aż po przeprowadzenie procesów decyzyjnych wynikających z danych.
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.
More Related Content
More from Stowarzyszenie Jakości Systemów Informatycznych (SJSI)
Model-based testing is an increasingly popular trend in the world of quality assurance. The aim of such an approach is to focus on a working system model and automatically generate test cases. However, how can it become useful in the work of a business or system analyst? The essence is in the model. It is called an executable specification. In this approach, it can take the form of code, gherkin syntax or UML graphs and diagrams. The latter is something that analysts use every day. In my presentation, I would therefore like to show how model-based testing can be used in the work of analysts. And how this approach can improve the work of the project team.
Did you know, that 65% of our average workday is COMMUNICATION with our colleagues? Communication is really essential in our daily life. It can make or break a project we are working on! Bad communication makes us not only lose valuable time, but money and resources as well. Let’s have a look at the style different people use to communicate, and on the different approaches we can use to make our communication more effective, and stop wasting time in meetings, that we never needed to have if we communicated properly. I will teach you the best tips and tricks to succeed in communication with your colleagues and partners to make your project great again!
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ść.
Wiele lat temu podczas rozmowy rekrutacyjnej prezes jednej firmy powiedział do mnie: błędy popełniane na etapie analizy są najdroższe dla firmy. Wtedy była to dla mnie teoria, którą rozumiałam, ale za dużo na sobie nie doświadczyłam albo też nie potrafiłam ocenić skali czy wczuć się w powagę tych słów ☺ Każdy projekt, w którym brałam udział, każde doświadczenie dokładał kolejny kawałek do pewności co robię dobrze, a co źle, przyczyniał się do zmniejszenia ryzyka popełnienia błędu. Zazwyczaj uczymy się na własnych błędach, ale wiemy też, że najtaniej uczyć się na cudzych. Tylko nie zawsze to działa ☺ Zapraszam do edycji drugiej mojego wystąpienia „Błędy w analizie, co robić, i czy da się ich uniknąć” ☺ Opowiem o kilku kolejnych typowych potknięciach, które się zdarzają każdemu i o tym, jakie ja mam sposoby na przeciwdziałanie pojawieniu się podobnych kolejnych.
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.
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.
Although there are few absolute truths in software development, I have discovered several requirements principles that apply almost universally to software projects. These principles emphasize the critical contribution that excellent requirements make to a project's success, and the critical contribution that customer involvement makes to excellent requirements. You'll hear several suggestions for practices that can help any team build a more effective customer-developer partnership. These cosmic truths can help your organization produce and manage accurate, consistent, and unambiguous sets of requirements.
Zagraj w zaangażowanie czyli jak dzięki grywalizacji angażować zespół projektowy. Graczy nie trzeba dodatkowo motywować do tego by chcieli osiągać kolejne poziomy w grze – dlaczego więc nie wykorzystać mechanizmów z gier do angażowania naszych zespołów projektowych by ułatwić im osiąganie celów? Możesz to zrobić dzięki grywalizacji, która w Polsce staje się coraz bardziej popularna. Fabuła, punkty, ranking, odznaki – to tylko niektóre ze stosowanych mechanizmów, które z codziennych zadań pracowników tworzą ich zawodową przygodę. Jak wpleść je w pracę naszego zespołu projektowego? Podczas wykładu nie tylko dowiecie się więcej o grywalizacji, ale będziecie mieli okazję sami zbudować koncepcję gry. Jakiej? Przyjdź i przekonaj się.
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.
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.
Accessibility is a legal requirement in almost every country in the world. WCAG 2.1, Section 508 of the Rehabilitation Act, Equality Act 2010 these are examples how serious accessibility is. Accessibility means the ability of everyone regardless of their condition to have access to digital product, transport, physical products. The web and internets in whole is an increasingly resource in many aspect of our life, so it is important that the digital product be accessible to everyone in order to provide equal access and opportunity. Accessible is easy & low-cost if you as BA think about it on the early stage
The spread of Agile raises demanding challenges. If you’re a BA who’s faced with the situation when your organization is undergoing “agile” transformation, you might be looking for information about what this transformation means. There are some misconceptions about agile adoption and even more hype. The lecture introduces my personal experience of reaching organization’s Agile maturity from a Business Analyst perspective.
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.
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.
Despite years of efforts to improve the professional approach to developing software systems, many of these projects continue to fail. Investigations into these failures invariably denote poor interactions between humans, both within development teams and with customers and users, as a key factor. Recent evolution in development approaches, like human-centered design and extreme programming, try to address this problem, but until now, an overall view was missing. In this presentation we integrate these initiatives into a simple model, that arranges six key skills along two axes (customer–team and problem–solution) around communication as a core. Many techniques are available to implement these skills in development teams, so failure will no longer be the usual outcome.
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.
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.
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.
Dobry system musi być przetestowany pod względem wydajnościowym. Takie testy są zupełnie inne niż testy funkcjonalne: zamiast binarnego rezultatu (pass, fail), mamy ogromne ilości danych do zebrania, zaprezentowania i zinterpretowania. Podczas wystąpienie prelegent omówi cały cykl testów wydajnościowych: od przygotowania warunków testu, środowisk i danych testowych, poprzez przeprowadzenie testów, zebranie danych, ich prezentację i interpretacje, aż po przeprowadzenie procesów decyzyjnych wynikających z danych.
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.
More from Stowarzyszenie Jakości Systemów Informatycznych (SJSI) (20)
[TestWarez 2017] „Przypadek Testowy” a „Kliencki Przypadek Użycia”
Testy dwóch róż – czyli Lancasterowie i Yorkowie poznają psychologię testowania
1. Wojna dwóch róż, czyli
Lancasterowie i Yorkowie stosują
psychologię w testowaniu
Adam Roman
Instytut Informatyki i Matematyki Komputerowej UJ
TestWarez 2015
2. 1. Mechanizmy
psychologiczne
Efektywne testy
podstawa dla
2. Praktyczny
problem testowy
pozwalają dobrze
przetestować
3. Model
Techniki
białoskrzynkowe
pokrywają
Podejście
analityczne
generuje
testy
wykorzystuje
wpływają na
PLAN PREZENTACJI
8. MECHANIZMY PSYCHOLOGICZNE
EFEKT POTWIERDZENIA (EKSPERYMENT WASONA)
Odgadnij regułę, według której akceptowane są trójki liczb
Trójka (2, 4, 6) spełnia regułę (jest akceptowana)
Dla każdej podanej przez Ciebie trójki otrzymasz odpowiedź,
czy spełnia ona regułę
10. MECHANIZMY PSYCHOLOGICZNE
EFEKT POTWIERDZENIA (EKSPERYMENT WASONA)
Reguła brzmi: „dowolna sekwencja rosnąca”. W eksperymencie
przeprowadzonym przez Wasona badani mieli duże trudności
z jej odgadnięciem, często zakładając bardziej skomplikowane
reguły
Badani przeprowadzali testy jedynie, aby
potwierdzić swoje przypuszczenia
Krytyczny racjonalizm: hipoteza naukowa musi być
przetestowana przez próbę falsyfikacji
Ludzie próbują raczej potwierdzać niż zaprzeczać
Klayman & Ha: ludzie nie tyle mają tendencję do potwierdzania, co
do przeprowadzania testów zgodnych z założoną opinią
11. MECHANIZMY PSYCHOLOGICZNE
EFEKT POTWIERDZENIA (EKSPERYMENT WASONA)
test negatywny, niepewne potwierdzenieT H
H T
TH
test negatywny, zdecydowana falsyfikacja
test pozytywny, niepewne potwierdzenie
test negatywny, niepewne potwierdzenie
test negatywny, zdecydowana falsyfikacja
test pozytywny, niepewne potwierdzenie
test pozytywny, zdecydowana falsyfikacja
test negatywny, niepewne potwierdzenie
test pozytywny, zdecydowana falsyfikacja
test pozytywny, niepewne potwierdzenie
12. MECHANIZMY PSYCHOLOGICZNE
EFEKT POTWIERDZENIA (EKSPERYMENT WASONA)
Klayman & Ha – potwierdzenie ich hipotezy:
Trójki liczb klasyfikowane jako „DAX” i „MED”, zamiast
informacji „zgodna z regułą”, „niezgodna z regułą”
Pozwoliło to uniknąć sugerowania, że celem jest znalezienie
jakiejś specyficznej reguły
W tej wersji badani uzyskiwali znacznie lepsze rezultaty
Należy testować swoje hipotezy tak, aby
uzyskać jak najwięcej informacji
to właśnie leży u podstaw formalnych technik projektowania testów!
13. CEL TESTOWANIA
Wykazać, że testowany
program nie zawiera
błędów
Wykazać, że testowany
program zawiera
mnóstwo błędów
Podświadome dążenie
do przekonania, że tak
rzeczywiście jestKonstrukcja złych
(słabych) przypadków
testowych
Brak objawów błędów
Większe przekonanie,
że w programie nie ma
błędów
Dobrze
skonstruowane,
przemyślane testy
Większe
prawdopodobieństwo
wykrycia błędu!
MECHANIZMY PSYCHOLOGICZNE
IMPLIKACJE EFEKTU POTWIERDZENIA W TESTOWANIU
14. MECHANIZMY PSYCHOLOGICZNE
TEST SELEKCJI WASONA
Przygotowanie do eksperymentu
Podział słuchaczy na dwie równe grupy
Grupa pierwsza za chwilę zobaczy zadanie na slajdzie. Będzie miała
minutę na rozwiązanie zadania. Rozwiązanie należy zapisać na
kartce lub zapamiętać
Grupa druga proszona jest o to, aby przez chwilę nie patrzeć na
ekran
16. MECHANIZMY PSYCHOLOGICZNE
TEST SELEKCJI WASONA
Na stole leżą 4 karty, zgodnie z rysunkiem. Każda karta ma liczbę
po jednej i kolor po drugiej stronie. Na widocznych stronach kart
widnieją: 3, 8, kolor czerwony, kolor niebieski. Którą/które z nich należy
koniecznie odwrócić, aby sprawdzić, czy prawdziwe jest twierdzenie:
jeśli karta zawiera parzystą liczbę z jednej strony, to jej druga strona
jest czerwona
8
18. MECHANIZMY PSYCHOLOGICZNE
TEST SELEKCJI WASONA
Na stole leżą 4 karty, zgodnie z rysunkiem. Każda ma wiek osoby po
jednej i pity przez nią napój po drugiej stronie (piwo lub wodę). Na
widocznych stronach kart widnieją: 16, 25, piwo, woda. Którą/które
należy koniecznie odwrócić, aby sprawdzić, czy prawdziwe
jest twierdzenie:
jeśli ktoś pije alkohol, to ma co najmniej 18 lat
25
19. MECHANIZMY PSYCHOLOGICZNE
TEST SELEKCJI WASONA
Prawidłowa odpowiedź:
Grupa 1
karty: 8 i niebieska
Grupa 2
karty: 16 i piwo
implikacja A → B jest nieprawdziwa tylko, gdy A jest prawdziwe
a B nieprawdziwe; więc tylko dla karty z parzystą liczbą z jednej
strony i kolorem niebieskim z drugiej
Policzmy poprawne odpowiedzi w obu grupach.W której jest więcej?
(egz. z testowania, 102 studentów – pytanie w wersji dla Grupy 1
– 58% błędnych odpowiedzi)
8
25
20. MECHANIZMY PSYCHOLOGICZNE
TEST SELEKCJI WASONA – IMPLIKACJE DLA TESTOWANIA
Ludzie rozwiązują test łatwiej, gdy przedstawi się go w postaci
problemu dotyczącego stosunków społecznych lub dotyczących
tego, czy z jakichś przywilejów korzystają wyłącznie ci, którzy
są do tego uprawnieni
Ten sam test używający pojęć abstrakcyjnych wypada gorzej!
WNIOSKI
1. Logika jest ważna!
2. Używać języka odbiorcy!
x=1; i=0;
while (!(x==1) || i>=0) {
…
}
21. Gwidon jest najlepszym testerem wśród programistów i
jednocześnie najlepszym programistą wśród testerów. Wtedy :
A) Zbiór testerów nie może pokrywać się ze zbiorem programistów.
B) Gwidon może być jednocześnie najgorszym programistą i
najgorszym testerem.
C) Gwidon musi być najlepszym testerem lub najlepszym
programistą.
D) Jeśli jakiś tester jest jednocześnie programistą, może być
lepszym testerem od Gwidona.
E) Część wspólna zbioru testerów i programistów musi być
niepusta.
• 102 studentów, 40% odpowiedzi niepoprawnych!
MECHANIZMY PSYCHOLOGICZNE
LOGIKA (!) PYTANIE EGZAMINACYJNE NA EGZAMINIE Z TESTOWANIA, Inst. Inf. UJ
22. PROBLEM SUKCESJI
SPECYFIKACJA PROBLEMU
Wojna dwóch róż – problem sukcesji tronu
Zasada sukcesji: primogenitura w linii męskiej
Reguły:
• najstarszy syn monarchy i jego zstępni mają pierwszeństwo
przed jego rodzeństwem i ich zstępnymi
• starszy syn ma pierwszeństwo przed młodszym, ale synowie
mają pierwszeństwo przed córkami
• dzieci reprezentują zmarłych przodków i starsza linia
pochodzenia ma zawsze pierwszeństwo nad młodszą, w ramach
każdej z płci
WEJŚCIE: drzewo genealogiczne z zaznaczonym zmarłym
monarchą
WYJŚCIE: następca tronu
23. PROBLEM SUKCESJI
PRZYKŁAD – CZY ROZUMIEMY ZASADY? REGUŁY LOGICZNE!
kolejność dzieci = starszeństwo
potomek
martwy
potomek
24. PROBLEM SUKCESJI
PRZYKŁAD – CZY ROZUMIEMY ZASADY? REGUŁY LOGICZNE!
kolejność dzieci = starszeństwo
potomek
martwy
potomek
25. PROBLEM SUKCESJI
JAK METODYCZNIE WYPROWADZIĆ EFEKTYWNE TESTY?
Opisywać testy językiem biznesowym (biznes = królestwo,
dziedziczenie, potomkowie, tron itp.)
Pamiętać o efekcie potwierdzenia! Każdy test ma sprawdzić
możliwie odmienną od dotychczas przetestowanych części
programu.
Wykorzystać formalne techniki projektowania testów (dobrze
zrealizują efekt potwierdzenia)
Out of the box thinking – wartościowe dopełnienie technik.
28. PROBLEM SUKCESJI
PODEJŚCIE ANALITYCZNE – WYŁAPANIE WSZYSTKICH KLUCZOWYCH TERMINÓW
Wojna dwóch róż – problem sukcesji tronu
Zasada sukcesji: primogenitura w linii męskiej
Reguły:
• najstarszy syn monarchy i jego zstępni mają pierwszeństwo
przed jego rodzeństwem i ich zstępnymi
• starszy syn ma pierwszeństwo przed młodszym, ale synowie
mają pierwszeństwo przed córkami
• dzieci reprezentują zmarłych przodków i starsza linia
pochodzenia ma zawsze pierwszeństwo nad młodszą, w ramach
każdej z płci
WEJŚCIE: drzewo genealogiczne z zaznaczonym zmarłym
monarchą
WYJŚCIE: następca tronu
29. PROBLEM SUKCESJI
PODEJŚCIE ANALITYCZNE – WYŁAPANIE WSZYSTKICH KLUCZOWYCH TERMINÓW
Wojna dwóch róż – problem sukcesji tronu
Zasada sukcesji: primogenitura w linii męskiej
Reguły:
• najstarszy syn monarchy i jego zstępni mają pierwszeństwo
przed jego rodzeństwem i ich zstępnymi
• starszy syn ma pierwszeństwo przed młodszym, ale synowie
mają pierwszeństwo przed córkami
• dzieci reprezentują zmarłych przodków i starsza linia
pochodzenia ma zawsze pierwszeństwo nad młodszą, w ramach
każdej z płci
WEJŚCIE: drzewo genealogiczne z zaznaczonym zmarłym
monarchą
WYJŚCIE: następca tronu
kolejność dzieci
30. PROBLEM SUKCESJI
PODEJŚCIE ANALITYCZNE – WYŁAPANIE WSZYSTKICH KLUCZOWYCH TERMINÓW
Wojna dwóch róż – problem sukcesji tronu
Zasada sukcesji: primogenitura w linii męskiej
Reguły:
• najstarszy syn monarchy i jego zstępni mają pierwszeństwo
przed jego rodzeństwem i ich zstępnymi
• starszy syn ma pierwszeństwo przed młodszym, ale synowie
mają pierwszeństwo przed córkami
• dzieci reprezentują zmarłych przodków i starsza linia
pochodzenia ma zawsze pierwszeństwo nad młodszą, w ramach
każdej z płci
WEJŚCIE: drzewo genealogiczne z zaznaczonym zmarłym
monarchą
WYJŚCIE: następca tronu
kolejność dzieci
liczba dzieci
31. PROBLEM SUKCESJI
PODEJŚCIE ANALITYCZNE – WYŁAPANIE WSZYSTKICH KLUCZOWYCH TERMINÓW
Wojna dwóch róż – problem sukcesji tronu
Zasada sukcesji: primogenitura w linii męskiej
Reguły:
• najstarszy syn monarchy i jego zstępni mają pierwszeństwo
przed jego rodzeństwem i ich zstępnymi
• starszy syn ma pierwszeństwo przed młodszym, ale synowie
mają pierwszeństwo przed córkami
• dzieci reprezentują zmarłych przodków i starsza linia
pochodzenia ma zawsze pierwszeństwo nad młodszą, w ramach
każdej z płci
WEJŚCIE: drzewo genealogiczne z zaznaczonym zmarłym
monarchą
WYJŚCIE: następca tronu
kolejność dzieci
liczba dzieci
liczba zstępnych
32. PROBLEM SUKCESJI
PODEJŚCIE ANALITYCZNE – WYŁAPANIE WSZYSTKICH KLUCZOWYCH TERMINÓW
Wojna dwóch róż – problem sukcesji tronu
Zasada sukcesji: primogenitura w linii męskiej
Reguły:
• najstarszy syn monarchy i jego zstępni mają pierwszeństwo
przed jego rodzeństwem i ich zstępnymi
• starszy syn ma pierwszeństwo przed młodszym, ale synowie
mają pierwszeństwo przed córkami
• dzieci reprezentują zmarłych przodków i starsza linia
pochodzenia ma zawsze pierwszeństwo nad młodszą, w ramach
każdej z płci
WEJŚCIE: drzewo genealogiczne z zaznaczonym zmarłym
monarchą
WYJŚCIE: następca tronu
kolejność dzieci
liczba dzieci
liczba zstępnych
płeć
33. PROBLEM SUKCESJI
PODEJŚCIE ANALITYCZNE – WYŁAPANIE WSZYSTKICH KLUCZOWYCH TERMINÓW
Wojna dwóch róż – problem sukcesji tronu
Zasada sukcesji: primogenitura w linii męskiej
Reguły:
• najstarszy syn monarchy i jego zstępni mają pierwszeństwo
przed jego rodzeństwem i ich zstępnymi
• starszy syn ma pierwszeństwo przed młodszym, ale synowie
mają pierwszeństwo przed córkami
• dzieci reprezentują zmarłych przodków i starsza linia
pochodzenia ma zawsze pierwszeństwo nad młodszą, w ramach
każdej z płci
WEJŚCIE: drzewo genealogiczne z zaznaczonym zmarłym
monarchą
WYJŚCIE: następca tronu
kolejność dzieci
liczba dzieci
liczba zstępnych
płeć
żywy/martwy
34. PROBLEM SUKCESJI
PODEJŚCIE ANALITYCZNE – CATEGORY-PARTITION
Kategoria Podział
Typ osoby Monarcha, potomek, przodek, rodzeństwo
Liczba dzieci 0, 1, więcej niż 1
Kolejność S > S, S > C, C > C, C > S
Liczba zstępnych 0, 1, więcej niż 1
Płeć Syn, córka
Aktywność Żywy, martwy
Idea: wykorzystać kombinacje powyższych do konstruowania testów
Np.: monarcha ma więcej niż 1 potomka
potomkowie to syn, córka i syn
najstarszym potomkiem jest syn, potem córka, potem drugi syn
najstarszy syn ma 0 zstępnych, drugi syn jest martwy
córka ma 1 zstępnego i jest to syn
35. PROBLEM SUKCESJI
PODEJŚCIE ANALITYCZNE – CATEGORY-PARTITION
Kategoria Podział
Typ osoby Monarcha, potomek, przodek, rodzeństwo
Liczba dzieci 0, 1, więcej niż 1
Kolejność S > S, S > C, C > C, C > S
Liczba zstępnych 0, 1, więcej niż 1
Płeć Syn, córka
Aktywność Żywy, martwy
Idea: wykorzystać kombinacje powyższych do konstruowania testów
Np.: monarcha ma więcej niż 1 potomka
potomkowie to syn, córka i syn
najstarszym potomkiem jest syn, potem córka, potem drugi syn
najstarszy syn ma 0 zstępnych, drugi syn jest martwy
córka ma 1 zstępnego i jest to syn
SYSTEMATYCZNE
TWORZENIE KOMBINACJI
DOBRZE POKRYJE
ALGORYTM (efekt
potwierdzenia!)
38. PROBLEM SUKCESJI
THINKING OUT OF THE BOX
Uwzględnienie błędnych danych wejściowych!
(BTW, X może być pogrobowcem, wtedy chyba jest OK?)
X
39. PROBLEM SUKCESJI
THINKING OUT OF THE BOX
Przypadek typu „Gra o tron” – wszyscy potomkowie martwi ;-)
(BTW: w takim przypadku chyba istotna jest informacja o
rodzeństwie króla – pytanie, jak „szerokie” ma być otoczenie
króla w drzewie, nie tylko jego potomków, ale i wstępnych
oraz rodzeństwa!)
40. TESTOWANIE OPARTE O MODEL
PODEJŚCIE WYKORZYSTUJĄCE TABLICE DECYZYJNE
1 2 3 4 5 6 7 8 9
WARUNKI
ma NS? T T N N N N N N N
NS żyje? T N - - - - - - -
ma NC? - - T T N N N N N
NC żyje? - - T N - - - - -
ma NB? - - - - T T N N N
NB żyje ? - - - - T N - - -
ma NSi? - - - - - - T T N
NSi żyje? - - - - - - T N -
AKCJE
następca NNS - NNC - NNB - NNSi - -
oznaczyć jako
analizowany?
- T - T - T - T T
kto do dalszej analizy? - NNS - NNC - NNB - NNsi przodek
NS/NC/NB/NSi = nieanalizowany syn/córka/brat/siostra
41. załóżmy, że drzewo podawane w formie tekstowej:
nazwisko data ur. ojciec
Edward III 1312 -
Edward 1330 Edward III
Ryszard II 1367 Edward
Jan z Gandawy 1340 Edward III
Henryk IV 1366 Jan z Gandawy
Edmund z York 1341 Edward III
Ryszard 1375 Edmund z York
Jakie dodatkowe rzeczy można przetestować?
np.: poprawność dat, dwoje synów o tej samej dacie urodzenia,
dziecko o dacie urodzenia wcześniejszej niż ojciec, poprawność nazwisk
(puste pola, znaki specjalne, zbyt długie nazwy), błędna struktura pliku…
TESTOWANIE API
WPŁYW POSTACI DANYCH WEJŚCIOWYCH NA MOŻLIWOŚCI TESTOWE
Edward III
Edward
Jan
z Gandawy
Edmund
z York
Ryszard II Henryk IV Ryszard
42. • mechanizmy psychologiczne mają wpływ na testowanie
– efekt potwierdzenia (skuteczność technik proj. testów)
– test selekcji (logika; rola języka w komunikacji)
– thinking out of the box (kreatywność wspomagająca formalne
techniki projektowania testów)
• podejście analityczne (w tym oparte na modelu) pozwala
na systematyczne i dokładne przetestowanie nawet
złożonych systemów oraz skomplikowanych reguł
biznesowych
• u źródeł podejścia analitycznego leży m.in. psychologia!
PODSUMOWANIE
WNIOSKI