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.
In my personal opinions,
White box testing is made possible by giving testers access to source code, and comprehensive testing techniques such as MC/DC testing, condition decision testing can be applied.
Questions you may need to consider:
Is every tester working with you able to read source code? If they are able to read source code, do they want ...
To answer this, I think it is better to first look into why they have code access restrictions set. The fact that it is financial software is a valid reason. Minimizing risk of a security breach by minimizing exposure to source code is very important. This is maybe not the best comprison, but if during a snow storm, you don't need to travel, don't do it, ...
You should make a new branch from master branch anyway. The only changes which might go to the master branch are bugfixes. So the process should look like the following:
You make new branch from master. Now you have absolutely the same code as master has.
Developers develop the code in new branch, testers test the code in new branch
Since the master has ...
Testers having access to the source code and testers doing code reviews are completely separate things. More often than not testers are not that technically competent and also from my experience not even all developers can do code reviews.
Having read access to the application source code is useful for testing, if you are able to read and understand code.
Ofcourse testers should have access to the code that is being made by the developers.
In an Agile development testing should be an parallel activity. If you have dedicated testers they should be able to add automated tests during development and or do exploratory testing on builds they build them selfs from the code.
To quote the Less framework:
This is what you use Maven for. Maven manages and downloads your dependencies.
Suggest you try to always use the latest stable version of Maven and you should be set.
This is completely ok, we did exactly the same for a while. I assume this is for historical reasons (it was in our case)?
But in general, you will try to have the smallest number of systems possible. So for the medium future, it probably makes sense to unify on either SVN or Git(hub) as repository.
If the statistics are formatted differently you only need to modify how your get_statistics() methods parse their data sources.
If the statistics are numerically different, requiring you to set different target values. It's probably a good idea start storing those statistics in a config file. Then you can isolate version specific logic into the code that ...
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 ...
If you are testing safety, or other, critical code then your testing requirements will include 100% Code and Decision coverage - this is often impossible to achieve without seeing the actual code.
The specifications which you cannot test without are usually easier to understand & steal than the actual code so confidentiality is only an issue if ...
The main idea of specifying a version of a product in defect description is making dev engineer possible to trace-back the app the is currently under test to the particular commit under version control system.
What you show in your question is likely a build versions (not a version in terms of version control system since they likely look either as a commit ...
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.
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 :)
Yes git is a good option.
There is nothing like best, it's totally on you how you are implementing it. There are many other open source version control tools available you can consider:
Not really.. You could always:
Write your own history tab.
Amend your email templates for better
formatting (I have to agree with you on that one - the default emails
are useful to get as a note that something has changed, but I don't
know anyone who really reads them because the formatting is not
Many Test Case Management Systems offer some form of version control.
TestRail is one such tool and offers the functionality
TestRail automatically saves the history of your test cases and you
can see the different changes of a test case via the History tab in
the sidebar of the test case pages. TestRail doesn't currently allow
you to execute ...