4

I'm using SVN and I'm wondering about which part of the code base the users should test. The trunk (after the new feature branch has been merged in) or the branch?

If using the branch, how do you deal with the scenario where two developers are working on two different feature sets (so two branches), and need to release for testing to the users?

We've had a scenario where users are testing the wrong version (branch) and obviously cannot see their fixes. I'd appreciate some experience / advice about dealing with this.

Update:

Branches are used for new features / bug fixing and eventually merged back into the trunk. Testing involves testing the entire application (for site-effects) but will realistically users will have only tested their feature.

Improve this question
3
  • 1
    This is really a question about Subversion and has very little to do with testing. What is your policy on using branches? Why did you create a branch in the first place? What do you use branches for?
    – S.Lott
    Jan 12, 2012 at 11:55
  • Branches are used for new features/bug fixing which is then merged back into the trunk
    – billy.bob
    Jan 12, 2012 at 12:04
  • Please update the question to contain all the facts. Now that you have updated the question to say what branches are used for, please also state what the users are supposed to be testing. New Feature? Bug Fix? Or entire merged result?
    – S.Lott
    Jan 12, 2012 at 12:12

4 Answers 4

Reset to default
4

In our project, branches are created for specific releases, upon code freeze. So there is no regular development on a branch anymore, only bug fixes (for bugs found during release testing). So any features/bugfixes requested by users and included in that specific version are already on the branch.

This is the version which then gets deployed for UAT / staging, thus users can test it. It is also possible to deploy a development (trunk) version in the UAT environment for users to test, but we very rarely do this in practice. Usually only our own testers get access to the development (trunk) version of our app. This is deployed on separate development servers, which are physically not accessible for end users.

We use JIRA for issue tracking, which makes release management easy, so we (almost) always know (almost) precisely what features/bugfixes a specific release includes. In case you have no issue tracker, I recommend taking one into use. JIRA is commercial, but there are free alternatives too.

Improve this answer
1
  • JIRA is excellent.
    – quant_dev
    Jan 12, 2012 at 12:00
1

You mention users, so that could mean this is some sort of a Beta test. I would then assume this is a major release of some sort. So it was a branch from the trunk.

Or are they internal testers so they would be testing something prior to it being added to the branch or trunk.

In any case the users should be testing what they are given, or granted access to. Prior to testing starting a specific build is given to them to test.

Improve this answer
2
  • These are external testers (i.e the end users) there is no internal test team. So you think we should merge everything into the trunk, and then release that to users?
    – billy.bob
    Jan 12, 2012 at 11:47
  • "merge everything into the trunk, and then release that to users". This is not a question about testing. This is a question about how to use Subversion. (1) Search for answers. (2) Read the SVN book. If you're still confused ask a separate question.
    – S.Lott
    Jan 12, 2012 at 11:54
0

Since it's possible for errors to creep in after a feature branch has been merged into either trunk or a release branch, I would never do UAT based on a build from a feature branch. Make a build from your trunk, or your release branch if you use them; and have the users UATing that build.

Improve this answer
0

It depends on your branching/merging model, what put in your trunk, and how big your feature branches are. It depends also on your release model, if your users get a special "testing" version of your product before the final release is made, or if there is always just one software release in production, which always contains the latest (maybe unstable) features.

From what you wrote I assume a feature is merged back into the trunk when the developer in place thinks the feature is fully implemented. Letting the user test only the trunk version thus has pros and cons:

Pro:

  • you will get feedback from your testers not only if a feature is ok, but also when there is a bug caused by integration into the trunk
  • if you apply bug fixes directly in the trunk, you will be sure your users will get them also

Con:

  • if you need several days or weeks for developing a feature before you reintegrate it into the trunk, you will get no feedback from users in this period, since they cannot see the feature during this time.

The solution to this seems pretty simple: try to break down features into small feature slices which can be developed in only a few days, and merge them early and often. If you fear that your will get too many "half-baked" things into production using this model, I would suggest to implement something like a testing-mode into your application. In this mode, those "unstable" new features can be switched on at run time and tested from your testing-users, without having the need of delivering / developing two different branches of your program.

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.