Mówcy

Zobacz kto wystąpi podczas Agile & Automation Days

Jeff „Cheezy” Morgan Continuous Delivery Coach, Author

Jeff been helping companies improve the way they build software since the early days of Agile.  His emphasis on Continuous Delivery has fostered new technical and collaborative techniques that help teams deliver high quality software every day. He is driven by Lean values and principles, technical excellence and rapid delivery of value to customers.

Jeff has developed numerous open source tools to help teams with their automation efforts toward building Continuous Delivery pipelines. His book “Cucumber and Cheese – A testers workshop” has helped many people on their journey to highly automated systems done by testers, developers and business working in collaboration.  Jeff codes, coaches, trains and mentors organization leaders, teams and individuals to deliver software quickly, reliably and in a sustainable way. He argues that it is possible for a team to have zero defects and there is no need to use defect tracking tools.

Jeff was one of the co-founders of LeanDog and recently his new company, Tango, playing the role of CTO and developing people skills. While his nickname is Cheezy, there is nothing cheesy about his passion on what he does.

KEYNOTE: It’s a Strange World
What does the future look like? Some might try to look at the past as an indicator of what the future brings. Others might look at technical trends to understand where things are going. Many in our community spend no time contemplating such things. Many spend all of their time fearing what will come.

Well, we are all fortunate. Cheezy has seen the future – all three of them – and he says it’s a fun and exciting place. And this future world is coming sooner than you might think. With companies driving toward Continuous Delivery armed with DevOps and Business Agility the world of the future is a very different place than where we live today. It is sure to take us out of our comfort zone.

But what does this world look like for testers? Should we feel good about our prospects or should we fear for the survival of our unique species? As we move away from anything that remotely resembles a testing phase to a world of instantly releasing software, will developers finally take over the world?

FULL DAY WORKSHOP „Acceptence Test Driven Development”, Wednesday, 11/10/2017

The software industry is changing rapidly. With the new approaches to software development that have been introduced over the past 20 years we have learned that we can deliver value rapidly to our end users.  We have moved from yearly releases of our software to quarterly and sometimes even more frequent releases.  And yet the pace is increasing.  With the introduction of DevOps and the focus on Continuous Delivery we are learning that there is value in delivering small changes every day.

In order to work in this new world we need to change the way we test.  The idea of testing something after development is complete just doesn’t work when the code goes to production with each commit.  Even the idea of “regression” seems incompatible with the idea of CI/CD.

Join Cheezy as he introduces the technics and approaches necessary to deliver high quality software in this new world. In this hands-on workshop he will walk you through the creation of an application from scratch. As a tester you will focus on all aspects of quality for the application which include:

  • Story mapping to define the high-level application requirements and release strategy
  • Progressive Elaboration of our requirements
  • The Acceptance Test Driven Development workflow
  • Learning what to test, who should test it, and how much
  • Effective automation strategies to build useful non-brittle automation
  • How to truly leverage a Build Pipeline
  • How does DevOps change our testing approach

This workshop will for ever change the way you view testing and your role on the team.

Number of seats is limited, register now!

Alexandra Schladebeck Agile Tester, Consultant, Product Owner, Bredex

Alex fell into IT and testing in 2005 and has never looked back. She is now Head of Software Quality and Test Consulting at BREDEX GmbH and spends her time working with test consultants, developers and customers to help them towards great quality.

You’ll usually find Alex talking about quality and how it affects the whole development process. She’s also a frequent speaker at conferences where she likes to share her project experiences and learn from other practitioners.

KEYNOTE: Whole Team Quality: In the same boat or up the creek? [ENG]

Those three little words. No, not those three, the other three:

“Whole Team Quality”.

We know that successful agile teams live and breathe by this principle. But what does it actually mean in practice – and what does it not definitely not mean?

In this keynote, I’ll look at techniques teams can use to evolve their testers and developers and to empower the team to (want to) be responsible for quality together – without suggesting that what we really need is just a great super role that can do everything. I’ll tell some stories about things that have and haven’t worked and I’ll address some of the questions and fears that come up when we talk about whole team quality.

Mark Fewster Software Testing Training Consultant

Mark has over 30 years of industrial experience in software testing across test management, test techniques and test automation. He has provided consultancy and training in software testing, published papers and co-authored two books with Dorothy Graham, „Software Test Automation” and “Experiences of Test Automation”. Mark has spoken at numerous national and international conferences and has participated on the ISTQB working group responsible for the advanced level certification for test automation engineers.

Mark is the Director of Grove Software Testing Ltd., formerly Grove Consultants, offering ISTQB accredited training and licensed courseware, and test automation management consultancy.

KEYNOTE: Test Automation Health: keeping your test automation fighting fit and ready for the next challenge. [ENG]

Modern software development requires modern software testing, and that means the integration of test execution automation. The ability to run many more tests, repeatedly and faster than could ever be achieved with manual testing alone, is no longer a luxury but a necessity. Keeping the test automation healthy is important to ensure that it continues to support testing well.

Is your test automation giving you the support that you need and are you sure this will continue? After starting well, many test automation efforts do not grow from strength to strength but fail to keep pace with the increasing demands placed upon them. What we learn from the automated tests then becomes less useful, less reliable and misleading.

Fortunately, this decline is not inevitable. It is possible to spot the symptoms of trouble early on and act to correct the issues before they inflict long term damage.

We need to learn to distinguish between automation that is and is not healthy, by understanding the symptoms of test automation disorder and disease, and by learning what trends to monitor. Decreasing benefits, increasing costs, use avoidance and hand-holding are just some of the symptoms that we need to be looking out for.

 

Marcin Grzejszczak Author

BIO: Author of „Mockito Instant” and „Mockito Cookbook” books. OSS Contributor. Co-founder of the Warsaw Groovy User Group and Warsaw Cloud Native Meetup. Lead of Spring Cloud Sleuth, Spring Cloud Contract and Spring Cloud Pipelines projects at Pivotal. Contributed to Groovy, Mockito, Rest-assured, Drools, Moco. Author of Uptodate Gradle plugin, Spock subjects-collaborators extension, gradle-test-profiler, JSONAssert and XMLAssert open source projects.

Presentation including live coding (60 min): Consumer Driven Contracts and Your Microservice Architecture

Consumer driven contracts (CDC) are like TDD applied to the API. It’s especially important in the world of microservices. Since it’s driven by consumers, it’s much more user friendly. Of course microservices are really cool, but most people do not take into consideration plenty of potential obstacles that should be tackled. Then instead of frequent, fully automated deploys via a delivery pipeline, you might end up in an asylum due to frequent mental breakdowns caused by production disasters.

We will write a system using the CDC approach together with Spring Boot, Spring Cloud Contract verifier. I’ll show you how easy it is to write applications that have a consumer driven API and that will allow a developer to speed up the time of writing his better quality software.

John Ferguson Smart Consultant, Author and Trainer

