At the end of March, the Allure server meetup was held in the St. Petersburg office of Wrike. In a few hours, it was possible to put the concentrated information on the new Allure server tool, on the modern practices of working with test documentation and autotests and on the interesting experience of the interaction between testing Wrike and the new vendor on the TMS systems market.
For those who could not come, we will publish video reports. Anton Bashkirov (Wrike QA Lead) spoke about the concept and the product of the Allure server itself, about how our needs for fast and cheap test documentation and centralized work with it grew together and mutually penetrated with the ideas of the qameta.io team. Outlined our further plans for working with the Allure server. ')
Anton Bashkirov - Allure server: transformation of test case management in Wrike
The usual documenting process may look like this: QA Manual writes a check list → lists test cases → gives them to automate → supports documentation as autotests change. We figured out how to simplify and reduce the price of this chain, thanks to embedding QA and QAA into the overall team flow of work, moving to a single documentation system.
We learn to use all testing artifacts as documentation about our product, we actively use the autotest code annotations, linking them with the corresponding features in the server's gait base, which allows us to work with test cases, checklists, end2end and integration tests in a single ordered ecosystem .
Ivan Varivoda (Wrike QA automation) highlighted a very important for us the history of the test quarantine, which allows you to stream output from launches, repair and return of stabilized autotests. Again, this solution, built first separately from the Allure server, and integrated into this system in collaboration with the 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 autotests temporarily stop working correctly. Perhaps these are test flags or their infrastructural problem or bug has affected their performance - one way or another we have to “turn off” such tests from the launches or ignore them.
When there are a small number of tests in a project and they don’t chase often - there are no special problems, but with an increase in the number of tests and daily launches, it becomes imperative to turn off the broken tests as quickly as possible and be able to control the “turned off” tests.
Artem Eroshenko (qameta.io), Mikhail Levin (Wrike QA Director) with the participation of Dmitry Baev (qameta.io) and the audience discussed the Allure server and, in general, views on modern test documentation.