Miękkie umiejętności w pracy analityka biznesu
•Download as PPTX, PDF•
0 likes•252 views
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ść.
Report
Share
Report
Share
Recommended
Star Trek: BDD Enterprise
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 as a BA tool
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.
Communication - Language of Leader
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!
Błędy w analizie z praktyki (nowe wydanie )
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.
7 Skills for highly effective teams - workshop
7 Skills for highly effective teams - workshopStowarzyszenie 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.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)
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.Cosmic truths about software requirements
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
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ę.
Recommended
Star Trek: BDD Enterprise
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 as a BA tool
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.
Communication - Language of Leader
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!
Błędy w analizie z praktyki (nowe wydanie )
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.
7 Skills for highly effective teams - workshop
7 Skills for highly effective teams - workshopStowarzyszenie 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.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)
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.Cosmic truths about software requirements
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
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ę.
Analiza prawdziwie biznesowa - skąd biorą się projekty
Analiza prawdziwie biznesowa - skąd biorą się projektyStowarzyszenie 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.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)
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. Start with Accessibility: Why, How and What
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
Agile business analyst
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.
Analityk i architekt w czasach automatyzacji i robotyzacji biznesu
Analityk i architekt w czasach automatyzacji i robotyzacji biznesuStowarzyszenie 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.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 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.7 Skills for highly effective teams
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.
[TestWarez 2017] Skomplikowane testowanie, skomplikowane terminy. Testowanie ...
[TestWarez 2017] Skomplikowane testowanie, skomplikowane terminy. Testowanie ...Stowarzyszenie 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] Przychodzi tester na rozmowę...
[TestWarez 2017] Przychodzi tester na rozmowę...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] A proper gun makes testing fun
[TestWarez 2017] A proper gun makes testing funStowarzyszenie 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] Zen testów wydajnościowych
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.
[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)
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] Requirements for Performance Testing
[TestWarez 2017] Requirements for Performance TestingStowarzyszenie 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] Continuous Delivery and beyond
[TestWarez 2017] Continuous Delivery and beyondStowarzyszenie 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] 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)
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] 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)
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] 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)
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] 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)
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] Jakoś(ć) w pracy testera
Podczas panelu będziemy dyskutować o problemie (nie)świadomego zamykania się testerów na jakość. O tym jak i czy w ogóle dbamy o jakość oprogramowania poza testowaniem. O tym, co ma wpływ na jakość w projekcie i jak tester może przyczynić się do jej zapewnienia. Spróbujemy zaadresować problem, zbadać go oraz zastanowić się, jak możemy go rozwiązać.
Agenda:
1. Opis problemu oraz jego objawy.
2. Jaki wpływ ma ten problem na nas?
3. Kto powinien dbać o jakość?
4. Jak budować świadomość QA w zespole?
[TestWarez 2017] Adaptability – the stories
Reorganization of test teams working on complex, high scale systems using KANBAN and empowerment of individuals for the magic of testing. We invite you to listen to two stories about introducing self-organization and improving transparency in test teams, based on our experiences with Motorola Solutions as Test Managers. We will talk about the magic these changes brought the testers, the leaders and the organization. And also we will describe why the KANBAN (instead of Scrum) have been chosen to organize the work. We will show the benefits, difficulties and failures that decision had brought along the way and how to proactively build on that.
More Related Content
More from Stowarzyszenie Jakości Systemów Informatycznych (SJSI)
Analiza prawdziwie biznesowa - skąd biorą się projekty
Analiza prawdziwie biznesowa - skąd biorą się projektyStowarzyszenie 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.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)
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. Start with Accessibility: Why, How and What
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
Agile business analyst
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.
Analityk i architekt w czasach automatyzacji i robotyzacji biznesu
Analityk i architekt w czasach automatyzacji i robotyzacji biznesuStowarzyszenie 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.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 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.7 Skills for highly effective teams
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.
[TestWarez 2017] Skomplikowane testowanie, skomplikowane terminy. Testowanie ...
[TestWarez 2017] Skomplikowane testowanie, skomplikowane terminy. Testowanie ...Stowarzyszenie 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] Przychodzi tester na rozmowę...
[TestWarez 2017] Przychodzi tester na rozmowę...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] A proper gun makes testing fun
[TestWarez 2017] A proper gun makes testing funStowarzyszenie 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] Zen testów wydajnościowych
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.
[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)
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] Requirements for Performance Testing
[TestWarez 2017] Requirements for Performance TestingStowarzyszenie 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] Continuous Delivery and beyond
[TestWarez 2017] Continuous Delivery and beyondStowarzyszenie 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] 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)
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] 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)
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] 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)
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] 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)
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] Jakoś(ć) w pracy testera
Podczas panelu będziemy dyskutować o problemie (nie)świadomego zamykania się testerów na jakość. O tym jak i czy w ogóle dbamy o jakość oprogramowania poza testowaniem. O tym, co ma wpływ na jakość w projekcie i jak tester może przyczynić się do jej zapewnienia. Spróbujemy zaadresować problem, zbadać go oraz zastanowić się, jak możemy go rozwiązać.
Agenda:
1. Opis problemu oraz jego objawy.
2. Jaki wpływ ma ten problem na nas?
3. Kto powinien dbać o jakość?
4. Jak budować świadomość QA w zespole?
[TestWarez 2017] Adaptability – the stories
Reorganization of test teams working on complex, high scale systems using KANBAN and empowerment of individuals for the magic of testing. We invite you to listen to two stories about introducing self-organization and improving transparency in test teams, based on our experiences with Motorola Solutions as Test Managers. We will talk about the magic these changes brought the testers, the leaders and the organization. And also we will describe why the KANBAN (instead of Scrum) have been chosen to organize the work. We will show the benefits, difficulties and failures that decision had brought along the way and how to proactively build on that.
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...
Miękkie umiejętności w pracy analityka biznesu
- 1. Miękkie Umiejętności w Pracy Analityka Biznesowego Tomasz Furgalski
- 2. Elementy przekazu w bezpośredniej interakcji 7% 38% 55% mowa ciała siła wysokość rytm słowa brzmienie
- 4. Dobre wrażenia to emocje Kluczem - bezwiedna ewaluacja emocjonalna Trzeba odwoływać się do procesów bezwiednych poprzez: Mowę ciała Emisję głosu Treść wypowiedzi
- 5. Jak utworzyć relację? Rozpoznanie potrzeby Zaspokojenie rozpoznanej potrzeby Dostrojenie się fizycznie do jego tempa do jego gestykulacji do nastroju Dostrojenie mentalne do klienta wartości światopogląd przekonania postawy i styl życia
- 6. Samorealizacja Szacunek Przynależność i potrzeby społeczne Bezpieczeństwo i ochrona Potrzeby fizjologiczne