Top-5 Allure TestOps myths

Every single developer team faces community myths about a product. They may sound like “Oh, you are improving THAT product!” or “Wow, that is just another product in the mix“. The number of these myths increases rapidly if the product introduces some new concepts. Allure TestOps, as such a product, has a trail of these myths and in this post, we aim to address the most common myths and break them down.

Myth 1: Allure TestOps is just one more Test Management System

This is the most common misconception. It usually comes from people who don’t want to invest any time in exploring the system or from those who are specifically looking for a Test Management System (TMS). In fact, this does make sense as Allure TestOps possesses all the functionality a TMS should have:

  • creating and managing test cases
  • QA team testing load balancing
  • test plans management
  • test runs or results analysis

These features work perfectly with manual testing in any modern TMS and there is also an API provided to allow for your own integration of testing automation frameworks.

However, Allure TestOps is a system that possesses much more than the standard functionality of a TMS, we have actually built a system that also works as a DevOps-ready quality platform that provides these additional functions:

  • Automation: Be it your tests, documentation, runs and reruns, failed or flaky tests analysis, and reporting — try to automate it. The modern development cycle is mostly automated, and manual testing bottlenecks the pipeline. Use it as the last resort.
  • Communication: As soon as a test gets modified, update the documentation and vice versa — let your test case updates go straight to automation QA to keep automation up-to-date.
  • Transparency: Testing tools are quite often built to keep the testing cycle within the QA department. TestOps allows you to share all the data about testing: versions, results, diffs, environments, and attachments.

Allure TestOps embodies these principles to let you build a future-proof testing infrastructure.

Myth 2: Allure TestOps forces migration to our tools

A logical conclusion from Myth 1. Where Allure TestOps is considered a TMS, the user may start to think that they will be forced to migrate from their existing TMS. But this is not how it works.

While most of our clients do migrate to Allure TestOps, others actually keep their good old testing tools for manual testing and use Allure TestOps as an automation management tool.

Without going into the mechanics of it all, Allure TestOps works really well with TestRail as a dedicated integration spot for automation infrastructure. It’s easier to integrate TestRail with Allure TestOps than it is to develop and maintain dozens of testing frameworks and CI system integrations.

It won’t be long before we will be implementing an out-of-the-box native integration with TestRail and other popular TMS. Watch this space!

Myth 3: Allure TestOps doesn’t fit manual QA teams

When comparing Allure TestOps to other TMS, many manual QA managers see that our product has different solutions.  For example, our dynamic tree structure for test case management substitutes “classical” folder logic (there is a whole post about why we implemented this) but these discoveries are easy to justify — Allure TestOps is an “automation first” system so some of the manual testing features are implemented in a new and “unfamiliar” way.

The reason for this is simple — in the Allure TestOps environment, manual testing becomes cognitively demanding as test planning and test case management for automation focuses on non-trivial cases and tasks. This is quite the opposite of manual running test steps in the same regression release after release.

However, Allure TestOps supports all the manual testing features of a TMS such as:

  • Test cases, test plans, and checklists management
  • Test results history and versioning
  • Automated test balancing among QA engineers
  • Flexible analytics (by an engineer, by a team, by component, or by release)
  • Automated and manual test runs and reruns
  • Two-way JIRA (and other issue trackers) integration

Consequently, this makes our solution suitable for large manual-driven testing teams.

Myth 4: Allure TestOps is expensive

The QA-tooling market is still evolving. About 41% of testers and QA Engineers don’t use any specific tools to manage test cases, and only 20% use special test management tools (source).

Many of these people and their managers still don’t see any reason to spend money on QA tooling. With a $30 user/month pricing Allure TestOps is sometimes considered as “expensive” software.

Myth 1 may have an impact on this belief, people compare the Allure TestOps price to other TMS and some of them look less expensive but it may be that the entirety of our product is not fully understood.

We have gathered the most popular products compared to Allure in this short spreadsheet:

We took a median of a 10-license trial query to make this comparison. * Zephyr Scale Server pricing has been calculated for 25 JIRA-users team on the assumption of 40% of the engineering team is testers (the lower the rate, the higher is RRP).

As you can see, the price is about the same. The truth is Allure TestOps has something more to offer for the price: a fully integrated native test automation management. So the same functionality requires adding automation integration development and maintenance costs, or standalone tools like Katalon Runtime Engine / Studio.

Moreover, since Allure TestOps pushes enterprise-verified process improvements, it leads to cost reduction in the long run. Usually, our clients benefit in two fields: HR and testing infrastructure costs optimization.

Myth 5: Allure TestOps is a Russian software

Data Security is in priority!

While there are dozens of the US/EU clients in the Allure TestOps portfolio, we hear business concerns regarding the Russian origin of Qameta Software from time to time. These are good questions as working with Russian software companies may cause various legal (GDPR or CCPA related) and security (data storing and protecting) issues to European or US companies. But in fact, there is no reason to worry about that. Here’s why:

  • We do not store any personal data. At the moment Allure TestOps is deployed as an on-premises solution, which means we don’t access any data processed by TestOps users. Moreover, Allure TestOps faces enterprise-level security standards such as SAML, SSO, and JWT. For an upcoming cloud solution, all contractors are checked for compliance with the US/EU legal requirements.
  • We are an international OSS developer. Allure Framework is contributed to from all over the world. Thousands of companies run over 17 million test suites each month with our technology, including companies such as Apple, Netflix Disney, and others.
  • European legal entity. In case you are worried about any restrictions on working with Russian companies caused by the current geopolitical environment, don’t be. We are an officially registered transparent European company.
  • The Development Center of Qameta is based in Russia. Well, that’s simple: it is an extremely cost-effective business solution that lets investing more in future development while saving the roots and engineering culture of the core team that comes from Saint-Petersburg.

Allure TestOps helps to build next-gen testing for more than 50 enterprise-level clients from Europe and the USA. If you have any questions regarding this myth, feel free to contact us.

Conclusion

These are a few of the myths surrounding our product but ultimately there is just one piece of advice:

Choosing a software quality platform should be a balanced decision focused on your company’s tasks, tools, and goals. Try, search, test, and analyze!

If you are looking for a DevOps-ready Testing Platform, don’t fall for myths — contact us for a 30-day free trial that includes premium support. We’ll help you install, set up, migrate and tune test processes with Allure TestOps.

Share this article

Subscribe to the blog

Menu