Versions labels with a continuous integration

G'day testers, here goes my first post.

How do people handle versions while performing manual exploratory testing when working in a continuous integration environment. Working in Jira there is a ‘releases’ feature that allows a version to be assigned to an issues, ‘affects’ and ‘fixed’ fields. But that gets gets out of hand quickly when there are one or more builds a day, and those builds a identified by their git hash not a progressive series.

Before this project I’ve worked with a fast release cycle in manual tested. A new build with bug fixes might appear every 3 or 4 days during regression cycles. During regression bugs are verified with any additional checks and then testing just rolls on with the new builds.

I’m excited to get started with a new proper agile project and I want to get it right from the start. What I want to suggest to the team is:

  • builds on check-in identified by hash, and maybe check-in count
  • Auto Test on each build
  • Build which break the build but can’t be immediately fixed are added to Jira as version
  • Builds which have major functions implemented or bugs fixed added to Jira as versions
  • Bugs are verified and recorded in later check-in numbered builds
  • Exploratory testing picks the lasted build recorded in Jira to run through each test session

Does anyone use the Version Merging feature in Jira?

Thanks!

Views: 69

Reply to This

Replies to This Discussion

>How do people handle versions while performing manual exploratory testing when working in a continuous integration environment.

What is the problem you are trying to solve? Tagging versions in JIRA is a solution, but what is the problem you have in that team?

RSS

Adverts

© 2017   Created by Rosie Sherry.   Powered by

Badges  |  Report an Issue  |  Terms of Service