A practical example of integrating ReQtest into a wider network of tools

Intro

We in the ReQtest product team eat our own dog food and use ReQtest to track our requirements, test cases and bug reports. Today I want to show you how in the development team we use the integration features in ReQtest to make our daily lives easier, and to make our development process more efficient.

Some background

Different people in our team use different parts of ReQtest. Us developers spend most of our time in the bug reporting module.

Here’s the typical life cycle for a bug.

Someone finds a problem and creates a bug report.
A developer picks up the bug report for fixing.
The developer commits their fix to Subversion.
The continuous integration server picks up the code change, compiles the code, runs unit and integration tests, and deploys the new version to a shared DEV environment.
Our tester Kristina triggers a deployment of the code to the TEST environment.
Our tester Kristina re-tests the bug and hopefully approves it.

This is somewhat abbreviated (for example, there is also triage and prioritization) but we can ignore that for now.

lifecycle-of-a-bug-at-reqtest-v2

All the communication around the bug report happens in ReQtest.

In step 1 of the bug life cycle above, a bug report is created in ReQtest. In step 2, the developer sets themselves as the owner of the bug report, and changes the bug report’s status to “Being fixed”, so everybody else knows that the bug is “taken”. When the developer checks in their fix, in step 3, the status is updated to “Fixed in DEV”.

As part of step 5, the bug report’s status is changed to “Ready for test” so that Kristina knows which bug fixes are ready for her to verify. She then verifies the bug and sets status to either “Approved” or “Reopened”.

Automation

Being developers, we love to automate the heck out of repetitive tasks. Steps 4 and 5 in this process are prime candidates for automation: they happen frequently, involve lots of fiddly steps, and require no judgement calls whatsoever. Therefore we have put in place a fully automated continuous integration process, including fully automated deployments.

The only thing that needs a human touch is triggering the deployment. While the deployment is in progress, the test environment is unavailable. We don’t want this to happen automatically, because we don’t want to interrupt Kristina’s work unnecessarily. So we let Kristina be in charge of that by clicking the button when it best suits her.

But getting the code to the test environment is not enough. Kristina also needs to know what bugs were fixed by that deployment. So the deployment process also needs to promote bug reports in ReQtest from “Fixed in DEV” to “Ready for test”.

Details

To solve this, we wrote a simple console application that can update the status of bug reports in ReQtest. Its command line looks like this:

BugStatusSetter.exe <from-status> <to-status> <project id> <userid> <password>

This application basically does the same thing that a user would do: it filters the list of bug reports in our project based on status, and then edits the bug reports to update their status. Except that instead of using the user interface in ReQtest, we use the REST interface of ReQtest Connect, our API.

Get metadata (field data) for bug reports from https://secure.reqtest.com/api/v1/projects/1/meta?itemtype=bug
Look up the field called Status, and the required status values
Create a query for bugs with status equal to <from-status>, at https://secure.reqtest.com/api/v1/projects/1/queries
Execute that query to get all bugs with that status
Loop through the result and updates each bug, setting its status to <to-status> at https://secure.reqtest.com/api/v1/projects/1/bugs?queryId=22

(That number 1 in the URLs is our project ID – we were the very first users of ReQtest, back when we started developing ReQtest, and we are still using that very first project.)

You could do this using any language, but since we mostly work in .NET, we chose to write this in C#, using our demo application for ReQtest Connect as a starting point.

Then we hooked this little application into our deployment process. We use Octopus Deploy to automate our deployments. We added a deployment step, right at the very end of the process, to call this script:

deployment process

The deployment step consists of this Powershell script:

if($OctopusParameters[“Octopus.Environment.Name”] -eq “test”)

{

& “C:Program FilesReQtestBugStatusSetterBugStatusSetter.exe” “Fixed in DEV” “Ready for test” 1 $OctopusParameters[“ReQtestProdUserId”] $OctopusParameters[“ReQtestProdPassword”] | Write-Host

}

And we’re done! Now, any time Kristina clicks the button to deploy the latest version of our code to the test environment, she automatically also gets a fresh list of bug reports to retest.