
Heisenbug 2017 Piter: Call for Testing

Let's see what awaits you on the spot.

Given the opinions of the participants of the Heisenbag 2016 Moscow, we succumbed to the heat and increased the number of technically complex, deep and unusual reports. For your convenience, we have screwed an indication of hardcore to each report so that you know exactly where the RPGs are distributed and where - a master class on mount mounting. For those who cannot get to Peter, we do an online broadcast with the ability to ask “questions from the audience” during the reports and watch interviews with speakers in between sessions.
So, a review of reports grouped by topic:
Testing Approaches and the Right Patterns

The ability to apply patterns is one of the basic skills of a professional. Knowing the approaches allows us to solve problems at a high level of abstraction and to prevent "children's" errors. That is why we have the first place with approaches and good practices with 8 reports:

As we all know, people involved in testing have long since resolved all the problems in this area. If we still encounter bugs, it’s only because of the laziness of the engineers: existing methods and technologies, if applied correctly, can completely solve all problems. And finally, security bugs are just bugs, therefore, security testing for lazy engineers is also a solved problem.
In this talk, Claudio will try to debunk this blatant lie, drawing on some of the lessons he learned while dealing with security testing in an uncomfortable large infrastructure. After he demonstrates that among testing practices, security testing is a full citizen, not a strange alien, he will present his travel notes on creating security testing tools on Google.
Attention, spoiler: there will be no moments in the Hollywood style like “root-shell-and-galloped-in-sunset” -
scalable security testing is a trench warfare, not a walk in the park. For the effect of surprise, Claudio, among other things, will talk about things that didn’t work at all, and also about things that didn’t work at all, because failure in places is even more interesting than victory.
If you care about security “in the trenches”, want to know about the little things that can undermine the initiative, or worry about software or infrastructures for security testing, then you should find this report interesting.

Design patterns have been known in development for many years. Some developers love them, others find it useless. At the same time, design patterns have very clear tasks: to describe typical solutions to common problems, create a common language for the community, improve understanding and reuse of existing approaches.
Since test automation has its own set of tasks, there is also its own set of useful design patterns for this area. In the report, Nikolai will go through all the known patterns and describe them in detail with a few practical examples.

Management of companies is trying to make decisions not on a hunch, but on the basis of numbers and objective data. How to test the operation of software that considers these numbers? If the code, after processing the company's data for the year, shows 42% - is this the correct answer, or is there an error, and we should have received 43%? Based on the practices developed in the Toptal analytics department, I would like to answer these questions. BI, ETL, DWH, ML ... If you know what these abbreviations mean - come talk about testing in the data world.

Systems can be tested in many ways. Most organizations, teams of testers and individual specialists use in their projects only one or a couple of approaches, even if they are not optimal in each case. This report aims to correct the situation.
To begin with, let us outline the difference between scripted and exploratory testing, and then go through the entire palette of methods in the space from scripted to exploratory, including: detailed scripting, global scripting, session based testing, bug hunts, test tours and freestyle exploratory testing, having experienced both the essence of each approach and the situation in which it is most applicable. Among other things, Jan Jaap will explain how automated testing can be associated with any of these types.
The last part of the presentation will be devoted to practical examples and a checklist to help determine which type of testing is optimal for your project.

This report presents the findings of more than a decade of thinking and observing what makes the tester a world-class specialist. It's about what YOU can do to get more skills, more job satisfaction and more attractiveness for world-class companies you respect.
At this session, we will not break away from reality and discuss specific steps and ideas that you can implement immediately. You will also hear real stories about testers and how they completed these steps. You will be able to choose some of the proposed ideas and begin to implement them today.
This report is not about complaining, but about specific actions that will help you become the best version of yourself.

write UI autotests in different ways. What techniques should be used by a professional developer, and which are better to bypass? Where is the pain in modern automated testing? Alexei will demonstrate his position with illustrative examples. Let's start with simple code and consistently apply popular design patterns to it, such as: PageFactory, LoadableComponents, Single Responsibility Principle and others.

In their talk, two girls - Java autotest developers - will compete against each other in the Mortal Kombat style to show which of the two tools, Cucumber or JBehave, has the most restrictions. They will choose the worst tool. And for what?

You can find out about the possibilities by going to the library documentation or watching reports where the speaker praises the tool he has already selected. But he will be able to find out what exactly lies in wait for the developer when choosing Cucumber or JBehave, only if he “rustles” the entire Stack Overflow or tries the library himself. This report will help you avoid rewriting the old autotest framework to a new one simply because one day someone chose the wrong tool.

Automator Problems Automation is one of the most important patterns used by senior-level specialists. Test automation is not just about writing WebDriver tests. This is, first of all, the solution of regularly arising problems and optimization of repetitive labor.
In order to write high-quality, supported tests and utilities for testing, many additional costs are required - http-clients, organization of checks, description of the project with tests, documentation support, ... (this list is much longer!)
In this report, Cyril will talk about how you can automate code writing that eases the burden of supporting additional code for tests; what ready-made tools and mechanisms exist in the Java ecosystem and what his team uses to turn a dozen lines of declarative description into hundreds of lines of code that you can simply take and use.
Web project testing

