Technical support
This article describes standard technical support services available for end users of Allure TestOps. These services cover both server deployments and cloud Allure TestOps instances.
Scope of the standard support services
Allure TestOps standard support is included in license fees and detailed in the General Terms and Conditions under items 1.3 and 1.4. This support covers both cloud and server instances, offering the following services:
- Access to Allure TestOps documentation available on this documentation website.
- Access to pre-recorded demo sessions.
- Access to our support team's knowledge base on the Allure TestOps Help Desk portal.
- Ability to register bugs via the Allure TestOps Help Desk portal.
- Delivery of bug fixes as either hotfix releases or within new releases during the active paid license period for both cloud and server deployments. The method of delivery depends on the priority of the bug.
- Introduction and delivery of new features in upcoming releases according to the product development plan.
Limitations of the support services
The Allure TestOps support team focuses exclusively on providing recommendations directly related to Allure TestOps. We are unable to offer support or advice concerning third-party software. All recommendations on the settings, usage, and performance of third-party solutions are limited to those described in our documentation, but support of such solutions is outside our scope.
We do not advise on the selection and usage of the client's infrastructure unless it is explicitly described in our documentation and relates to supporting solutions required for Allure TestOps normal operations.
Our support team does not and cannot handle troubleshooting of the client's infrastructure. This responsibility remains with the client.
Topics not included into the standard support offering
The following services are not included in the standard support package:
- Code review, troubleshooting, or debugging of any automated tests.
- Consulting on the usage of the Allure Framework, including debugging and code review. The Allure Framework is an open-source project supported by its community and contributors with discussions and documentation.
- Code review, troubleshooting, and debugging of any CI pipelines.
- Consulting related to the deployment of third-party solutions such as RabbitMQ, PostgreSQL, Redis, JVM, etc. Allure TestOps documentation includes information on recommended versions and links to third-party documentation, but we do not provide support for these solutions.
- Maintenance for server deployments of third-party solutions. However, we offer best practice recommendations for tuning solutions like the PostgreSQL database to enhance performance.
- Consulting on the organization and transformation of manual or automated testing within a QA team, or best practices in the QA domain.
Help Desk portal
Qameta Software Inc. offers a dedicated support portal for Allure TestOps users available at https://help.qameta.io.
Registration on the portal is required for Allure TestOps end users seeking assistance.
We recommend that end users of Allure TestOps use their work email addresses for Help Desk portal. Using public email addresses prevents us from identifying the company that owns the license or subscription, which could compromise the security of sensitive information, potentially allowing access by third parties when using public emails services, and our goal and contractual obligation is to prevent that.
Registration on the Help Desk portal
To create an account on the support portal:
- Go to https://help.qameta.io.
- In the upper-right corner, click Sign up.
- Add your name.
- Add your corporate email address.
- Pass the CAPTCHA test.
- Verify your email address by clicking the link from the email sent by the Help Desk portal.
- Set your password.
Working hours
The technical support business hours are from 08:00 to 18:00 UTC. Requests registered on the Help Desk portal outside the business hours will be processed when the working day of the first available agent starts.
There is no support during weekends, nighttime and holidays.
Access to the requests created by your organization
In case you would like to see the requests created by your colleagues, please create the Low priority support request and we'll configure the visibility of the company's requests for you.
Types of requests
The support team processes the following types of requests:
Questions
Questions are intended for brief client interactions and aim to solve a specific issue without further iterations. It does not include log analysis or any kind of troubleshooting.
Requests demanding actions beyond providing an answer will be converted into Support requests.
These requests cannot be assigned high priority.
Support requests
Purpose
Support requests are used by clients seeking solutions to existing problems. They usually involve several iterations, gathering details from the client and providing resolutions for Allure TestOps issues. This includes improving Allure TestOps performance, resolving unexpected application behavior, clarifying deployment matters, and addressing integration problems with third-party solutions such as IdP, CI, TMS, and issue trackers.
Prerequisites
Before submitting a support request, make sure you completed all self-help steps and reviewed any relevant recommendations or knowledge-base articles.
For troubleshooting guidance, first visit our documentation and knowledge base, where you’ll find online guides, videos, and other resources.
Prior to submitting a related request, consult the team responsible for your infrastructure or third-party solutions to rule out issues on your end.
If the problem is related to the Allure TestOps deployment, work with your infrastructure team to make sure that:
- dedicated resources (RAM, CPU) are sufficient;
- network connection is stable;
- adequate storage space is available (both general capacity and nodes).
Request priority
When creating a request, clients can indicate the desired priority. However, the final priority will be based on the issue’s impact on client processes and set by a support agent. We reserve the right to determine the request’s priority using the information provided and our analysis.
Required details
Please include as much information about the issue as possible:
- Detailed description of the symptoms and how they are affecting the end users.
- Why you believe this behavior is incorrect.
- Any changes or events that occurred before the issue appeared.
- Actions you have already taken.
- Information from your infrastructure team (if applicable).
- Allure TestOps full logs as separate .txt files. Do not send partial logs, as they may be irrelevant to the issue you are facing. Do not send screenshots of logs, as they cannot be used for the analysis.
- Details of the most recent commands used (if related to deployment). Use the
history
command and provide its output as a text file rather than screenshots. Include all terminal errors encountered when running these commands.
Bug reports
Purpose
Use the Bug request type to report application behavior that does not match the documentation. Any other issues should be submitted as a Question or Support request and investigated by a support agent first. After review, valid bug reports will be moved to the Bug queue for resolution by the product team.
Preconditions
We continually improve the application by fixing errors reported by clients, trial users, and our QA team. New versions of Allure TestOps include these bug fixes.
Only issues present in the most recent product release (including the latest hotfix release) can be accepted as bugs. If you are using an earlier version of Allure TestOps, please review the release notes for fixed bugs, then upgrade to the latest version and check if the behavior persists.
Request priority
When creating a Bug report, clients may indicate a preferred priority. However, the final priority will be determined by a support agent based on the issue’s impact on the client’s processes. We reserve the right to set the priority according to the information provided and our analysis.
Required details
To help us resolve the bug more quickly, please include the following information:
- Description of the issue.
- Expected behavior.
- Actual behavior observed.
- Steps to reproduce the issue.
- Logs and any other relevant evidence.
- Allure TestOps full logs as separate .txt files. Do not send partial logs, as they may be irrelevant to the issue you are facing. Do not send screenshots of logs, as they cannot be used for the analysis.
- Details of the most recent commands used (if related to deployment). Use the
history
command and provide its output as a text file rather than screenshots. Include all terminal errors encountered when running these commands.
Bug fixes
The timeline for fixing a bug depends on how much it affects the client’s ability to use the application as intended.
The highest-priority bug reports with no available workaround are processed and delivered as a hotfix release to the most recent product release and include:
- errors preventing Allure TestOps from starting;
- errors stopping end users from signing in;
- errors that contradict the documentation and prevent the system from being used as designed.
If the issue can be resolved by a different approach, tool, or workflow, it does not qualify for highest priority.
Before reporting:
- check all prerequisites for reporting a bug;
- review the Allure TestOps logs for descriptive error messages indicating the faulty component.
Feature requests
Purpose
We welcome your suggestions for new features, feedback on existing functionality and ideas to improve Allure TestOps. A Feature request captures your needs and helps our product team understand your requirements.
Limitations
Please note that submitting a Feature request does not guarantee implementation, prioritization or response within a set timeframe. Feature requests serve as guidance for our product roadmap, which may not always align with every suggestion. We reserve the right not to implement or respond to each proposal.
Required details
To help our product team evaluate your idea, please include:
- Context: Describe the task or problem you need to solve.
- Proposed Solution: Explain the feature or change you would like to see.
- Alternatives Considered: Outline any other approaches you tried or considered.
Supporting materials, such as process descriptions, screenshots or references, are appreciated and will help clarify your request.
Implementation of Feature requests
While we value all feedback, our internal roadmap dictates which features are developed. As such, not every proposal will be implemented or receive a direct response.
How to submit Feature requests, suggestions, and feedback
These sections are available only to registered users of the Help Desk portal. To access them, please create an account.
The direct channel to the product team is the Forum section of the support portal. You can post Feature requests and suggestions in the dedicated stream.
For guidance on creating an effective suggestion, please read this topic.
Security related requests
Security related requests are used to inform the Allure TestOps team about:
- found vulnerabilities,
- security threats like compromising the end users' data.
Any other requests must be submitted as Support requests.
Migration from third-party TMSs
Purpose
This type of request is intended to assist teams transferring their manual test cases from third-party Test Management Systems. Our migration tool can migrate the test cases, scenarios, attributes of the test cases, and attachments to Allure TestOps.
Limitations
When migrating test cases from a third-party TMS to Allure TestOps you need to consider the following:
- There is no need to transfer automated test cases, as they are automatically created by Allure TestOps when you close a launch containing test results from automated tests.
- It is not possible to transfer historical test case data such as previous test runs.
Request details
To create a request for data migration:
- Check the list of supported source TMSs. This page also contains the instructions on the migration tool usage.
- If your TMS is in the list of supported source TMSs:
- Go to https://help.qameta.io.
- Sign in to your account or create a new one.
- Create a request with the type Migration from other TMS, Medium priority, and the subject Migration from TMS_NAME.
- The support team will supply you with the information on the most recent migration tool.
- If your currently used TMS is not supported by our migration tool:
- Go to https://help.qameta.io.
- Sign in to your account or create a new one.
- Proceed to forum pages.
- Create a new topic with the subject Support TMS TMS_NAME in migration tool.
The product team may contact you to ask additional questions.
We'll inform you if the migration is possible.
If any sensitive information will be required to enhance the migration tool, we'll create a support request and continue communications in the scope of the created request.
Request priority
Request priority describes how much an issue affects the end user’s business operations or overall experience. It assesses the problem’s severity and its potential to cause significant disruption. For example, a critical system outage affecting many users could lead to substantial productivity losses and downtime.
We categorise requests as follows:
Urgent
A large number of customers are affected because a service, product, or major feature is unavailable, or a single customer is experiencing a critical production outage. No viable temporary solution or workaround exists. Also applied for Security related requests.
High
These issues impact a moderate number of customers. They are reproducible and have a short-term workaround but cannot be sustained in the long term.
Medium
The issue causes minimal operational impact.
Low
Usually applicable to Questions, Feature requests, and Support requests not affecting the end users.
First response
First response is the initial communication from a support engineer, confirming that they received and reviewed a support request or in-product chat. This response may or may not include the final resolution of the issue.
First response definition
First response is the first non-automated answer from the support team with an attempt to resolve the issue or with further clarifications in order to resolve the issue of an end user.
First response SLA
Our target is to provide first response within the first 8 working hours from the moment the support request was created at https://help.qameta.io.
Based on our stats, the first response time is much shorter than 8 working hours.
Allure Framework support
The support of Allure Report / Allure Framework is done by contributors and community via GitHub Discussions and is not included in the scope of the Allure TestOps technical support services.