TestOps logo
Try TestOps

SaaS

You can use Allure TestOps not only as a system deployed in your data center (or deployed at your cloud provider), but also as a SaaS solution (the cloud version of Allure TestOps).

You can try the solution before buying the commercial subscription. To request the creation of your trial instance of the cloud version of Allure TestOps, you need to proceed to the following address: https://qameta.io/cloud-trial-request/ and fill out the instance creation form with the following data:

  • your name;
  • work email;

Please consider providing a work email, and preferably – a shared mailbox, or an email of a service account accessible by several people, not a personal one. This will release you from the necessity to restore the access to the instance in case person created the instance left your team.

  • company name;
  • expected users; The number of users can be altered as soon as you are ready to use Allure TestOps on a commercial basis.
  • domain name, for example, https://yourdomain.testops.cloud. Please try to avoid domain names like test, testtest, qwerty etc.

After you requested the creation of the instance, our system will create the instance for you and send the email with the credentials for accessing the administrator account (the first administrator of the instance). The provided credentials must be kept in a secure place.

Trial conditions

  • Trial is provided for 14 days.
  • If you haven't provided any payment means after the day 14:
    • Instance becomes read only.
    • Only users with administrator permissions will be able to perform actions including the operations related to the payment.
    • All other users will become Guests and will be able to see the UI, but they won't be able to perform any actions in your instance.
  • Next 7 days, the payment gate will perform 3 attempts to charge your bank card (if provided).
  • If there is no bank card details provided or the funds on the bank card aren't sufficient o pay for the service, or card details are wrong, then after the day 7 your instance will be deactivated (suspended), and you won't have the access to the UI.
  • If you decide to use and pay for the service, then during next 14 days period the instance can be revived.
  • After the day 14 after the deactivation, the instance is completely deleted with no option to revive and restore the data.

Payment, number of users, payment terms

To add payment details:

  • Sign in using the first administrator credentials.
  • Go to Administration → License → Manage Subscription.
  • You will be redirected to the payment gateway (Stripe).

In the payment gate UI, you need to update your plan:

  • Select between monthly/annual subscription. Annual subscription will grant you instant 10% discount
  • Select the number of seats (quantity) you need to have for your team. There are Guest accounts, that are not billable, you don't need to consider these in payment gate settings.

If during the usage you need to increase the number of paid seats:

  • You can return to the payment gate.
  • You can update the number of seats.
  • Payment gate will recalculate the payment required and charge your card accordingly.

Save the changes by clicking on Continue button.

Stripe will recalculate charges and update the number of seats available in your instance.

Cloud instance limitations

Dedicated storage for the artefacts

The storage dedicated to each instance to store the test cases artefacts (attachments) and test results artefacts (attachments) is 60 Gbytes per Allure TestOps instance.

To respect the storage limit the end users can create cleanup rules to delete old artefacts (check also our recommendations on the configuration for the cleanup rules). Cleanup rules only delete the artefacts from the test results, the attachments to test cases aren't cleaned up.

In case current storage exceeds the quota, the end users will be notified about this fact.

This limit cannot be changed for a SaaS instance at this moment.

The upload body size limit

When uploading artefacts to test result the end users need to consider the limit on the upload body size limit which is 100 Mbytes. This limitation means that if the group of files selected for the upload by allurectl or a plugin for a CI system (e.g. Jenkins) would exceed 100 Mbytes, such upload will be rejected, and some test results and/or attachments might be missing due to this rejection.

The symptoms of the event when upload body size exceeds the limit of 100 Mbytes looks in the pipelines like follows:

[ERROR] Failed to upload batch (123456). Reason: failed sending upload request: sess: 98765, err: POST : 0

In case on allurectl side you have debug enabled, then the error might look like this:

[ERROR] Failed to upload batch (12345). Reason: failed sending upload request: sess: 7654, err: POST : 0 <html>
<head><title>502 Bad Gateway</title></head>
<body>
<center><h1>502 Bad Gateway</h1></center>
<hr><center>cloudflare</center>
</body>
</html>

In this case you need to check if you are sending big files, and change the size (number of files in upload batch) of the parameters used in allurectl (see allurectl watch --help for the reference).

This limit cannot be changed for a SaaS instance.

Test result file maximum size

The maximum allowed test result file size is 2,000,000 bytes. The files that exceed this size are considered as attachments by the logic of the application, and eventually are deleted after the closure of a launch. In this case the test result itself and all associated attachments will be missing in the created launch.

This limit cannot be changed for a SaaS instance.

© Qameta Software Inc. All rights reserved.