5

How do people handle version labels while performing manual testing when working in a continuous integration environments. In Jira there is a ‘releases’ feature that allows a version to be assigned to an issue's, ‘affects’ and ‘fixed’ fields. But that gets gets out of hand quickly when there are one or more builds a day, and those builds are identified by their git commit ID (hash) not a progressive series.

Before this project I’ve worked with a fast release cycles in manual testing. 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 build.

I’m excited to get started in an agile project again 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
  • Test on each build
  • Builds which break the build AND 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?

Improve this question

2 Answers 2

Reset to default
2

Some recommendations which may be relevant (but not Jira-specific) for your case:

Your build system will change, your ticketing system will change, and your version control system will change. This is inevitable, and it's a good thing. In the first two cases it’s either hard or impossible to migrate references (build numbers, ticket numbers) to the new system seamlessly - you may end up with “ticket #10 in the old system” and “ticket #10 in the new system”. In version control systems you can generally easily keep the old version identifiers (at least when going from CVS to Subversion, or from Subversion to Git). So I would base references on commit IDs, because they can easily be migrated in an automated fashion. You may of course also refer to build numbers or ticket numbers, but the commit ID should be used whenever possible.

Another reason for using the commit ID is that even within a single build system you should have the flexibility of splitting, merging, and generally tweaking the jobs/projects/pipelines without breaking references in your ticketing system. And your build system should make it easy for you to find builds based on a commit ID.

Builds should produce artefacts, which should flow through your build system to produce the production system if all the tests (automatic and manual) pass. This is an enormous improvement on the traditional Jenkins & co way of having disconnected build, test, and deploy steps, only linked by much hard work. Go.CD is a great example of this, where every build is linked back in obvious ways to the artefacts and commits which it is based on.

Recommended reading: Continuous Delivery by Humble & Farley.

Improve this answer
3
  • Should all builds be added to a ticket / testing management tool? If so there could quickly become thousands of versions. In that case just choosing the correct build from a dropdown would require some effort in filtering. I conceded that commit IDs have uniquness but they don’t have any inherent meaning, how do non-developers without source code access know what each build represents? ie, testers, project/product managers documenters, tech support etc.. I’m working on a firmware / internet integration project
    – shedfly
    Mar 19, 2017 at 12:35
  • No, that's not what I meant. I mean if you need to refer to a build, do it by commit ID because that is easy to migrate. Granted, in a large organisation you may have people who interact with builds but never with the source control system, but that is presumably a small minority?
    – l0b0
    Mar 19, 2017 at 12:37
  • I think its more about the industry then the size of the organisation. Our embedded firmware releases need to be handled by a number of groups most of whom can't read code. Thanks for your time! I hadn't really considered migration issues.
    – shedfly
    Mar 19, 2017 at 13:25
2

I would recommend using the versioning and release processes available in github.
We use them for both staging and production releases. Manual Testers are given github access so they can check what versions are being used by the various environments.

enter image description here

enter image description here

Improve this answer

Your Answer

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

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