Without test case versioning, if you are trying to understand how a test case changed over time as it has gone through new test versions, you want to see if anything about a test changed as an application got more complex, or if you want to know more about an accidental change to a test (like if someone errantly makes a bulk edit), there would be no way to know the history of the changes in a test case. Whether it is knowing when a test case was changed, who made certain changes, what changes were made, or where your process started to break down, test case versioning allows users to keep track of and see the histories of different versions of a test case. However, it is not just simply having your test management tool track all changes that you make to a test case. Similar to version control for code, test case versioning could also mean:
- Comparing test case versions side by side
- Reverting to previous versions of test cases
- Creating multiple branches and test case copies within a project
As software projects evolve, every testing team needs to think about how they will handle changing requirements and test cases for their projects and releases over time.
Why is Test case Versioning Important?
Now you’re aware that test case versioning makes it easy to manage, track, and review different test case versions and changes over time, but why is that so important?
Let’s go ahead and explore some examples of how test case versioning can help you track the history of test case changes, compare them, and easily manage baselines for different project release branches with TestRail.
Reason 1: Compare any test case versions side by side
If your existing test case is incorrect, missing information, or skipping a step, you would most likely make changes to correct the test case so that it is more accurate for the next time you (or anyone else) runs that test again. Test Case versioning allows you to understand the changes that have occurred over time within a test case by comparing two versions side by side. This makes it easy to see the differences between any two versions so that you can understand them and take action accordingly.
Here is an example of this test case versioning in action: If a test lead creates the initial test case to be used for testing and then a tester decides to update and change the description of a test case to include missing information, the version of the test case will change incrementally. The initial version of the test case was version 1 but after the changes, the version will be updated to version 2. This is beneficial to allow users to view the details of a previous version of a test case, compare any two versions of a single test case, and allow users to roll back their test case to a previous version.
How does test case versioning in TestRail help?
Test case versioning in TestRail allows Enterprise testers to compare any two test case versions side-by-side and see highlighted differences between the two versions. TestRail also gives users the ability to better understand how to fix issues, why a bug is occurring, and why something is not working the way it’s supposed to work.
Reason 2: Full Test Case History
Even if test cases do a great job documenting what the application does when a user makes a change, the application has now become a new version of itself and the same test cases might not be accurate or relevant. Test case versioning is important in this situation because it lets teams see who exactly made what changes to test cases and identify what the test case would have looked like when it was run against previous versions.
Example: You keep having to rework through development because you have had constant changes and bugs going on in a certain aspect of your application for a long period of time. When this happens, you can end up with a chaotic history of how that part of the application has been working, what bugs have been going on around it, and where it stands now.
How can test case versioning in TestRail help ease this problem?
When it comes to test cases and portions of applications that have constantly been undergoing change, TestRail helps by documenting what’s changed, what’s working, what’s improved, etc. If you are working with Excel, finding historical test case data is a messy task and with other tools that don’t support test case versioning, you would most likely be manually sifting through heaps of past versions trying to figure things out for yourself. With TestRail, you can compare any versions you choose and get visual feedback instantly while boosting team collaboration and efficiency.
TestRail also provides comment history. Comments add context to each version so anyone – including the person who made the changes – can look back and understand not just what changes were made but why those changes were made and what considerations they were trying to address.
Reason 3: Baseline Support
The third reason why test case versioning is important is that sometimes it is necessary to keep multiple versions of an instance for different audiences and purposes. These baselines allow you to create multiple branches and test case copies within a project.
Example: If a certain segment of your users are not going to want to change from an old version of an application or they’re going to have to apply certain changes within their instance before they can adopt the newer version, you don’t just want to push up the new version for everyone, you want to keep both versions live and working. You also want to make sure you can maintain and test both versions, making it helpful to keep a record of exactly what the test case looked like when you tested it against a specific version.
How does TestRail help?
Internally, a baseline is similar to a test suite, and it includes all sections and test cases of the original baseline or master branch it was copied from. With test case versioning and TestRail, teams should use baselines if they have to maintain multiple major project versions for a long time in parallel. That is, your team needs to maintain and release multiple main branches (e.g. 1.x and 2.x) in parallel for many months or years, and the test case details will be quite different for each baseline over time, as each version will need different test cases. We designed baseline support specifically for this scenario and it’s a great way to manage multiple branches and versions of a project’s test case repository for multiple parallel development efforts.
Conclusion:
So why is test case versioning important? Test case versioning allows users to compare test cases and to keep track of the historical data of their evolution. It is also important because ultimately, it helps QA make sure the integrity of your application is intact. But in order to do that, you need to make sure that test cases that are written against your application also have their own integrity. The way to do that is to be able to make sure that as changes happen to your application, as changes happen within your test cases, and as changes occur simultaneously across different branches, test case versioning allows you to maintain that integrity throughout the process.
Try TestRail for free today to improve your testing efforts and check out the latest test case versioning features!
