Agenda
Become someone who makes things happen
It is frustrating when you have an idea about how something could be improved, but you can't persuade your team or stakeholders to change.
Katrina is an established test professional, but early in her career she found it difficult to implement change in established development practices. In this interactive workshop Katrina will share the techniques that she learned to improve communication with colleagues, better explain her ideas, and become confident talking about change to stakeholders. Katrina will demonstrate how to structure a persuasive argument and share a self-assessment tool to help you practice communicating effectively.
Interesujesz się serverlessem, ale masz dość prostych przykładów pokazujących jedynie podstawy pojedynczych usług? Dzięki tym warsztatom poznacie pełnię możliwości, którą daje integracja kilku popularnych usług AWS. Na podstawie rzeczywistego przypadku będziecie przeprowadzeni przez proces tworzenia aplikacji opartych na serverless: od projektowania, przez pisanie kodu, wdrożenie i testowanie, po monitoring działającej aplikacji. Dowiecie się, w jaki sposób połączyć usługi takie jak S3, Lambda, SNS i SQS w jedną aplikację, praktycznie gotową do produkcyjnego zastosowania.
Kluczowe elementy szkolenia:
- przedstawienie koncepcji serverless na podstawie rzeczywistego przypadku biznesowego;
- realizacja pomysłu za pomocą podejścia serverless i usług z chmury AWS;
- powtarzalny deployment z użyciem Infrastracture as a Code;
- rozwiązanie problemu biznesowego od A do Z – infrastruktura, kod i wdrożenie.
Podczas warsztatów będziecie budować aplikacje w oparciu o język TypeScript. Jego znajomość nie będzie wymaganiem, ale na pewno ułatwi pracę!
Warsztaty kierowane są do:- programistów,
- architektów.
„Każdy projekt jest inny” – to mantra, którą usłyszeć możemy wielokrotnie od różnych osób. Nie oznacza to jednak, że nie możemy uczyć się na błędach i wyciągniętych z nich wnioskach. Nie trzeba każdorazowo zaczynać „od zera”. Wyrobienie sobie odpowiedniego frameworku do pracy z projektem w zakresie analizy biznesowej pozwala wszystkim zainteresowanym stronom mieć jasność, co należy zrobić, jakie są kolejne zadania do wykonania i kto powinien je wykonać. Warsztaty prowadzone będą na podstawie doświadczeń z prawdziwego projektu, na które Natalia zaprasza analityków biznesowych i osoby, które zadania analizy biznesowej łączą z innymi rolami w projekcie.
Warsztaty będą podzielone na 3 części: teoria, praktyka, i automatyka. W części teoretycznej nakreślimy tło poprzez omówienie standardów takich jak OWASP Top 10, ASVS, czy SAMM. W części praktycznej zobaczycie, jak można wykorzystywać różne narzędzia do znajdywania podatności z listy OWASP Top 10. W części automatycznej dowiecie się, jak można automatyzować prace omówione w części praktycznej.
Jako uczestnicy warsztatów zakończycie je z podstawowym zrozumieniem podatności z listy OWASP Top 10 oraz umiejętnością ich wyszukiwania w swoich aplikacjach.
W dzisiejszych czasach prawie wszystkie aspekty dostarczania oprogramowania ujmujemy jako kod: infrastrukturę, konfigurację jej oraz aplikacji, testy oraz specyfikację. Tego samego możemy dokonać dla naszego procesu dostarczania (delivery pipeline), bardzo istotnego elementu w podejściach typu Continuous Development/Deployment. Jako kod możemy zapisać wszystko, co dzieję się od chwili, w której programiści wypchną swoje zmiany do repozytorium, aż do momentu, kiedy trafia on do naszego użytkownika końcowego.
Podczas warsztatu dla przykładowej aplikacji zaprojektujemy oraz zaimplementujemy wszystkie etapy jej dostarczania:
- nauczymy się jak ją budować
- uruchomimy potrzebne testy
- wydamy jej nową wersję
- wdrożymy aplikację na środowisko ‘produkcyjne’
Użyjemy do tego celu Dockera, Jenkinsa i Jenkins Pipelines.
To ćwiczenie pozwoli Ci na zrozumienie całego procesu dostarczania oprogramowania z bardziej technicznego punktu widzenia co umożliwi Ci wgląd na podobne aspekty związane z Twoją aplikacją, którą budujesz w swoim projekcie/zespole. Dodatkowo, nauczysz się jak stworzyć lokalne środowisko do eksperymentowania z CI/CD na własną rękę.
Podstawowa znajomość pojęć związanych z Dockerem będzie pomocna, ale wszystkie potrzebne informacje zostaną przedstawione w trakcie warsztatu.Pisanie testów jednostkowych jest kluczową umiejętnością w pracy z kodem. Podczas warsztatów TDD nie tylko oswaja się czerwone testy, ale przede wszystkim buduje dobre nawyki. Niemałym wyzwaniem może być praca w parach i pair programming. Wszystkie te umiejętności wykorzystywane są w codziennej pracy w projekcie. TDD jest techniką powszechnie stosowaną w programowaniu. Chociaż nie używa się jej zawsze i wszędzie, warto poznać to narzędzie.
Z warsztatów skorzystają głównie programiści Javy, którzy chcą spróbować pisać testy przed kodem, a także testerzy, którzy znają podstawy Javy. Warsztaty będą miały bardzo przyjemną formę i dotychczas są dobrze odbierane przez ich uczestników.
Umiejętność poruszania się w złożonej rzeczywistości i uwzględniania wielu różnych zmiennych czynników jest obecnie potrzebna bardziej niż kiedykolwiek wcześniej. Świat „kurczy się” drastycznie, jest coraz bardziej dynamiczny, a zdolność dostrzeżenia tzw. „Big Picture” staje się nieoceniona. Coraz częściej mierzymy się ze złożonością organizacji, w których pracujemy, a których dotykają efekty naszej pracy w postaci tworzonych przez nas produktów.
Daniel postara się podczas warsztatów przedstawić koncepcję stojącą u podstaw Lean, Agile Manifesto czy skalowanych podejść do tworzenia produktów – LeSS i SAFe (nikogo nie dyskryminuje!). Postawicie na minimum teorii i maksimum praktyki, tak byście otrzymali narzędzie, którego można używać w swojej codziennej pracy.
„Systems Thinking” może przydać się każdemu, kogo interesuje odpowiedź na pytanie „dlaczego” – od testerów, po analityków, a na scrum masterach i managerach kończąc. Część zadaje pytanie, inni mają na nie odpowiedź – a myślenie systemowe pozwala te światy połączyć.W czasie warsztatów będziecie zgłębiać tajniki automatyzacji aplikacji mobilnych przeznaczonych na platformę Android. Wraz z Jakubem, Piotrem i Dagmarą będziecie mogli nauczyć się, jak od zera stworzyć testy whitebox. Dodatkowo zapoznacie się ze wzorcem projektowym PageObject, dzięki któremu możliwe będzie zwiększenie wytrzymałości testów i dodanie do nich nowej, biznesowej warstwy abstrakcji.
Codziennością testera technicznego w większości projektów są testy UI. Mimo że często stanowią podstawę automatyzacji w projekcie, trzeba wiedzieć, że nie wszystko da się nimi przetestować. Zdarza się, że system/aplikacja, którą testujemy, może składać się z samego backendu. Może zdarzyć się też, że jest bardzo dużo funkcji, które musimy — lub możemy — przetestować jedynie za pomocą testów API. Tutaj z pomocą przychodzi nam REST-Assured — biblioteka, która pozwala wykonywać testy za pomocą protokołu HTTP.
W czasie warsztatów dowiecie się, czym jest API, REST i SOAP oraz jak wysyłać za jego pomocą zapytania. Nauczycie się, jak prawidłowo pisać testy zgodnie ze sztuką, jak od zera zbudować prosty framework testowy i w jaki sposób go rozwijać. Wszystko to w połączeniu z Kotlinem, który jest nowoczesnym, coraz częściej spotykanym językiem w wielu projektach. Co ciekawe, wszystko, co napiszecie, będzie testowane na specjalnie przygotowanej na te okoliczności apce."
Dług techniczny bywa mierzony narzędziami do statycznej analizy struktury kodu źródłowego. Tego typu analiza może dać dobrą odpowiedź na pytanie o aktualny stan jakości kodu, jednak pozostawia bez odpowiedzi inne, równie ważne: czy warto spłacać ten dług? A jeśli tak, to gdzie? A jeśli wszędzie, to gdzie najpierw? Podczas prezentacji Grzegorz zaprezentuje kilka technik, zaczerpniętych z dokonań Adama Tornhilla, które ułatwią, przy użyciu danych z systemów kontroli wersji, odpowiedź na pytania: gdzie mam bądź zaczynam mieć problemy z jakością kodu? Czy wiedza w zespole wystarczy do poradzenia sobie z długiem technicznym? Czy architektura mojego systemu ułatwia, czy utrudnia jego przyszłą ewolucję?
Podejście serverless i związane z nim technologie towarzyszą branży już od jakiegoś czasu. Dostawcy usług chmurowych wciąż udostępniają nowe rozwiązania oparte o tę filozofię. Wiele z nich przyjęło już w pełni dojrzałą formę. Z drugiej strony serverless pojawia się często jako modne hasło, które przez wiele osób interpretowane jest w różny sposób. W prezentacji Wojtek podzieli się swoim doświadczeniem w tej dziedzinie. Jest ono poparte budowaniem i utrzymywaniem usług, które działają produkcyjnie od ponad 3 lat. Opowie również o drodze, jaką przeszły aplikacje jego zespołu — od (wydawałoby się) dobrego projektu architektury, przez twardą jej weryfikację w rzeczywistym środowisku produkcyjnym, po wyciągnięte wnioski i ewolucję. Na podstawie tych doświadczeń podzieli się również przemyśleniami na temat odpowiednich i nietrafionych przypadków użycia architektury serverless.
Zastanawialiście się kiedyś, dlaczego zmiany nie wychodzą? Dlaczego po spotkaniu, na którym zdefiniowaliście akcje i po którym jesteście zmotywowani do działania, nic się nie dzieje? Albo dzieje się tylko przez chwilę? Dlaczego mimo dobrych pomysłów, entuzjazmu i motywacji tak trudno jest wprowadzić zmianę i zbudować dobry nawyk. A potem i tak często okazuje się, że w pierwszym trudniejszym momencie wszystko wraca na stare tory. Mózg szuka znanych ścieżek, nie lubi zmian, lubi za to automatyzację działania i znane, utarte schematy.W czasie prelekcji Dorota opowie Wam, jak zidentyfikować nawyki, które Was blokują i jak wykorzystać wiedzę o nich i pracy mózgu tak, by nie przeszkadzały, a pomagały we wprowadzaniu zmian. Poznacie odpowiedzi na pytania, jak krok po kroku pracować nad zespołowymi nawykami, aby wspierały one efektywną pracę i jakość dostarczanych rozwiązań i jak wprowadzać nowe rutyny tak, aby mózg przyjmował je bez większego oporu. Zwinne wytwarzanie oprogramowania wiąże się z usprawnieniami, ciągłą zmianą i szukaniem optymalnych rozwiązań — dotyczy to praktyk indywidualnych, zespołowych, jak i organizacyjnych. W systemie złożonym, jakim jest organizacja, wszystko jest ze sobą powiązane. Na przykładach Dorota przedstawi, jak świadomie podchodzić do budowania dobrych nawyków.
Mikroserwisy stały się już standardem nowoczesnej architektury oprogramowania. Nadal jednak często testowanie nie nadąża za nowym podejściem. W swojej prezentacji postaram się opowiedzieć czym tak naprawdę różni się testowanie architektury rozproszonej od monolitycznej, czy testy kontraktów to recepta na wszystko oraz w jaki sposób można rozwiązać problem alternatywnie wykorzystując zaimplementowaną już wcześniej hordę testów regresyjnych.
Mindsets and behaviours for a team and personal quality
Michał's talk is going to cover two important concepts of mindset and behaviour. Michal will talk about their meaning, importance, and their impact on teams and individuals. First, he will introduce his understanding of those. Next, he will shift the focus to quality and present what quality-related situations and behaviours we face in our teams or how to react in such situations. After such an introduction, Michał will focus on career and personal life quality and show their importance in this matter. Does it sound a bit... fuzzy? He will dive into the nitty-gritty and instruct you on how to behave if someone says your quality or your process is shit. How to break the wall of resistance to change? How to make sure you are not siding with the resistance? Michał will surely seek answers to these questions (and more) in the presentation.
Czym są testy korytarzowe? W jaki sposób mogą one zostać wykorzystane do poprawienia użyteczności naszego produktu? Co zyskamy, włączając testy korytarzowe do naszej strategii testowania? W przedstawionej prezentacji Ewa podzieli się z Wami sposobami na wykorzystanie „przypadkowych testerów” do poprawy jakości naszego oprogramowania, skupiając się na definicji testów korytarzowych oraz kto-jak-co-kiedy, czyli:
- kogo zaangażować w przeprowadzenie testów korytarzowych,
- w jaki sposób przeprowadzać takie testy,
- w jakich projektach testy korytarzowe sprawdzają się najlepiej,
- na którym etapie najlepiej wprowadzić testy korytarzowe,
- dobre praktyki testów korytarzowych,
- czego unikać podczas przeprowadzania testów korytarzowych.
W firmach z wieloma różnymi projektami problemem może być zapewnienie w nich jakości na podobnym poziomie – praktyki, jakie stosowane są w projekcie, często zależą od ludzi i ich doświadczeń. W wyniku takich różnic często powtarzane są te same błędy w różnych projektach, mimo że inny zespół już sobie z nimi poradził. Nadia i Adam postanowili zaradzić temu problemowi, tworząc zbiór dobrych praktyk, typowych problemów oraz ich rozwiązań i obudowali je procesem, który nazwali „Quality Kickoff”. Quality Kickoff startuje wraz z początkiem projektu. Biorąc pod uwagę potrzeby projektowe, kontekst i wymagania, cały zespół wybiera odpowiednie praktyki jakościowe, a następnie odrzuca te, które są nadmiarowe. Cały proces jest iteracyjny – postęp prac sprawdza się na regularnych spotkaniach Quality Check. Omawiane są też na nich aktualne i nowe problemy oraz pomysły na kolejne usprawnienia. Quality Kickoff jest rodzajem retrospektywy poświęconej aspektom jakościowym – w kontekście developmentu, testowania, jak i zarządzania projektem. Sprawia, że temat zapewniania jakości staje się codziennością i integralną częścią procesu dla każdego członka zespołu. Dzięki bazie dobrych praktyk, potencjalnych problemów oraz zaangażowaniu testerów z doświadczeniem w różnorodnych projektach, to podejście zapewnia wysoką jakość mimo różnego stopnia doświadczenia członków zespołu w zakresie poprawiających ją praktyk. W czasie QE 2020 Nadia i Adam chcą zainspirować słuchaczy do przeanalizowania swoich procesów i zaangażowania całego zespołu w zapewnianie jakości.
Piotr często spotyka się ze stwierdzeniem, że wprowadzenie testów automatycznych kodu w projekcie nie jest łatwe. Zwykle nie ma na to czasu, klienci nie rozumieją, dlaczego to ważne albo nie wszyscy w zespole są tak samo zaangażowani w testowanie. Brzmi znajomo? Pewnie wielokrotnie słyszeliście, że nie ma sensu dążyć do 100% code coverage w testach. Czy dacie się przekonać, że tak naprawdę jest to dopiero początek drogi, którą trzeba przebyć, by móc cieszyć oko dobrze napisanymi testami i ze spokojem puścić deploy na produkcję w piątkowe popołudnie? W czasie prelekcji Piotr opowie historię półtorarocznego projektu, w którym przeszedł drogę od totalnego braku testów, przez decyzję o ich wprowadzeniu i dotarciu do 100% code coverage, aż po problemy z zarządzaniem danymi i opisami testów. A to wszystko po to, by w końcu osiągnąć dojrzałe testy i przygotować plan dalszych działań, przy jednoczesnym rozwoju funkcjonalnym produktu.
Jakub przeprowadził ostatnio hurtową liczbę rozmów rekrutacyjnych. Zdarzały się fantastyczne spotkania, ale i takie, których wolałby nie pamiętać. Wyłaniający się statystyczny obraz nie napawa wielkim optymizmem. Testerzy znają narzędzia i techniki, organizują pracę sobie i innym, ale brakuje im całkowicie podstawowych umiejętności czy wiedzy. W czasie prelekcji Jakub podzieli się swoimi spostrzeżeniami i opowie o auto-refleksji, do której pchnęły go te doświadczenia. Zaproponuje także kilka prostych sposobów na to, jak można zastosować podejście shift-left, shift-right nie tylko do projektu informatycznego, ale też do swojego rozwoju. Jest bardzo ciekaw odbioru i przemyśleń słuchaczy – czy wszystkie zaproponowane elementy da się wyćwiczyć, czy część z nich jest „wrodzona”? Zastanowicie się też wspólnie, czy duże umiejętności w wąskim obszarze, z brakującymi podstawami mają w zawodzie testera rację bytu, czy powinno się je traktować jak kolosa na glinianych nogach i czym prędzej usypywać mu poprawione fundamenty.
Dobra specyfikacja i architektura REST API to:
- Dokumentacja dla zespołów konsumujących API,
- Informacja dla testerów — co i jak testować,
- Wyeliminowanie problemów komunikacji,
- Jednolite nazewnictwo wśród popularnych dziś mikroserwisów.
A tale of rockets, cavemen, code and money − developing software from a software house perspective
Working for big, well-known companies from Fortune 500 may sound prestigious. Ambitious initiatives with multiple-digit budgets, opportunities to work with numerous teams spread across the whole world sound amazing too. Everyone expects and waits for the project to be a grand success, pushing the client to the frontiers of innovation - something often dubbed ‘digital transformation’.
There’s a significant difference though when you are not working directly for those companies, but as a software house, to which they have outsourced developing the software. The brutal truth is, a lot of things you may have heard or read about software development craft do not necessarily apply while working in such a context.
In this talk, based on numerous projects and clients Michal has worked with, he wants to discuss various aspects - starting with how to sell your services, through implementing the solution and ending with going live with it and what awaits beyond. Michal wants to shed some light onto why sometimes we feel like we are building rockets for cavemen, while other times we end up looking like those who barely discovered fire.Jak bezpiecznie testować funkcjonalności „na produkcji”? W swoim wystąpieniu Ola zaprezentuje, że testowanie na środowisku produkcyjnym nie musi być czymś złym, jeśli wiemy, co robimy. Podzieli się przykładami ze swojego doświadczenia odnośnie do tego, jak można w kontrolowany sposób testować nowe funkcjonalności na web i mobile na produkcji. Nie będzie to typowa prezentacja o podejściu shift-right, ale raczej o tym, co zrobić przed wdrożeniem, by móc testować bezpiecznie po wdrożeniu produkcyjnym. Dzięki prezentacji docenicie podejście shift-left dbające o testy w trakcie wczesnych faz developmentu po to, by pokazać, co można dzięki temu zrobić później.
Przykłady, o których posłuchacie:
- feature flagi (przykład LaunchDarkly)
- customowe feature flagi (w sosie własnym)
- custom buildy i whitelistowanie
- A/B testy dla użytkowników testowych oraz A/B testy jako narzędzie badania wpływu na użytkowników.
Czy da się funkcjonować bez testów? Ile projektów może przypadać na jednego testera, zanim zgłosi załamanie nerwowe? Kiedy wyrażenie „nie ma takiej ilości kawy, żeby to zrobić”, zaczyna się urealniać? Czy QA w ogóle się opłaca? Na przykładach z (biznesowego) życia wziętych Marcin opowie, jak dzięki pozornie niewielkim zmianom udało mu się całkowicie zrewolucjonizować proces testowania. Podczas prelekcji pokaże, jakie podejmował decyzje, jakie rozwiązania wdrażał i jakie wnioski — zarówno te trafne, jak i trefne — wyciągnął, aby od zera zbudować dojrzały zespół testerów. Opowie także, jak udało się przejść wyboistą i krętą drogę, zaczynającą się w okolicach testów przez klienta robionych na produkcji do etapu, w którym ostateczny feedback to z reguły „Wspaniała robota, bez zarzutu. Trzymajcie tak dalej!”. Na zakończenie odpowie na pytanie, jak to jest z opłacalnością QA, i czy zawsze jest to opłacalność wyrażana w konkretnych liczbach — szczególnie jeśli mowa o nich w kontekście niewielkiego software house’u.
Odkąd w 2006 roku zaprezentowano koncept Consumer-Driven Contracts wiele się zmieniło. Pojawiły się narzędzia i integracje, które pozwalają skutecznie wdrożyć takie podejście w projektach. O ile zaczynamy od zera, to wszystko wygląda jak na zielonej łączce: ptaki ćwierkają, trawa szumi, pełen spokój. A co, jeśli nasza rzeczywistość to dziesiątki aplikacji, setki endpointów i daleko nam do ideału? Jak bezpiecznie podejść do kontraktów, żeby się nie sparzyć? Mateusz podczas wykładu omówi problemy, na które możemy trafić i podpowie, co zrobić, żeby kontrakty były faktycznie korzyścią, a nie kolejnym buzzwordem.
Czym jest jakość? Czy to jakieś abstrakcyjne pojęcie za które odpowiadają testerzy? Czy oznacza procent pokrycia kodu testami? A może powód do dzwonienia do programistów na urlopie?
Przez ostatnie kilka miesięcy Ola rozmawiała z inżynierami oprogramowania podczas webinarów Rozmowy o Jakości. Zaskakujące, jak szeroko można definiować jakość i jak wiele części wspólnych jest w różnych definicjach. W czasie wykładu posłuchacie o tym, czego się nauczyła dzięki tym dyskusjom. Ola przedstawi wnioski mówiące o tym, co może ograniczać nas w zapewnianiu wyższej jakości oprogramowania.
Jeden, by wszystkimi rządzić. Jeden, by wszystkie odnaleźć. Jeden, by wszystkie zgromadzić i w ciemności związać. Zachłyśnięcie się architekturą mikrousługową trwa już ładnych parę lat. Falstart, jaki popełniliśmy w IT, adoptując architekturę systemu rozproszonego bez uzasadnionych driverów architektonicznych, boli niejeden zespół developerski i utrzymaniowy do dziś. Historia lubi zataczać krąg, dlatego do łask wracają niechlubne „Monolity”. Czy rzeczywiście architektura monolityczna jest zła?
Na prezentacji zostanie omówiony Modularny Monolit – młodszy brat monolitu, który dba o dobre imię architektury monolitycznej. Omówione zostaną główne cechy takiego systemu, jak modularność oraz drivery architektoniczne, które za tą architekturą przemawiają wraz z tymi, które skłaniają do podziału Monolitu i migracji do architektury mikrousługowej. Podczas sesji zaprezentowany zostanie jeden ze sposobów projektowania Modularnego Monolitu, zgodny z najlepszymi praktykami i wzorcami projektowymi znanymi w środowisku inżynierii systemów IT.
Wszyscy jesteśmy całkiem nieźli w estymacjach — w końcu nie spóźniamy się do pracy zbyt często. A jednak w projektach estymacje zwykle wychodzą nam średnio. Skąd ta różnica? W czasie prelekcji dowiecie się, w jaki sposób estymacje i mierniki usprawniają jak najlepsze podejmowanie decyzji. Prezentacja będzie opierać się na przykładach z codziennych problemów w projektach i spoza nich. A wszystko to dopełnione rysunkami Żółwia :)
Healthy habits for Testing in DevOps
Where does testing fit in a DevOps world? How can testers, developers, and others involved in software delivery adapt to DevOps?
DevOps encourages the development and operations team to work together. This broadens the network of people who collaborate to deliver a product, which creates opportunities for the boundaries of testing to expand and nature of testing to evolve. In this session Katrina will share some healthy habits for Testing in DevOps based on her best-selling book, A Practical Guide to Testing in DevOps. She'll explain testing in DevOps and share some common DevOps practices for testing during development, in production, and against infrastructure.
Zespoły developerskie dostarczają wartość, kiedy wypuszczają nową wersję kodu dla swoich klientów. Sam proces może być różny i może zależeć od różnych czynników. Dla niektórych zespołów nowy release będzie przebiegać szybko i bez problemów, a dla innych, w najgorszym przypadku, może to oznaczać dni — jak nie tygodnie — testów regresyjnych, co w samo sobie nie dostarcza wartości dla klientów. Jak więc można przyspieszyć drugi przykład? Na pewno trzeba znaleźć i usunąć wąskie gardła (ang. bottlenecks) na tych projektach, a czymś, co może w tym pomóc, jest Modern Testing.
W czasie panelu Patryk przedstawi uczestnikom naturalną ewolucję Agile testing o nazwie Modern Testing i jego dążenie ze szczególnym uwzględnieniem „Accelerate the Achievement of Shippable Quality”. Wspólnie wgryziecie się w (czasem kontrowersyjne) zasady Modern Testing i przedyskutujecie ich wartość oraz zastosowanie w codziennych projektach i Waszych zespołach.
Przydatne informacje
Jak dojechać na miejsce konferencji? Gdzie się zatrzymać? Przygotowaliśmy szereg informacji, które mogą Ci się przydać podczas planowania wizyty w Gliwicach.
Zobacz także
2019
