Have you ever wondered: why do we have to invent the wheel again and again in software test automation? In this presentation I am going to present you 7 lessons that can be applied from the ancient art of house building to test automation. Of course: building a house is something completely different than setting up a Test Automation framework. But by using these 7 common practices, you can avoid some leg-breaking pitfalls. Register for this topic and enjoy!

In this topic we are going to share how to build an automation framework which can be used by everyone. Main technologies behind it are java / cucumber / testNG. ISTA participants will see main principles building an automation framework in a way any QA will be able to learn / use and contribute. On top of that any non technical person will be able to consume and write UI tests. There will be examples from a client we have been working with since 2016 – adidas HQ. Part of our presentation will be devoted to the automation growth knowledge within the project – scaling from 3 automation engineers to 50+ for the period of 6 months.

Cypress is a relatively new JavaScript testing framework that seems to be targeting a lot of the typical pain points when it comes to all types of web related testing, especially end-to-end. In this talk you will receive a general overview of the technology with its quirks and strong suits.

Imagine “to run”. You probably see in your mind yourself running, or an athlete crossing the finish line, or a cheetah chasing a gazelle. We are object oriented – we perceive and consume the world through the objects in it. We need an object to show an action. Our perception of the world is built on objects that we can interact with – touch, see, export,… and that have properties – large, blue, nice,… . We are so object-oriented, that we objectify even abstract notions – liberty is a woman waving a flag or holding a torch, and democracy can be built or ruined.

Three basic needs form the backbone of this objectivity: orientation, consistency and organization. It is beneficial to understand the principle of object-orientedness and the basic needs and apply them in your work. This object-oriented approach to analysis and design breaks down the problem space into objects, their attributes, the relations among the objects and the actions that can be performed with these objects.

You will:
Understand the concept of object-orientedness, which is successfully used by programming, design, and documentation;
Take a different look at the way you think about content and places;
See various examples that illustrate the three basic human needs in a place;
Change the way you design, test, and deliver.

Have you ever worked with a large and complex codebase, limited automated test coverage, lengthening release cycles, and the danger of accumulating technical debt? It can be difficult to know where to begin, particularly when you have competing demands to spend time delivering new functionality. Two years ago our team realised we needed to modernize the architecture of one of our products, which would eventually involving refactoring the several hundred-thousand line codebase from a monolithic architecture to a distributed micro-service based deployment. In this talk I’ll share how we used test automation techniques to drive this transformation, and share lessons learnt as we redesigned both our software architecture and our development processes – allowing us to move from quarterly release cycles to a continuous delivery model.

“Modern software development methodologies and approaches help to increase delivery speed while still caring about software quality. However, if we think about manual regression tests, they are not only time consuming and repeatable, but also feedback time is quite high. These are the reasons why regression tests are often automated.

Automated tests can provide results faster and it’s possible to execute them more frequently than manual ones. They can decrease the overall time needed for tests, but what’s probably even more important, they allow to test and receive feedback earlier in the development process. It’s essential if we want to release and deliver business value faster and more frequently.

But what if we have more and more tests and even automated execution of them takes too much time – 10 minutes… 30 minutes… maybe even hours? Should we consider the ability to execute full tests set just a few times a day as something normal? Is adding more compute resources the only option to reduce the execution time? Or maybe there are too many high-level tests and some of them should be replaced by low-level ones according to the Test Pyramid? Is the Test Pyramid still valid in the cloud world?

During the presentation, you will see how the serverless cloud services like AWS Lambda may be used to run tests in the highly parallelized environment that can speed up test execution even hundreds of times.”