John is an international speaker, consultant, author and trainer well known in the Agile community for his many books, articles and presentations, particularly in areas such as BDD, TDD, test automation, software craftsmanship and team collaboration. John helps organisations and teams around the world deliver better software sooner through more effective collaboration and communication techniques, and through better technical practices. John is the author of the best-selling „BDD in Action”, as well as „Jenkins: The Definitive Guide and Java Power Tools”. Very active in the Open Source community, John also leads development on the innovative Serenity BDD test automation library, described as the „best opensource selenium webdriver framework”.

Workshop (120 min): Feature Mapping – The Fast Track from Stories Executable Specs [ENG]

Writing good acceptance criteria is one of the keys to effective software delivery. But it’s hard. In this workshop, you will learn about Feature Mapping, a new technique and easy that can help teams write higher quality acceptance criteria more easily. Simple and pragmatic, yet suprisingly effective, Feature Mapping is an excellent way to build a deep shared understanding of a story’s requirements and clear a path to a smooth implementation of automated acceptance tests.

In the hands-on workshop, you will not only experience Feature Mapping for yourself, but see first-hand how simple facilitation techniques can maximise creativity and productivity in ways that leave traditional, brainstorming-based requirements discovery sessions in the dust.

Presentation followed with panel discussion: Shift-Left: The role of the tester in a DevOps world [ENG]

In this talk, you will learn about the changing role of testing and test automation in the increasingly fast-paced world of continuous delivery and automated acceptance testing. Learn how, in a DevOps environment, testing activities start with requirements discovery and definition, playing a vital role in not only detecting defects, but preventing them, and ensuring not only that the features are built right, but the right features are built. And learn how test automation needs to happen during, not after, the sprint, and how you can achieve this.

Mirjana Kolarov Test Department Manager and Test Architect, Levi9

BIO: Mirjana is co-founder of the first testing community in Serbia, called Test’RS Club (testrs.club). After more than 8 years in testing she concluded that she needs to give it back to the community and started speaking and doing workshops. During the day she is a Test Department Manager and Test Architect at Levi Nine IT Services. But above all she is passionate and highly motivated software tester who loves getting her hands dirty with actual testing, and leads by example, promoting appropriate and deliberates testing skills and techniques.

Presentation followed with panel discussion: Balancing your test automation with exploratory testing
[ENG]

In Agile things are going very fast. In most cases, we cannot achieve good testing with only manual testing. We need test automation to speed us up, and to cover the regression testing. UI testing is not the only thing to be automated, due to the constant changes. API should also be covered with tests. Even with this coverage, can we rely on the test automation only? No. The common pitfall I see these days is trying to automate all, and not dedicating any (testing) time to other ways of testing. This is where exploratory testing comes into spotlight – to find defects which are not covered with automation, and which can never be covered with scripts.
In this presentation I will give you my opinion of the right balance of automation and exploratory testing on all testing levels. Since we tried different approaches so far, I’ll try to highlight lessons learned. Also, I will explain which tools we use for test automation and which tools we use for exploratory testing.

Alper Mermer Lead Consultant, ThoughtWorks

BIO: I’ve been testing software for more than 10 years. I’ve worked in number of sectors such as Finance, Telco, Banking, Retail etc where i had the oppurtunity to practice both Exploratory Testing and Automated Test implementations. I’m the founder of the QA community Test Hive in which we hold regular meetups and workshops both in Istanbul Turkey and Manchester UK. I’m currently working as a Lead Consultant in ThoughtWorks UK.

Presentation followed with panel discussion: Testing Microservices in Isolation: Unique Data Management, API Journeys and Mocking [ENG]

In this talk we’re going to explore ways to implement and automate our tests in in a microservices environment. We’re going to focus on the isolation of our tests.
First part is going to be about unique data management. In order to have a repeatable and independent test execution we have to do two things; make every test manage its own data (its own data only) and make those data unique and dynamic so that there are no conflicts in test execution. In a hermetic test environment where all the tests are executed in a seperate entity (container, box, vm etc…) it’s much easier to manage data locally but in most of the real corporate world your tests will have to share some data structure with other tests and applications. We’re going to talk about how to manage those environments. I’m going to show some code pieces as examples here for the implementation of data management.
Second part is going to be about defining API journeys and Mocking. We’re going see how we can build service journeys by mocking the external service implementations. While it’s always beneficial to have a fully functional end to end service testing in place, time constraints and asynchronous development of services might force you to test things with mocks. We’re going to touch on what is a Journey Test and how to implement mock services for those journeys using Mountebank. This section is going to include sample codes from a demo API service and Mountebank itself.

Daniel Dec Software Quality Engineer, Quality Keys

