Miro is a collaboration tool (an online whiteboard), and it has migrated to Allure TestOps to build a fully automated testing pipeline.
At Miro, there are more than 600 people in development, and the company has a very intensive testing process. Keeping it streamlined and effective is a huge priority for them. Later on, we'll show you their journey in detail, in the meantime, watch the video interview with Zhaopeng Xuan and Balazs Galambos, Miro QA people:
If you are more into reading, below we've described some of the challenges that pushed Miro to making the change and going for Allure TestOps.
A single space for testing analytics
In the initial setup at Miro, there were separate repos for production code (written in TypeScript) and test code (in Java). Tests were run using Selenium WebDriver, and their results were simply stored in folders. An XML file was created in the process, and then an Allure Report was generated based on that XML. There was no management tool for tests and no integration with any CI/CD tool.
Right now, test code resides in the same repository as production code, it is written in the same language (TypeScript), and it uses PlayWright instead of WebDriver. The tests are run through Jenkins jobs, and those jobs populate projects in Allure TestOps. This way, all test data ends up in a single space. This makes the whole system much more controllable. To demonstrate that, let's take a look at how selective reruns are done.
Rerunning failed tests only
Previously, rerunning failed tests was a fairly complicated process: the necessary data wasn't contained in the Allure Report, and one had to extract it from another place. An important watershed in the migration to Allure TestOps was when it finally became possible to connect Jenkins to the functionality allowing reruns in Allure TestOps. After that, it became possible to select and rerun failed tests with just a few clicks of the mouse.
Huge volume of test runs
The initial approach at Miro (standalone Allure Report) lacked scalability. Right now, a total of 3000 tests are run for every pull request in the company, and there are about 400 PRs every day. This process is automated: when an engineer creates a pull request, a plugin fetches all the existing tests plus all the new tests in the PR itself. The merge into the main branch cannot happen until all those tests have passed. In other words, this is an automated quality gate that allows processing a truly stupendous amount of tests every day.
All in all, the results of the migration are best summarized by Balazs Galambos:
I have been working with ALM (HP) and other tools (like SAP) to administer test results and I can say from experience that Allure TestOps is the best from a usability perspective and also in terms of integration with CI pipelines (all others seem to be left untouched since 1990).
A new era of TestOps
Allure TestOps is more than a test management system. It's a single space for quality tools and infrastructure management across the whole software development cycle. We can't wait to see more teams joining the TestOps family!
Qameta Software is an open-source-driven company building next-gen software testing solutions for DevOps teams.
Allure TestOps Server and Cloud enable IT teams to reduce software time-to-market by 40% by providing native integrations, DevOps-friendly processes, and routine automation.
Allure Report is an open-source, flexible, lightweight, multi-language test report tool with more than 2 million active monthly users.
