Abstract
As we deal with maturing software, we’re often faced with the need to adjust our test cases on different stages, for instance Development environment, Final Quality environment, Hotfix-Stage, Migration stage and many more.
Baangt offers a simple yet powerful method to easily deal with all possible occurances of different software versions without the hustle to change the definitions whenever you reach the next stage in your deployment process.
The usual approaches
One way to deal with that is to copy a test case definition for each stage. If you’ve been there and done that, you know already how tedious this gets in the weeks to come after the decision to copy. Of course you’ll have hotfixes, that need to be reapplied to all other stages. If you have copies of test files, that means that you have to adjust each parallel change in multiple files. And of course you forget that. You’re spending hours and hours of useless waiting time just to find out, that – again – you forgot to copy a change into one of the files. Assuming you’ve more than one test case, you’ll soon spend more time searching for errors in your test case definition than actually finding errors in the SuT.
Another way is to add endless IF-Conditions. IF Stage = PreQuality: Do something different. IF Stage <= FinalQuality: Do something. That’s slightly better, because you work only in one file. But you have to touch this file with each and every deployment! And you’ll make mistakes – you are human after all. Sometimes somebody in your organization will deploy to an upper stage but forget to tell you or you don’t see it. Bang! There goes another few hours of searching for errors in your test case definition rather than finding errors in the Software (or confirming, that it actually works).
How baangt is better
With baangt you have a very simple yet powerful way to define, which test steps run in which stage. The secret is the field “Release” in the test case definition. Let’s say, that you have one set of fields for entering the customer name for current productive use and a new cool way for the next release. All other fields in the test case remain the same.
You’d simply have both versions in your test case definition, one with “Release” e.g. 1.0 and the other with “Release” 2.0. You can test the productive state of software in Hotfix and the new cool way in Pre-Quality without changing anything in the test case definition. In the test run definition you’ll tell baangt, which Release is installed in the current stage. That’s it!
As your software matures, you simple increase the version for each stage, that gets populated with the latest version.
No copying of files, no endless IF-Statements, no unnecessary and error prone changes to the test case definitions!
Try it out!
In baangt download there’s an example “CompleteBaangtWebdemo.xlsx” which shows the functionality. This is a mature feature of baangt, but in case you need additional functionality you can adjust the corresponding code using sub-classing or plugin.
Recent Comments