0

I am trying to formalize the development workflow and here's the first draft. Welcome suggestions on the process and any tweaks for optimization. I am pretty new when it comes to setting up the processes and would be great to have feedback on it. P.S: We are working on an AWS Serverless application.

Create an issue link in JIRA - is tested by. The link 'is tested by' has no relevance apart from correcting displaying the relation while viewing the story.

Create a new issue type in JIRA - Testcase. This issue type should have some custom fields to fully describe the test case.

For every user story, there will be a set of test cases that are linked to the user story using the Jira linking function. The test cases will be defined by the QA.

The integration/e2e test cases will be written in the same branch as the developer. E2E test cases will be written in a separate branch as it's a separate repository (Open for discussion).

The Test case issue type should also be associated with a workflow that moves from states New => Under Testing => Success/Failure

Additionally, we could consider adding capability in the CI system to automatically move the Test case to Success when the test case passes in the CI. (This should be possible by using JIRA API ). This is completely optional and we will most probably be doing it manually.

When all the Test cases related to a user story to success, The user story can then be moved to Done.

A few points to note:

We will also be using https://marketplace.atlassian.com/apps/1222843/aio-tests-test-management-for-jira for test management and linking.

The QA should be working on the feature branch from day 1 for adding the test cases. Working in the same branch will enable the QA and developer to be always in Sync. This should ensure that the developer is not blocked waiting for the test cases to be completed for the branch to be merged into development.

The feature branch will be reviewed when the pull request is created by the developer. This is to ensure that the review is not pending until the test cases have been developed/passed. This should help with quick feedback.

The focus here is on the "feature-oriented QA" process to ensure the develop branch is always release-ready and that only well-tested code is merged into the develop branch.

Improve this question

1 Answer 1

Reset to default
3

Most of your proposed workflow looks ok, but there is one thing that will bite you.

The Test case issue type should also be associated with a workflow that moves from states New => Under Testing => Success/Failure

No. A Testcase should have a workflow like New => Being Written => Ready for Execution.

Next to that, you should use an additional issue type "Testcase Execution" with the workflow you proposed. The Testcase Execution issues record the results of executing one or more associated Testcases. The advantage is that when you have the CI system run regression tests, you can just create new Testcase Execution tickets for recording the results of each run, without losing the history of previous times you executed the test.

The rule for closing a story would then that it has a Testcase Execution that shows all tests passing.

Also, before you start manually adding new test-related issue types, check what issue types AIO Tests adds for you to Jira.

Improve this answer
3
  • 1
    I'm not familiar with AIO, but similar tools handle test executions without issue types. A Test issue type is tied to 0 or more executions in various states that are managed by the tool. It appears, looking at the docs, that AIO is similar. But the rest is spot on, especially integration of your build server to your test executions to automatically track and record automated test executions against builds.
    – Thomas Owens ♦
    Commented Mar 31, 2021 at 14:13
  • I am also not familiar with AIO, as we use XRay. XRay uses issue types for test executions. I believe that in Jira just about anything you want to have uniquely identified must be an issue of one type or another.
    – Bart van Ingen Schenau
    Commented Mar 31, 2021 at 15:36
  • 1
    Interesting. I'm familiar with Zephyr, which keeps test execution data in the Zephyr service. They have a custom field integration that loads data from their servers. The only issue type that you need is "Test", which lives in Jira. Information about test steps, test cycles, and test executions lives entirely outside Jira. It sounds like different tools use different strategies, so getting the tool in place and understanding its capabilities early is a must, before adding issue types and relationships and workflows.
    – Thomas Owens ♦
    Commented Mar 31, 2021 at 16:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.