Each product company that develops new software will anyway meet certain misconceptions made by users and the community.

And if the software is not only new but conceptually new, then there will be much more misconceptions of this type.

And there are numerous myths about Allure TestOps.

Some of them are trustworthy and some of them will be debunked further in this article.

So let’s talk about 4 most popular myths.

Allure TestOps is another TMS

It’s the most popular myth.

Usually, this point of view is said by users that have not studied software thoroughly.

Allure TestOps has a common set of functions of a common TMS: test case creation, test plan management, a possibility to assign tickets to the corresponding developers/testers, test runs, and the result analysis.

All this works well with manual tests, and automation has to deal with API interfaces that can be easily used for creating basic integrations for the technologies that are used.

The truth is that this functionality is not the most important in Allure TestOps.

The principles of TestOps are built on the common base of software testing by using classic DevOps:

1. Everything that can be automated should be automated: from tests to test analysis;
2. Constant feedback. If an automated test has been changed, all changes should be written in technical documentation.
3. Transparency. Each test run should be available for every team member and also, test documentation should be thoroughly structured.

This basis that is completely implemented in Allure TestOps, helps us to plan future software testing.

Using Allure TestOps means avoiding common tools

This point of view comes as a conclusion from the first myth — if you consider Allure Ops a common TMS, you will need to use more than one test management system. But it’s not true.

Most users really move to TestOps completely, some of them continue using common tools for manual test management.

Allure TestOps is not designed for use in manual testing teams

The world of thematic software for testers is very young.

Numerous QA engineers believe that it’s expensive to purchase all useful tools.

As for Allure TestOps, we’d like to say that this software costs from $30/month for one personal account (one account — one user).

Is this expensive?

Further, we’ll try to analyze why this price is quite acceptable, by comparing it with some other popular products.

Name	RDP	Price	Release/Subscription
Allure TestOps	$30	$300	Professional
TestRail	$34	$340	TestRail 1-20 users
Qase	$36	$360	Business
PractiTest	$39	$390	Professional

 

Each team can create its own Allure TestOps

This myth is not so popular but it’s also mentioned when talking about this software.

But there is some difference – Allure TestOps is built on the basis of Allure Report, therefore, you should take the following actions to built it:

1. Find a proper type of data. A user will need to constantly work with test cases, their content, and context. Selecting a required type of data is important since it can significantly affect future development;
2. Create commons API to give stable integration of the required data. It’s very important to build it universally so that a user will be able to adjust it to test back-office protocols and their operating interaction;
3. Get used to using parallel tests since it’s impossible to run all automated tests for one flow and sprint.

Conclusion

We have analyzed all myths that we planned. At the end, we’d like to give a universal tip — in the same way as any complex system, you should select an operating platform to perform quality assurance for certain purposes and tasks.

But if your management or you directly wish to use Allure TestOps, [highlight dark=”no”]you should first test this software[/highlight] and only then – decide to use it.