Our DevOps team has come up with a concept that I (as a QA automation engineer) do not agree with. They are suggesting that the test automation code should also have versioning that is always compatible with the source code - for example if app source code version is 2.10..the automation code version should also be 2.10. I don't agree that test automation code should be 'versioned' as such. It should be changed based on the needs. I would love to get some feedback on this.
-
It sounds a good idea to me. I personally prefer having everything TAGed.– Yu ZhangCommented Feb 6, 2018 at 0:46
-
@YuZhang I don't think the OP disagrees with idea of versioning (including tagging) in general, only with a scheme that synchronizes the source code and test code version.– beatngu13Commented Feb 6, 2018 at 9:52
-
2What would be the benefit of having different versions in test code, or no version at all? And if you cannot list any benefits, why you disagree?– Peter M. - stands for MonicaCommented Feb 6, 2018 at 14:34
-
@beatngu13, thanks, I re-read it, you were right.– Yu ZhangCommented Feb 6, 2018 at 16:08
Add a comment
|
7 Answers
I believe its a very good practice, In my company we do exactly the same, I assume this is only because of historical reasons (in our case) but in general, you will try to have the smallest number of the system possible so for the medium future, it probably makes sense to unify test automation script with the source code as the same version.
answered Feb 6, 2018 at 1:36
The big advantage of synchronizing both the source code and the test code version is that you can easily go back in time within your VCS by using tags (see e.g. Git or SVN), allowing you to qickly check out the sources and tests for a specific version.
Personally, I am a huge fan of Semantic Versioning, which you can summarize as follows:
Given a version number MAJOR.MINOR.PATCH, increment the:
- MAJOR version when you make incompatible API changes,
- MINOR version when you add functionality in a backwards-compatible manner, and
- PATCH version when you make backwards-compatible bug fixes.
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
If the source code versioning follows these rules, synchronizing the test code version makes even more sense: If, for instance, you make an incompatible API change and, therefore, increment the major version of the source code, your tests probably break as well. You would then create a fix for the new test interface and increment the major version of the test code.
In my opinion, a wonderful idea. As the version progresses, it will be necessary to make changes and adjustments so that the actual code of the automation will also increase the number of versions. If there is transparency to customers it looks much better and makes an order. Update what was decided at the end, interesting :)
Stop using separate branches for your test code. Test automation code is part of the solution, just like the 'real' , product code. The test code will not have its own version. It will have the same version as the product code by definition. No need to sync 2 versions. That's how we do it and we've never done it in another way.
As the system evolves, the test must evolve exactly the same way. There is no point to have only one version of tests, especially because you might want to test different versions of the same software, such as before/after adding a feature or before/after fixing a bug. Tests and System Under Tests are two evolving entities and the best approach to deal with these evolutions is letting them getting along.
ok I see that 100% of the answers here are in favor of putting a version to my test automation code. I am going to sound stupid/silly/dumb (yeah pick one!) but I've only ever just created branches and pushed test automation code to the branches. I have never put any versions/tags in SourceTree to the code. Can anyone please be kind and nice enough to tell me how to do that via SourceTree? (For instance have one version checked in..and next time when I check in do it with a different version)
Thanks!
-
This shouldn’t be an answer. Ask a separate question and the community will help. Commented Feb 8, 2018 at 21:22
I think there are two different scenarios:
You are adding new automation for an existing product
In this case it doesn't make sense to try anything other than 'current version number for app code'
You have a fully developed test suite
In this case it makes a lot more sense to keep version numbers aligned as others have suggested.
Another consideration is whether these are different codebases. I'm generally in favor of using the same repo (even if different languages). With this I see less need to pay attention to formal version numbers and focus more on working software (with automation) being released quickly.
answered Feb 7, 2018 at 13:58