BIO: Z niejednego projektu jadał chleb, był w projektach bardzo małych i bardzo dużych, bardzo prostych i dość skomplikowanych. Szkolony do misji specjalnych. Rekrutuje, prowadzi szkolenia, występuje na konferencjach, mentoruje, filozofuje, ma cięty język i trudne do kompilacji żarty. Uważa, że wspomaga zespoły developerskie z sukcesem i rozumie również architekturę systemów. Ma nadzieję, że developerzy uważają tak samo, a poza tym lubi z nimi dyskutować na temat sensowności ich rozwiązań szukając luk stosując zasadę ograniczonego zaufania. Jego jednym z radykalnych poglądów jest to, że QA i tester to jest ta sama rola, nie dopuszczając do siebie myśli, że tester może nie być QA. Nie uznaje podziałów testerów na biało, różowo czy szaroskrzynkowców lub technicznych i nietechnicznych. Sprawiają mu przykrość słowa „nie da się”. Współorganizator i pomysłodawca konferencji Quality Excites oraz Quality Meetupa. Nie odmawia współpracy z innymi firmami, bo lubi nowe wyzwania i lubi wiedzieć i widzieć, jak ludzie robią rzeczy (nawet jeżeli robią je źle;)). Marzy o napisaniu książki. Obecnie niepraktykujący piwowar acz ze świeżym dyplomem o ukończeniu kursu sensorycznego który pozwala mu dobitnie testować złociste trunki. Perkusista amator z rozpadniętym zespołem. Zaangażowany w budowę studenckiego satelity PW-SAT2 (http://pw-sat.pl/) a konkretnie komputera pokładowego mając nadzieję, że jego wystrzelenie pod koniec roku 2017 nie spowoduje zagłady.

Presentation with panel discussion (60 min): Konsultant nie zawsze robi to z półobrotu* [POL]

Stajesz przed faktem dokonanym – trafiasz do potencjalnego klienta, który jeszcze nie wie z czym ma problem, ale wie, że ma. Może się też zdarzyć, że wie z czym ma, ale potrzebuje potwierdzenia.  Inna sytuacja jest taka, że klient wie, że ma problem, wie z czym, ale … po Twoim badaniu okazuje się, że dokonane obserwacje nie potwierdzają z góry postawionej tezy. Po kilku dniach masz przedstawić raport, masz ocenić jako wyrocznia, masz zaproponować zmiany, określić stan obecny i zrozumieć co trzeba zrobić, aby osiągnąć stan docelowy, jak się do tego zabrać?
Potrzebujesz planu działania, aby osiągnąć cele … ale właśnie jakie są cele? Czyje to są cele? Konflikt interesów.

  • Jaką miarą oceniać?
  • Audyt czy konsultacje, coaching czy mentoring – jest jakaś różnica?
  • Jak głęboko wchodzisz w szczegóły, jak bardzo drążyć – Ty kontra czas i poziomy, na których operujesz.
  • Opór Twoich rozmówców – z kim rozmawiać i jak zadawać pytania.
  • Co powinien zawierać raport, jeżeli w ogóle powinien on powstać – wyniki Twojej pracy.
  • Kiedy uciekać, gdzie pieprze rośnie.

W którymś momencie naszej kariery zostaniemy poproszeni o pomoc w innym projekcie, w innej firmie, u naszego a być może przyszłego klienta. Pomoc może dotyczyć procesu, narzędzi, podejścia, ale też oceny jakościowej projektu. A może Ty szukasz nowych wyzwań i chcesz spróbować swoich sił w takich usługach? Jak być gotowym na ten moment? Jakie drzemią pułapki? Jakich błędów się ustrzec, a jak możemy się do tego przygotować. Brzmi jak wyzwanie?

Podczas mojego wystąpienia chcę podzielić się moimi doświadczeniami oceny zewnętrznych projektów, audytowania i usług doradczych.  Oczywiście moje historie będą tylko przyczynkiem do wspólnej dyskusji.

Dyskusję ubogacę przykładami swoich historii zarówno z projektów wewnętrznych, zewnętrznych, ale też wizyt u w innych firmach, a każda będzie z zupełnie innej beczki.

*co nie oznacza, że czasami robi to z półobrotu

Workshop (3 h): Lepsze testy – ćwiczenia praktyczne”. [POL]
co-speaker: Tomasz Wierzchowski

Zainspirowani zeszłorocznym wystąpieniem Bartka Szulca na Quality Excites chcielibyśmy pociągnąć temat ‚Lepszych testów’ i razem z uczestnikami warsztatów zastanowić się głębiej nad testami automatycznymi. Na początku warsztatów uczestnicy będą mogli zapoznać się z pewną implementacją testów. Następnie, wspólnie pomyśleć co jest dobrze rozwiązane, a co sprawia największe problemy. W końcu w praktycznych ćwiczeniach poprawić je oraz przedyskutować rozwiązania. Zaprezentowane problemy i techniki będą opierać się o xUnit test patterns oraz nasze doświadczenie zdobyte w różnych projektach. Uwaga – to nie są warsztaty z Selenium;), Poziom trudności warsztatów określamy na średnio-zaawansowany, ponieważ ćwiczenia wymagają znajomości podstaw programowania (solucja testów w C#).

 

 

Piotr Wicherski Senior Software Test Engineer

BIO: Certified software tester, and also great enthusiast for all kind of mobile devices and mobile operating systems. I can’t resist any new mobile technology like wearables and part of IoT. Worked for companies such as T-Mobile, Samsung Electronics R&D and Allegro. Helping them ship the best quality products on the World mobile market. Administrator of Software Testing Facebook group Organizer of Polish QA Conference TestWarez. Mentor and speaker on events like: TestWarez, Agile & Automation Days, TestingCup, BrainCode Mobi and ATM.

Presentation: Jak przypadkiem wpadłem w TestOps [POL]

Pewnego dnia wpadłem na pomysł stworzenia czegoś nowego w firmie w której pracuję. Stworzyłem projekt, przedstawiłem go wraz z założeniami i raportem moim przełożonym. Pomysł z założenia był prosty. Wziąć komputer, podłączyć do niego kilka urządzeń i tym samym usprawnić proces automatyzacji testów aplikacji mobilnych w firmie. Brzmi prosto, prawda? Projekt się spodobał, otrzymałem zielonego światło, własny projekt i programistę do pomocy! Tak rozpoczęła się historia powstawania laboratorium urządzeń mobilnych.

Chciałbym opowiedzieć Wam historię o tym jak prosty w założeniach pomysł przerodził się w realiach dużej firmy w ogromne wyzwanie dla małego dwuosobowego zespołu sprowadzając pracę testera na całkiem nowe tory.

Poznasz historię przejścia z pojedynczego komputera osobistego na obsługę serwerów z perspektywy testera aplikacji mobilnych. Porzucenia graficznego interfejsu użytkownika na rzecz linii komend linuxa server. Jednego telefonu na rzecz kilkudziesięciu. Gdzie problemy z własnym antywirusem zmieniają się w problemy bezpieczeństwa wewnętrznej infrastruktury. A awaria jednego telefonu może zniszczyć cały budynek.

Wymagania wstępne: Podstawowa wiedza z zakresu testowania oprogramowania i chęć posłuchania pewnej historii.

Mark Hrynczak Cloud Quality Engineering Manager, Atlassian

BIO: I’ve led QA and QE teams – large and small, agile and waterfall, local and distributed. I believe in solving the right problems at the right time, rather than a standard approach. I build high-performing, balanced, and adaptable teams; I help dev teams achieve excellence; and I foster a culture of innovation. Sometimes I code, but rarely to production-quality.

Presentation followed with panel discussion: Do Less Testing [ENG]

Testing is not a vital function. What we actually want is high-quality software. A development team able to produce better code and ship better features – while also reducing the time invested into testing cycles – is a more efficient, higher-performing team.

Testing is seen as crucial in many organisations, because it is where potentially serious problems are found. It is the last line of defence against low-quality releases. This perspective leads to counterproductive results – longer release cycles, inevitable duplication of effort, and low flexibility around release dates.

I’ll talk about proven methods to break out of this cycle of dependence, and reduce the reliance on testing. I’ll cover:
• Mindset – how quality-awareness in developers and their managers can reduce time spent on testing
• Accountability – how putting the responsibility for quality onto developers leads to better code
• Alignment – how a shared understanding of quality across the entire team facilitates good decision-making
• Process – how quality considerations can be integrated to minimise rework maximise efficiency
• Measurement – how valid use of metrics can help teams improve
• Techniques – how alternatives to testing can improve quality outcomes
• Automation – how effective use of automated tests and deployments can increase the team’s dev speed

Alexei Vinogradov Consultant, freelance

Alexei has been working in various IT projects in Germany for more than 15 years. He consults about quality assurance, test automation and about how to keep calm and be a good tester. Developer of Selenide. The founder and moderator of Radio QA podcast. Speaker at various IT conferences, since 2014.

Presentation: Selenide & KISS-Driven Automation [ENG]

As Selenium WebDriver is known to be a tool for browser automation and not for testing, we are doomed to use some testing frameworks to get efficient at automating web tests. But should every project reinvent the wheel? My answer is – “no!”

Selenide (http://selenide.org) is a well-known, mature (5+ years) web test automation framework with a large community, and has already solved almost every typical web automation problem. Just write your web tests in concise, easy to read manner, and concentrate on your business problems and not on taming your browsers.

In this presentation I’ll demonstrate how Selenide ease a pain of using typical automation design patterns. Also I’ll introduce the principles of KISS-Driven-Development and show how they work with Selenide.

Dusanka Lecic Test Developer, Levi9

Dusanka works as a test developer at Levi9 IT Services. Last year she finished her PhD Thesis. During ten years of her career she was a speaker at international conferences and author of many scientific papers. When she first met the testing, she realized that she completely finds herself in software testing. Working as a test developer isn’t just a job for her. It is more like a passion that grows from day to day and making her so curious to learn more and more. Every conference is a new challenge to present her knowledge in a best way.

Presentation: FUN(ctional) REST API testing with Clojure. [ENG]
co-speaker Marijan Mihaljev
 
Functional programming is a programming paradigm – a style of building the structure and elements of computer programs that treats computation as the evaluation of mathematical functions and avoids mutating objects state. Clojure as a functional programming language is a dynamic programming language, combining the approachability and interactive development of a scripting language with an efficient and robust infrastructure for multithreaded programming. It is highly declarative, meaning you build programs from expressions that describe „what” a program should accomplish rather than „how” it accomplishes it.
Clojure is “homoiconic” language, which is a modern term describing the fact that programs are represented by data structures. This is very important difference between Clojure and most other programming languages. Clojure is defined in terms of evaluation of data structures and not in terms of the syntax of character streams/files. Most Clojure programs begin as text files and it is the task of the reader to parse the text and to produce the data structure the compiler will see. Clojure is a compiled language, yet remains completely dynamic – every feature supported by Clojure is supported at run-time. Another one of the cool things in Clojure is REPL (Read–Eval–Print Loop) – an interactive programming shell that takes single expressions, evaluates them and returns the results.
This presentation has a goal to show the use of Clojure to create automated testing framework for REST API testing. As it’s Lisp based, Clojure is language with almost no syntax. In this presentation the authors will demonstrate basic features of Clojure and overall structure with a view on testing framework for REST API testing. Also, authors will demonstrate usage of some common Clojure tools and libraries. As one of the popular project management tools for Clojure, Leiningen is an automation tool that helps automate the build and management of projects. Cursive – the IDE for Clojure code, is also used. Cursive is written entirely in Clojure, allowing us to easily integrate all the fun tooling in the Clojure system. Cheshire is for working with JSON – encoding and decoding library for Clojure. Beside practical examples in this presentation that are showing REST API testing, authors have provided some basics of REST API testing also. In the end, we want to show you simplicity in REST API testing.

Anastasiia Naboikina Senior Software Test Development Engineer, Sii Poland

Bio: Originally from Ukraine, I have been working in Poland for 3.5 years now. I am experienced in a number of business domains, such as Cloud Computing, Medical industry devices, Intelligent Home Systems, and Enterprise Cloud Storage. I have tried myself in different roles, from a QA lead to a developer. I especially like working with dynamic programming languages, my favorite one is Python, but I also have expertise in React.js and node.js, which I acquired while being a part of a cross-functional team as a developer. I am a passionate perfectionist, always doing my best to improve myself and the world around me. My life principle is to never stop and move forward toward my dreams. Life is short and it should be bright, shouldn’t it? Speaking of hobbies, I am really into sports, music and active lifestyle. Fitness and cycling are my main sport passions. In my free time, I love to compose music and record new tracks on my synthesizer. I am really fond of jazz and progressive rock, I do both, listening and playing. One of my dreams for the future is to conquer the air. One day I would like to learn how to fly a small plane.

Presentation: Effective QA Task Management in Cross Functional teams [ENG]

Nowadays most of the companies start to follow more agile approach. Roles within the team become more and more blurred, making everyone focus on the goal, but not on the skills of the members. Business doesn’t wait and keeps setting tight deadlines. Engineering must react fast and adjust their daily tasks towards meeting the new needs.  So, how can we be productive in such conditions and most importantly deliver high quality products?

We will try to answer this question and dive into the meaning of cross functional team. During the presentation we will define solutions for top 5 important issues:

  • Unexpected tasks from other teams or business plans changes;
  • Constant context switching;
  • Visibility of current QA status;
  • QA/Dev task sharing within the team;
  • Long QA cycles before release.

A short demonstration will show how to setup such process on JIRA, how to separate test cases and test tasks and dev tasks and which types of tasks you may add to your project. Additionally there will be a short introduction how to use Zephyr test management tool and link the test cases with Jira tasks as part of Definition of Done. We will also cover how to share testing tasks with developers and how they can help with testing.  At the end we will look at the estimated results and analyze in which cases this approach might not work.

Marijan Mihaljev Developer/Team lead, Levi9

Marijan works as Developer and Team Lead at Levi9 IT Services. Marijan works at Levi9 IT Services. Marijan works as Developer. Also, he is Team Lead. And works as Developer. At Levi9 IT Services. He works there. With others. As Developer. And as a Team Lead. At Levi9 IT Services. Where he works as Developer. And Team Lead. Besides that he does stuff. Sometimes smart.

Presentation: FUN(ctional) REST API testing with Clojure. [ENG]
co-speaker Dusanka Lecic
 
Functional programming is a programming paradigm – a style of building the structure and elements of computer programs that treats computation as the evaluation of mathematical functions and avoids mutating objects state. Clojure as a functional programming language is a dynamic programming language, combining the approachability and interactive development of a scripting language with an efficient and robust infrastructure for multithreaded programming. It is highly declarative, meaning you build programs from expressions that describe „what” a program should accomplish rather than „how” it accomplishes it.
Clojure is “homoiconic” language, which is a modern term describing the fact that programs are represented by data structures. This is very important difference between Clojure and most other programming languages. Clojure is defined in terms of evaluation of data structures and not in terms of the syntax of character streams/files. Most Clojure programs begin as text files and it is the task of the reader to parse the text and to produce the data structure the compiler will see. Clojure is a compiled language, yet remains completely dynamic – every feature supported by Clojure is supported at run-time. Another one of the cool things in Clojure is REPL (Read–Eval–Print Loop) – an interactive programming shell that takes single expressions, evaluates them and returns the results.
This presentation has a goal to show the use of Clojure to create automated testing framework for REST API testing. As it’s Lisp based, Clojure is language with almost no syntax. In this presentation the authors will demonstrate basic features of Clojure and overall structure with a view on testing framework for REST API testing. Also, authors will demonstrate usage of some common Clojure tools and libraries. As one of the popular project management tools for Clojure, Leiningen is an automation tool that helps automate the build and management of projects. Cursive – the IDE for Clojure code, is also used. Cursive is written entirely in Clojure, allowing us to easily integrate all the fun tooling in the Clojure system. Cheshire is for working with JSON – encoding and decoding library for Clojure. Beside practical examples in this presentation that are showing REST API testing, authors have provided some basics of REST API testing also. In the end, we want to show you simplicity in REST API testing.

Remigiusz Dudek Agile testing trainer

BIO: Remigiusz Dudek – an Agile testing trainer and a member of a mature Agile team, for years working on assuring quality not only of a software but also quality of a software development process. In his career he worked on various positions: as a developer, tester, test leader, project manager, QA Engineer. Such variety of experience gives him an opportunity to look at a given problem from many perspectives and choose the optimal solution. Currently, he’s been working on a position of QA Engineer assuring quality of banking systems for over 5 years.

Presentation: How Classic QA/Test Management tools can improve your agility? [ENG]

High quality software does not just happen by chance. It requires lots of effort to assure quality. Since lots of effort usually corresponds to lots of money it needs to be properly managed, hence proper management tools are needed. One always has to pick tools that would work best under given circumstances. During my talk I will focus on agile environment (the one that truly requires short turn around in terms of responding to change) and a long living software (I will not talk about short 1-6 months projects). Having the environment defined I will show not only how using classic tools can be replaced with other tools more suitable for agile teams but also how using classic tools may do harm.

I’ve done some research (on various conferences and forums) to gather reasons why people usually need test management tools, here is fairly complete list:
– to measure how effective is Test Suite
– test execution report
– test execution progress management
– coverage in terms of code
– coverage in terms of business requirements
– traceability
– optimize test suite
– store test cases
– plan test case creation/execution
– facilitate learning for New Joiner

My experience shows that whenever you need a separate Test management tool to satisfy any from the above needs, it indicates that you’re doing something in a sub-optimal way, and it can be done better.
The only thing I’ve found so far that you can do little about is Audit – if in order to get ISO-9XXX badge, you need to have certain tools, what can you do? Educate auditors, but that’s a c.

Adrian Gonciarz Senior QA Engineer, Collective Sense

BIO: Jagiellonian University Faculty of Physics graduate. Former QA engineer and test manager in Oracle, Appdate Development and DREDAR. Currently senior QA engineer in Collective Sense. Also conducts lectures at post-graduate studies in software testing at Vistula University, Warsaw.
Co-organizer of Cracow QA meetup group KraQA. Polish software testing team champion, Testing Cup 2016. Particullary interested in API test automation, performance testing and DevOps. Also a huge fan of self-improvement and soft skills.

Workshop (120 min) „Tester w Kontenerze – zdockeryzowane środowiska testowe” [POL]

Jednym z największych problemów, z jakim borykają się zespoły testowe, jest konfiguracja środowisk i danych testowych oraz łatwe zarządzanie testami automatycznymi w tych środowiskach. Z pomocą zespołom developerskim i testerskim może przyjść Docker — narzędzie do „wirtualizacji” aplikacji oraz testów. Dzięki zastosowaniu Dockera możliwe jest nie tylko łatwiejsze budowanie środowisk lokalnych w codziennej pracy testerów, ale także dokładniejsze konfigurowanie środowisk do testów regresyjnych oraz wykonywanie testów automatycznych w Continuous Integration.

Warsztaty podzielę na 3 części:
1. Zbudowanie przykładowego obrazu zawierającego proste API oparte o: obraz bazowy NodeJS oraz https://github.com/typicode/json-server
2. Zbudowanie i uruchomienie prostego testu korzystającego z Rest-Assured, Java, Maven
3. Skonteneryzowanie testów i uruchomienie ich z użyciem docker-compose
Warsztaty skierowane są do grupy bardziej doświadczonych słuchaczy znających podstawy Java, Maven oraz API REST. Do udziału w warsztatach będzie wymagane łącze internetowe, laptop z zainstalowanymi: Java 1.8, Maven (wersja do ustalenia, na razie 3.3.9), Docker oraz IntelliJ (lub wybrane inne IDE). Uczestnicy powinni posiadać konto na Github lub Bitbucket.

Alex Chumakin Backend QA, Juno

BIO: Backend QA Engineer in Juno, US startup company in the ride-sharing business with RND center in Minsk. I have many years in QA automation area. The most of them are in different backend systems. I have good experience in projects with huge numbers of GUI tests and that’s why I know why it’s really bad to develop and support tests for user interface and always try to bring this knowledge to audience.I was a mentor of many QA members, prepared different internal talks about QA Automation for all level specialists. Also, I’m a speaker in many local and international conferences.

Presentation followed with panel discussion: Honest, simple and fast isolation tests.[ENG]

In this talk I will show how to make many thousands of tests stable, honest and very fast. I’ll explain the main ideas and basic examples of our approaches to microservices testing. The talk will also contain some ideas how to work in huge backend team of strong engineers and to support stable system with daily releases.

Sebastian Miałkowski Software Engineer, Spartez

BIO: I have finished computer science studies on Technical University in Gdańsk with Bachelor of Engineering degree. I am currently in the process of writing my master thesis. I have been working in Spartez for 2 years now. I started as java developer in JIRA cloud performance team. After 6 months I have joined JIRA Site Reliability Engineering team where I am responsible for improving JIRA monitoring, react to problems on production and fix them before customer notices.

Presentation: How to find issues before customer do [POL]

Running a big Product as a Service, like JIRA Cloud, is a challenge. JIRA Site Reliability Engineers (or JSRE in a short) deal with a lot of things on a daily basis, and probably the less pleasant one is reacting to the issues introduced with the most recent version update. Such situation is stressful because you are expected to address a problem before it’s noticed by your customers, so you are under preasure of time and responsibility. And you have a huge code base so figuring out what caused an issue may take a while.

That’s why JSRE developed a tool to fix JIRA faster. Please meet Instablame. It combines a power of logging as a service (splunk), source code repository management (bitbucket) and JIRA systems. Instablame allows to:

  1. Detect new errors as they appear in real time
  2. Correctly prioritise those errors based on the historical data, frequency of occurrence, number of affected customers etc.
  3. Build a special „class index” of the needed version of JIRA, across multiple repositories in use
  4. Analyze error and detect what changes caused it – line by line, repository by repository. This is  similar to Git „blame” command hence the name – Instablame
  5. Based on the analysis – make a decision on how to proceed – rollback the release, implement a fix, or contact responsible team

This presentation will focus on how Instablame operates, how we use it, and further plans of tool development.

 

 

 

Adrian Mucha Senior Quality Engineer, Objectivity

BIO: 2015 – to wtedy Adrian dołączył do Objectivity jako Senior Quality Engineer, choć jego podróż z testowaniem rozpoczęła się jeszcze za czasów studiów. I choć brzmi to górnolotnie – testowanie to pasja Adriana, a jego wiedza z tego zakresu jest naprawdę imponująca. Specjalizujesię w testowaniu rozwiązań Business Inteligence (PowerBI, BusinessObjects, Reporting Services) oraz hurtowni danych, automatyzacji testów (Selenium WebDriver, CodedUI), testach wydajnościowych (Visual Studio Load Test, JMeter), a i testowanie web service jest mu bliskie. Odskocznią od jego służbowych obowiązków są góry – jak sam mówi, najefektywniej odpoczywa przemierzając kręte, beskidzkie szlaki – a wybiera zawsze te najtrudniejsze i nigdy nie chodzi na skróty.

Presentation: What our automated test can tell us what we don’t know yet

Wyobraź sobie, że masz projekt, w którym masz za zadanie zbudować testy automatyczne. Wybrałeś najlepszy framework do zbudowania tych testów. W twoich testach zastosowałeś najlepsze praktyki, takie jak PageObjectPattern. Swoje testy oparłeś o piramidę testów, zbudowałeś środowisko uruchomieniowe najlepiej jak potrafiłeś na którym uruchamiasz testy równolegle. Wszystko to jest wysiłkiem wielu członków zespołu: testerów, developerów oraz managerów, aby dostarczyć jak największą wartość z wykonanej pracy. Jednak na samym końcu, po wielu miesiącach uruchomień Twoich testów ciągle jest z nimi coś nie tak. Testy kończą się błędami chociaż nie powinny z powodów często niespodziewanych i zazwyczaj losowo lub ich czas wykonania się wydłuża w miejscach w których nie było zmian od miesięcy.

Celem tej prezentacji, na którą chciałbym Was zaprosić jest pokazanie, jak posiadając wszystkie rzeczy, które już mamy uczestnicząc w takim projekcie, zacząć szukać przyczyn wymienionych niepowodzeń. Swoje przykłady oprę o wiedzę z rzeczywistych projektów oraz pokażę:

  • Jak efektywnie zbierać dane do przyszłej analizy problemów,
  • Jakie informacje możemy wyciągnąć z narzędzi Continous Integration,
  • Jak w zbudować w swoich projektach prostą solucję opartą o Business Intelligence.

.

Ewa Ludwiczak Software test engineer, Allegro

​Ewa is software test engineer focused on mobile iOS app testing and development. In Allegro Group works in agile team where she continually improves her testing, programming and negotiation skills. Systematically shares her knowledge at local meetups like Geek Girls Carrots, PyLadies, PTAQ, WrotQA and conferences e.g. Testwarez. Certified SCRUM devotee and dance lover.

Presentation followed with panel discussion: iOS testing from top to bottom [ENG]
co-speaker: Kamil Pyć.

If you are curious how we test iOS mobile applications in Allegro, this lecture is suited for you. We think of app testing right after opening Xcode, creating user interface and writing final implementation. Depending on different development stages, we test different subjects with different tools. Feel invited to learn our story about following stages of testing, starting from unit, through snapshot and functional testing. True story based on developer’s and tester’s experience.

Kamil Pyć iOS Application Developer

He is developing iOS applications for over 6 years. In work he strongly believes that everything can be automated and tested. In his free time he creates crazy projects during hackathons and travels around the world.

Presentation followed with panel discussion: iOS testing from top to bottom [ENG]
co-speaker: Ewa Ludwiczak

If you are curious how we test iOS mobile applications in Allegro, this lecture is suited for you. We think of app testing right after opening Xcode, creating user interface and writing final implementation. Depending on different development stages, we test different subjects with different tools. Feel invited to learn our story about following stages of testing, starting from unit, through snapshot and functional testing. True story based on developer’s and tester’s experience.

Maciej Wyrodek Software Tester, Kobo

„I am part of that power which eternally wills evil and eternally works good”

A Tester with about six years of experience. He became tester because it was the only legal way to inflict destruction, suffering, and misery on others. He specializes test automation, but his first love is Manual Testing. Currently working at Kobo, and in free time writing his blog: http://thebrokentest.com/.

Preentation followed with panel discussion: When machines lie to us and why manual testing is still needed  [ENG]

The growth of Agile also caused an incredible spread of automation. But sometimes we are too trusting. Machines are not raising yet against us, but they have already learned how to lie to us. Let’s take a look at a few stories of different automation failures and how they could be avoided with a minimal amount of manual testing.

 

 

Oleg Kulynyak Test Automation Leader

BIO: Ambitny i ciekawy innowacji i nowinek świata IT oraz QA, Automatyzator Testów, Lider zespołu automatyzacji testów. Również próbuje swoich sił w roli Menadżera Testów.
Absolwent Politechniki Lwowskiej oraz Wyższej Szkoły Menadżerskiej w Warszawie.
Niegdyś Kierownik zmiany działu kotło-turbinnego na elektrowni cieplnej, w branży energetycznej; trener w obszarze „lean management”.
Uczestnik i Laureat 2 miejsca w Zawodach Automated TestingCup 2016.
W swojej codziennej pracy lubię pokonywać trudne wyzwania, które prowadzą do zamierzonego celu. Każdy problem i zadanie analizuję pod kątem wielu możliwości, co poniekąd jest moją pasją.
Chciałbym się podzielić moimi doświadczeniami, zarówno opatrzonymi porażkami, jak i sukcesami codziennej pracy z Uczestnikami Konferencji Agile & Automation Days.

Presentation: Automatyzacja testów eksploracyjnych – sztuka dla sztuki, czy realny zwrot z inwestycji? [POL]

Z założenia technika testowania eksploracyjnego ma na celu równoczesne weryfikowanie i uczenie się analizowanej aplikacji. Zadania testowe poszatkowane są według zestawów test ideas, które zamknięte są w sesjach testowych. Praktyka nakazuje krótkie, godzinne sesje testowe. Jak w takim czasie skorzystać z automatyzacji? W jakim kontekście automatyzować regresje i jak wyznaczyć jej zakres?
W swojej prezentacji pokaże praktyczne przykłady wsparcia narzędziowego, automatyzacji testów eksploracyjnych. Eksploracja testowa aplikacji nie musi odbywać się wyłącznie manualnie. Możemy zwiększyć liczbę testów przygotowując zestawy danych testowych używając narzędzi. Wcześniej przygotowane skrypty testowe, zanim powstanie interfejs użytkownika testowanej aplikacji, mogą być wykorzystane do pre konfiguracji danych wejściowych dedykowanych zestawów testowych. Podobnie przy wykonywaniu zaplanowanych testów, automatyczne skrypty testowe (dla przykładu zaimplementowane w Selenium WebDriver) w szybki i łatwy sposób sprawdzą walidacje na formularzach aplikacji. W realizowanych projektach automatyzujemy również porównywanie wyników uzyskanych z przeprowadzonych testów z oczekiwanym rezultatem, jak dla przykładu porównywaniu procesów batchowych przetwarzających pliki płaskie, WebSerices, porównywanie raportów, faktur i innych dokumentów.
Wprowadzenie automatyzacji do ścieżek testów eksploracyjnych, stawia wiele wyzwań przy ich planowaniu i projektowaniu. Jednakże pozwala realnie zaoszczędzić koszty realizacji testów w całym projekcie informatycznym. Ponadto zaprojektowane automatyczne skrypty testowe mogą być wykorzystane przy kolejnych sesjach, wydaniach, projektach a także wspieraniu testów akceptacyjnych, utrzymania czy też wdrożeniach.
Na koniec zapraszam Uczestników do wspólnej dyskusji na temat wspierania narzędziami testów eksploracyjnych i opłacalności tego przedsięwzięcia. Podzielę się z Uczestnikami przykładami z własnego doświadczenia, które opatrzone były wieloma próbami błędów, jakie popełniliśmy. Nadal poprawiamy procesy w naszych projektach, aby przyniosły większe korzyści czasowe, ale i pozostawiły więcej czasu na pracę kreatywną testerów, a odciągnęły ich od powtarzalnych, algorytmicznych zadań.

Aleksander Zaleski Exploratory Tester

Exploratory Tester, Test Manager for Millenials, Researcher, Agile enthusiast, Procrastinator. Experience in Telecommunications, Investment Banking, Manufacturing, CRM systems etc. Enjoy sharing my experience and helping others to improve in their own way. When not testing I am playing and organizing Pub Quizes and similar intellectual challenges.

Worskhop: Selenide. Jumpstart your Test Automation

This talk is aimed to people who start their journey with Test Automation. In this workshop I want to show how to start a web automation project using Selenide.

Selenide is an open-source, free, stable test automation framework with concise API and community support. It can be an entry point to people who want to learn Selenium with Java, Groovy and even Scala. It can be used together with Junit, TestNG, JBehave, Cucumber and many other testing frameworks.

We will start a project from scratch and write several tests that solve typical web automation tasks in a simple and concise manner. This will be achieved by applying Keep It Simple Stupid (KISS) and Don’t Repeat Yourself (DRY) principles. We will cover basics of XPath and CSS Selectors, assertions, collections, custom matchers learn how to interact with different web elements (forms, radio button, dropdown menu etc.), get the idea of Page Object pattern and see how files can be uploaded and downloaded.

From more advanced side we will learn how Selenide simplifies usage of Waits that is of great help and saves a lot of time that otherwise would be spent on debugging, especially in applications that use Ajax.  Additionally, I will demonstrate how it helps to get rid of StaleElementExceptions and many more tips and tricks.

Szymon Ramczykowski Lead Test Engineer, Kainos

I have been a Tester since 2009. Being involved in various projects, my main interests have been automation and improvements in software development processes. Through years of experience, I evolved from a bug hunter to bug preventer. Within my current role I am focused on ensuring that automated tests are giving right benefits to the organization. After hours, I am a happy father, husband, traveler and guitar player.

Workshop (120 min): Quick start to Rest-assured library: learn how to enhance test automation of web application with fast and reliable test suite.

When it comes to test automation of web application, most of the testers think about Selenium and front end tests. If we are using only Selenium for testing whole functionality, we might end up with enormous number of flaky tests that are hard to maintain, and last way to long. My workshop is directed to anyone interested in gaining knowledge how to write fast and reliable tests in Java using Rest-assured library. I would like to shortly explain, why it is important to limit front end tests, and ensure that critical functionality is covered without clicking trough the browser. Most of the workshop will be in the form of practical exercises with code, that will be run against a real application.

• It will be “bring your own laptop” workshop.
• Basic Java knowledge required
• Tested app will be provided via url or virtual machine.
• Skeleton of test framework and instruction how to prepare working environment will be provided on github.

Topics covered:
1. Rest assured overview.
2. Handling authentication (cookies, tokens, etc.).
3. Handling requests.
4. Handling response data.
5. Using response data in requests.
6. Using json body in requests.
7. Creating end2end scenarios.

Exact coverage will depend on group progress during workshop.

Radosław Smilgin Consultant, Trainer, testerzy.pl

BIO: Ekspert i konsultant w obszarze testowania i zapewnienia jakości oprogramowania. Jedna z najbardziej rozpoznawalnych twarzy polskiego testowania. Swoje testerskie szlify zdobywał za granicą, pracując przy budowaniu i weryfikacji systemów krytycznych pod względem bezpieczeństwa. W swojej pracy łączy dwie testerskie szkoły – testowanie formalne i eksploracyjne.
Akredytowany trener ISTQB poziomu podstawowego oraz zaawansowanego. Członek grupy przygotowującej nową wersję sylabusa ISTQB Foundation Level (planowaną na 2018). Tłumacz sylabusów ISTQB Advanced Level.
Jest pomysłodawcą i organizatorem Mistrzostw w Testowaniu Oprogramowania – TestingCup. Autor książki dla początkujących testerów – „Zawód Tester”.
Swoją wiedzą i doświadczeniem dzieli się w Internecie na portalu testerzy.pl oraz na wielu otwartych i zamkniętych wykładach w kraju i za granicą.

Presentation: Eksploracja w kulturze Agile i DevOps, czyli o zwinnym testowaniu eksploracyjnym. [POL]

Jakie są problemy współczesnych projektów? To przede wszystkim czas, którego zawsze brakuje. Czy możemy sobie pozwolić na jego marnotrawienie na pisanie i utrzymanie przypadków testowych? Oczywiście, że NIE. Musimy znaleźć inteligentniejszą formę kontrolowania jakości, której fundamentem nie będzie metryka pokrycia przypadkami testowymi, a CZAS właśnie. Podczas prezentacji pokazany zostanie trójkąt projektowy i jego analiza w kontekście użycia nowych metod testowania.

 

Sergey Pirogov Test Automation Engineer, Ciklum

I am Senior Test Automation Engineer at Ciklum Kiev (Ukraine). I am an active blogger at http://automation-remaks.com. Have big experience building test automation process from scratch. Speaker at more than 18 conferences such as SeleniumCamp, SQADay, QAFest.

Workshop (120 min): Building fast and robust test automation with Selene + Python + Travis CI + Allure 2 and Testcontainers. [ENG]

At this master class, I am going to show real examples of building test automation using Python + Selene + Docker.
This master class will be useful for engineers with different levels because I will bring and share our experience in building test automation at different projects for business domains related to enterprise and trading platforms. Newbies will have a chance to see technologies in real life, as soon as experienced guys will see how we use Travis, Docker and Allure 2.

 

 

Beren Van Daele Software Tester

I’m a software tester from Belgium who shapes teams and testers to improve on their work and their understanding of testing. I’m an organizer of BREWT: the Belgian Peer conference & a test meetup in his hometown: Gent, the creative brain behind Test Sphere and speaker at Test Bash Manchester and Eurostar 2016.

My dream is to become a test coach for people that nobody believes in anymore or no longer believe in themselves. People that have motivation and will, but no luck. I want to tap into that potential and give them the opportunity to shape a better life.

Workshop: (Re)invent your test strategy
co-speaker: Marcel Gehlen

Testing is a craft, but it is also and for many foremost a job. A job you do day in day out, evolving with all the rituals every employee develops over time. These rituals, together with all sorts of other external factors (deadlines, pressure, etc.) often means that we don’t have a test strategy or that we are no longer reconsidering the strategies we set out from the start. Having the right strategy in testing is important to stay as efficient and effective as you can be.

This workshop wants to reignite your strategic fire by placing you in small groups with your fellow testers. Together you will devise a strategy for a real life product which includes methods, tools and planning. However, just like in reality the context will change, and our strategy must change accordingly to aptly react to that change. The workshop will use the TestSphere cards as a support to spark discussions and for bolstering your strategy.


Take-aways:

  1. You will work as a team to discuss and describe a strategy to tackle a real life case and problem.
  2. You will work out a proposal to convince your manager which can involve tools, methods and planning.
  3. You will use TestSphere as a tool to uncover unknown-unknowns and strengthen your strategy.

 

Marcel Gehlen Team Lead for technical testing, MaibornWolff

BIO: Marcel Gehlen is team lead for technical testing at MaibornWolff. He started out as a developer, who always had more fun testing his code than actually writing it and therefore decided to switch careers. Marcel worked in various industries spanning from automotive to customer loyalty programs.
After almost ten years testing software his focus currently lies on test automation and exploratory testing. He currently has the pleasure of testing one of Germany’s most used mobile apps, especially the new mobile payment functionality.
Marcel tweets as @Marcel_Gehlen and occasionally blogs on http://thatsthebuffettable.blogspot.com/.

Workshop: (Re)invent your test strategy
co-speaker: Beren Van Daele

Testing is a craft, but it is also and for many foremost a job. A job you do day in day out, evolving with all the rituals every employee develops over time. These rituals, together with all sorts of other external factors (deadlines, pressure, etc.) often means that we don’t have a test strategy or that we are no longer reconsidering the strategies we set out from the start. Having the right strategy in testing is important to stay as efficient and effective as you can be.

This workshop wants to reignite your strategic fire by placing you in small groups with your fellow testers. Together you will devise a strategy for a real life product which includes methods, tools and planning. However, just like in reality the context will change, and our strategy must change accordingly to aptly react to that change. The workshop will use the TestSphere cards as a support to spark discussions and for bolstering your strategy.


Take-aways:

  1. You will work as a team to discuss and describe a strategy to tackle a real life case and problem.
  2. You will work out a proposal to convince your manager which can involve tools, methods and planning.
  3. You will use TestSphere as a tool to uncover unknown-unknowns and strengthen your strategy.

 

David Piper Front-End Developer, Atlassian

BIO: I’m a Quality Engineer turned front-end Javascript developer at Atlassian in Sydney, Australia. I’ve designed and managed CI pipelines, both backend and frontend, and I have considerable experience implementing Pact testing systems. My most recent solo project has been the development of testing libraries that make Selenium WebDriver and similar browser-based testing tools obsolete.

Presentation: A Modern Javascript Frontend CI Pipeline

The design of CI pipelines is tightly coupled with the tooling and technology stacks they test. In an ideal world, pipelines would run on rock solid infrastructure and execute fully deterministic tests, resulting in the release of a product with a guaranteed quality bar.
In reality, infrastructure, tools and tests can all be flaky, not only slowing down pipelines with needless failed executions, but also reducing confidence in the final product. Integration tests are notorious for being the flakiest of tests, primarily due to dependencies on live or mocked external services, and the use of Selenium WebDriver for UI testing.

WebDriver is not an intrinsically bad testing tool. However, tests must be carefully written to avoid race conditions, cater for unexpected Javascript side-effects, and handle backend service delays due to constrained resources in a CI environment. As pragmatists, we often tolerate occasional flaky tests in our pipelines, but left unchecked, sources of flakiness can lead to significant problems. Hourly deployments in a continuous delivery system can slip to days or weeks, and without analysis, flaky tests can quite easily be failing tests that sometimes pass, rather than successful tests that sometimes flake.

However, with the correct tooling, infrastructure and testing libraries, sources of flakiness can be eliminated completely. In this talk, I will detail a comprehensive web frontend CI pipeline built on solid infrastructure and hardened against external dependencies. Most significantly, I will demonstrate that a modern CI pipeline can eliminate the need for WebDriver completely, while still guaranteeing the same level of quality and confidence we expect from UI testing.

Tomasz Wierzchowski Software Testing Engineer, Future Processing

Inżynier z wieloletnim doświadczeniem. Od początku pełnił różne role, wszystkie związane z testowaniem oraz zapewnieniem jakości. Na przestrzeni tych paru lat pracował w wielu projektach – zarówno małych jak i dużych. Projekty te były realizowane w oparciu o różne metodyki i technologie. Posiada certyfikat ISTQB CTAL – Test Manager. Obecnie jako członek Technical Expertise w gliwickiej firmie Future Processing pomaga innym osobom oraz zespołom w rozwiązywaniu problemów związanych z testowaniem oprogramowania.

Workshop (3 h): Lepsze testy – ćwiczenia praktyczne”. [POL]
co-speaker: Daniel Dec

Zainspirowani zeszłorocznym wystąpieniem Bartka Szulca na Quality Excites chcielibyśmy pociągnąć temat ‚Lepszych testów’ i razem z uczestnikami warsztatów zastanowić się głębiej nad testami automatycznymi. Na początku warsztatów uczestnicy będą mogli zapoznać się z pewną implementacją testów. Następnie, wspólnie pomyśleć co jest dobrze rozwiązane, a co sprawia największe problemy. W końcu w praktycznych ćwiczeniach poprawić je oraz przedyskutować rozwiązania. Zaprezentowane problemy i techniki będą opierać się o xUnit test patterns oraz nasze doświadczenie zdobyte w różnych projektach. Uwaga – to nie są warsztaty z Selenium;), Poziom trudności warsztatów określamy na średnio-zaawansowany, ponieważ ćwiczenia wymagają znajomości podstaw programowania (solucja testów w C#).

 

 

Jitesh Gosai Senior Developer in Test, BBC

Jitesh has over 14 years Test experience working with a wide variety of companies from Mobile manufactures to OS builders and app developers. He is currently leading the Titan Team; the BBC Test tools and Infrastructure team, charged with building the Open-source HiveCI system which is used across the BBC to run automated test on real devices.

Presentation: Mis-Adventures in Test Automation – iPlayer Mobile [ENG]

Exploring the journey of the BBC iPlayer Mobile App team’s pursuit to move faster and better; from 2-3 releases a year to every 4 weeks getting bug fixes and new features to their millions of users. We will take a deep dive into their Test and Automation approaches.

Key Takeaways:
What does and doesn’t work with UI test automation for mobile. Tools, approaches and to get started.

Anton Angelov Quality Assurance Architect @ Innovative Lab, CEO @ Automate The Planet

BIO: I am Anton Angelov, a Quality Assurance Architect at Innovative Lab. I am passionate about automation testing and designing test harness and tools, having the best industry development practices in mind. Furthermore, I am an active blogger and the CEO of Automate The Planet. I am ardent about technologies such as C#, .NET Framework, T4, WPF, SQL Server, Selenium WebDriver, Jenkins. I won MVP status at Code Project (2016, 2017) and MVB (Most Valuable Blogger) at DZone.

Workshop: Hero’s Journey to Perfect System Tests – Eight Assessment Criteria for Tests’ Architecture Design

What is the quest of every QA Hero? It is to find the golden recipe for the perfect system tests’ design- describing how to achieve fast, reliable, easy to understand and maintain tests. Anton Angelov is going to tell you his story of how he managed to complete this quest. The journey is going to introduce common problems and mistakes to you in the process of designing test automation frameworks, such as not following single responsibility principle, not enough code reuse, and bad object-oriented programming (OOP) design. The author is going to share with you how he and his teammates managed to solve these issues through the application of eight assessment criteria. Usually, people want to improve their tests but do not have quality metrics to determine which version of their improvements is most beneficial to their projects. The presented assessment framework can help you to figure out which is the best possible enhancement that you need to introduce into your system tests and so make them more stable, reliable and maintainable. – workshop
Together with the attendees, we will evaluate three different test writing approaches. We will write tests together using the presented strategies and then use the system to assess the solutions. Though the accumulated results, we will find out which approach is the best one.