Tricentis / qTest.Integration.Pulse

MIT License
12 stars 12 forks source link

qTest Pulse Community Marketplace

Platform: qTest Pulse Codebase: node.js License: MIT

Repository of open-source qTest Pulse rules powered by the community. What is qTest Pulse?

How It Works

Example Workflow Overviews

Getting Started

For a BDD workflow, please review the Pulse documentation for examples of how to set up a workflow and use Constants. Please bear in mind that the stock rules in the Pulse v9.1 repository mentioned by the Pulse documentation are NOT compatible with the rules in this repository due to updated standards and nomenclatures.

For a webinar that features a live demonstration of the above workflow, please go here.

Identify Your Workflow

It's a good idea to sit down and map out your workflow on a whiteboard. You will want to accmplish the following steps:

Begin Your Workflow

In a true agile environment with a CI/CD or DevOps workflow, most likely you will be triggering your builds with some sort of repository action, whether this be a simple push/commit with a smaller development environment, or an approval or merge for larger organizations. Most Repositories (Github, Bitbucket, Gitlab, etc) maintain a feature that will allow the call of a webhook when one or more of these actions occur. Sometimes there will be a native integration to kick off the CI/CD pipeline, but when there is not, Pulse can take charge and kick off your CI/CD pipeline via an API call. In this case you will want to look in the CI Tool Integrations for Actions that kick off CI/CD pipelines. In Pulse, set up a Trigger (webhook) and an Action (script) and create a Rule to link the two. Look for the Constants needed in the documentation block of the Action script and fill them in as needed in Pulse.

Deliver and Parse Testing Tool or Framework Results

This is key to picking out or developing your own parser. The output of the parser creates a standardized construct that is consumable by a qTest Manager API. In order to leverage a parser, you will need to deliver the framework or tool results file (expecting JSON or XML) to the parser webhook endpoint with a delivery script executed by your chosen CI/CD tool. These scripts may also be used in Launch to bypass the Universal Agent parsers and send the results to Pulse. You will need to edit the delivery script to include the qTest Project ID, target the top level Test Cycle ID, Pulse framework parser webhook endpoint, and location of the results output file. You can find the qTest Project and Test Cycle IDs in the URL when you select your chosen Test Cycle in qTest Manager, see below.

There is a selection of parsers available, but they are easy to create as well. Create a Trigger and Action with your chosen parser and link them together with a Rule. Update your delivery script with this webhook endpoint. To create your own parser, review this API documentation. In the next step, you will be delivering the parser results to qTest Manager via a Pulse rule wrapped around this API, and the payload will need to match the expected input for this API.

Submission of Parsed Results to qTest Manager

This rule takes the standardized construct created by the parser, then authenticates and submits it to a qTest Manager API, as linked in the section above. You will require a qTest API Bearer Token in order to authenticate. For heavily automated workflows, we suggest creating a service account in qTest that has access to all automation projects to allow submission of results to any project with one account.