Allure Server meetup: video recordings of reports

At the end of March, the Allure server meetup was held at the Wrike St. Petersburg office . In a few hours it was possible to put concentrated information on the new Allure server tool , on modern practices in working with test documentation and autotests, and on interesting experience in the interaction of Wrike testing and a new vendor in the TMS systems market.

For those who could not come, we publish videos of reports.

Anton Bashkirov (Wrike QA Lead) talked about the concept and the Allure server product itself, about how our needs for quick and cheap test documentation and centralized work with it grew together and penetrated with the ideas of the qameta.io team . I outlined our further plans for working with the Allure server.

Anton Bashkirov - Allure server: transformation of test case management in Wrike

The usual documentation process may look like this: QA Manual writes a checklist → writes test cases → gives them to automation → supports documentation as autotests change. We figured out how to simplify and reduce the cost of this chain by integrating QA and QAA into a common team flow of work, moving to a unified documentation system.

We learn to use all testing artifacts as documentation for our product, we actively use annotations of autotest code, associating them with the corresponding features in the server profile database, which allows us to work with test cases, checklists, end2end and integration tests in a single ordered ecosystem .



Ivan Varivoda (Wrike QA automation) covered the history of test quarantine, which is very important for us, which allows us to put the output from the launches, repair and return of stabilized auto tests to the stream. Again, this is a solution built first separately from the Allure server, and integrated into this system in collaboration with developers.

Ivan Varivoda - Quarantine tests or how not to go crazy with 10K selenium tests

In test automation, unfortunately, situations are not uncommon when some of the autotests temporarily stop working correctly. Perhaps these are test flasks or their performance was affected by an infrastructure problem or bug - one way or another we have to “turn off” such tests from launches or ignore them.

When a project has a small number of tests and they do not chase often - there are no special problems, but with the increase in the number of tests and daily starts it becomes extremely necessary to turn off broken tests as quickly as possible and be able to control “off” tests.



Artyom Eroshenko (qameta.io), Mikhail Levin (Wrike QA Director) with the participation of Dmitry Baev (qameta.io) together with the audience discussed the Allure server and generally views on the modern test documentation.