It is obvious that the widespread use of the Internet is not only an existing reality, but also a powerful and continuing trend. Therefore, at the Heisenbag 2017 Piter, a separate block of reports is devoted to testing web-projects.

We "fire" a demo web-service on Python Tornado, which is specially written so that performance problems appear. Aleksey will show how resource stress reports, heavy cron job, poor algorithms and heavy database queries appear in stress test reports. We will draw conclusions, correct bottlenecks and compare the performance of the “before” and “after” services.

When creating Selenium tests for modern web applications, it is often difficult to find elements on the page or wait for the moment when the view is updated after receiving a response from the server. If the application is written in Angular, then the Protractor framework is designed to help with this, but the scripts will have to be written in JavaScript. In this report, we will consider the surprises that this language can present, and try to figure out if we really need Protractor, or we can do without it.

In testing various web projects, sooner or later there is a desire to replace data for the front-end. Sometimes a task grows out of the needs of manual testing, sometimes - out of the needs of autotests, sometimes - out of the needs of frontend developers themselves. The report will tell you about the range of tasks that can be solved by convenient data substitution, which improves and speeds up the development cycle. Let's talk about various implementations, and how we found our ideal - we made data modification not just an engineering opportunity, but a tool that all team members use daily. From and to: why replace data, what approaches exist, implementation features of various components, and how this ultimately changes the project.
Testing frameworks and tools

Just as the right combat tactics makes the battle easier for you and actually predetermines its outcome, the correctly selected framework speeds up and simplifies development. We select the best of the new tools and invite their maintainers to the conference so that in one day you can understand and evaluate which new products will best contribute to solving your problems.

reports of a new generation Every person who encounters automated testing has to disassemble the test results. The larger your project, the more reports you have to look through. The world does not stand still, the release cycle is accelerating, some products manage to be released several times a week, and some several times a day.
Allure Framework is a popular auto-test reporting tool that simplifies their analysis. In the report, Artem will talk about the new version of Allure 2. A lot of new things appeared in it: the environment, restarts and test history, display of fixtures, error categories and much more. One of the key features is the ability to adapt Allure for themselves using a plug-in system.

A lot of water has flowed over the past decade in the world of Java and testing - so JUnit 4 goes into oblivion. He was replaced by JUnit 5, designed to focus the future of JVM testing on the capabilities and extensibility of Java 8, as well as on a modern API for testing. In addition, JUnit will no longer be a framework exclusively for Java testing. Third-party companies are in full swing developing test engines for Scala, Groovy, Kotlin, etc., which will work on the new JUnit platform.
At the beginning of this report, we will look at a real-life example of a new programming paradigm for Jupiter and learn how to migrate 4 tests available on JUnit. Then we will analyze the main idea of JUnit 5, take a look at its architecture and discuss compatibility with JUnit 4. Next, we will study the Jupiter extension model, their implementation possibilities and see how user extensions are created and registered to test conditions, method parameter permissions, lifecycle callbacks etc. In conclusion, we look at the roadmap: what else is in development and when to expect GA.

Over the past 5 years, Appium has become the de facto standard for automating mobile applications. More recently, support for many other platforms has been added to Appium: from Windows and Mac apps to TV apps. In a world where most products support multiple platforms and devices, it becomes absolutely essential that you do not need to learn a new framework every time you need to automate a new device. Just as a composer uses the same musical notation for all instruments, an Appium developer can write scripts for all devices in his orchestra using one protocol.
This report details the latest members of the Appium family of products - Appium for Mac and Windows, and discusses the future of Appium as a language and automation protocol.

As you know, "with great strength comes great responsibility." C ++ is a language with great expressive power and huge capabilities. You have to pay for these features with potential defects that are not available in programs in managed languages.
Sanitizers are wonderful tools that allow you to find complex defects in C ++ programs. Andrei will talk about these tools, their capabilities and how to use them with benefit for his project.

When Apple abandoned UI Automator last year with the release of Xcode 8, Alexey’s team, like many, was left with nothing. Appium, which they used, lost relevance, they began to look for alternatives and found the WebDriverAgent tool from Facebook. A report on what problems they encountered, how they were solved, and how this affected their testing infrastructure for iOS applications.

What if you are told that you can write tests in Kotlin? Never heard of him? If you use Java, there are reasons why Kotlin might become the language of your tests. No panic, Kotlin is easy. Leonid will tell you how the features of the language allow you to spend less time supporting the tests. How much code is becoming more concise. And why your favorite libraries and frameworks (for example, JUnit, HtmlELements, Allure) will stay with you. And, of course, the most important thing: where to start. Where possible, a comparison will be made with Java and Groovy. If you are testing or developing in Java / Groovy - this report is for you.
As you can see with the naked eye, the conference promises to be “fire” - the coolest experts, technologies at the forefront, battles on the stage and, of course, our signature chip - discussion zones, where each speaker goes after the report for behind-the-scenes communication with participants on any topical issues.
In general, dear comrades, see you at the location or online! You can find out more details and purchase tickets on the conference website: heisenbug-piter.ru