Everyone wants to produce quality software. To do this, companies hire testers. But sometimes testers are unable to influence quality due to some limitations. They can't write good autotests, build a locator to push a button, don't know where to get test data. I hold the view that quality needs to be built into the developers themselves, into the processes, into the software.

In this talk, I want to tell you about how to improve quality and make the software more testable, how you can increase the efficiency of the tester's work and remove a number of limitations.

Why should testers go to the talk: 

• You will learn how you can change the way of things and make your work more comfortable. 
• You will learn what you can demand from development to make your autotests easier to write and without kludge. 

Why do you need to show the talk to developers: 

Do you have enough test reports? 

Would you like to have on one screen? 

• Real-time test results 
• Slices by the environment, browsers, device types, features, commands and whatever
• Test execution time
• The regularity of test execution during the day
• Test coverage of pages and actions on pages
• Infrastructure operability
• Release results  

Do you want to have test results in front of your developers' eyes? 

In this talk, I will explain how we at Ozon use Grafana to visualize test results.

Every day on the Ozon.ru website, more than 3 million visitors choose from 6 million products, make more than 200 thousand orders. At the same time, having a relatively small staff of testing specialists, we work every day to improve the customer experience. We make 10 site updates a day. Release time is 20-25 minutes. 

In this talk I will tell you how we put the testing of the site in 5 minutes and at the same time did not lose in coverage and quality. For the listeners, I will give step-by-step instructions on how to come to this. I'll tell you about the difficulties that were on the way of improvement.

Well delivered automated testing provides a great opportunity. But most of the reports and testers at the conference are manual-typel. Some developers in general are skeptical about testing. If the project has automated testing but somehow through the UI, when tests work long and unstable. Developing automated testing on a project is not easy. It is easier when there are guidelines. So I have a reference to a set of principles and rules that formed over the years. In this short report I will try to describe a number of problems and try to provoke the audience to build at an effective automation testing.