Since testers like the why question so much: The answer to why I want all information available is pretty easy: I want to filter what might be necessary myself, I simply don’t want anyone else to do it for me as that might put a certain emphasis on things that I might not have chosen to emphasize on. And the answer to why I don’t want to put any effort into keeping two systems synchronized is probably even easier: Except from being lazy, I want to omit possible error sources whenever possible. So, that’s where tools kick in.
As you might have seen, TestBench helps you categorize tests by their respective user stories, so all you need for that part is user stories. If you are like a lot of other people and projects (yes, I know, your project is different, but let’s just assume for a second that it is not in that regard), you have your user stories in JIRA. As a tester your leading tool is probably TestBench, so that is where you want the user stories available. So, all you got to do is to tell TestBench where to find the user stories and push a button. Sounds easy? Well, it really is. Okay, it’s a software, so you have to do some minor configuration to get the magic running.
So, what do you need? The URL of your Jira project comes in handy, some credentials to login would be excellent and a grain of JQL might help as well. The URL is probably the most natural part that you can simply copy and paste. If the requirement system part of your test project in TestBench looks like this, you are on your way:
Unlike Santa, TestBench is not coming down the chimney to your Jira installation, but the proper way through the front door. To make that work, you should add some login credentials:
So you are through the main door now and all you need to know is where milk and cookies are stored. Or rather your epics and user stories. And this is where you need JQL. And it is pretty basic stuff, that you will know any. So, in this case we need to identify the Jira project and the issue type:
So, that’s it for the configuration part, now all you have to do is the press the button for synchronization and wait for that lovely green success message to show up:
In case you see this little bugger, then there is something wrong:
In my case that was pretty easy to get rid of. I tried the project name instead of the project ID, but hey, writing this sentence took way longer than fixing that.
As I mentioned earlier, TestBench uses user stories to categorize tests. To be honest (and as a user you probably noticed that mistake at once), this isn’t whole truth. TestBench uses a hierarchy of epics and user stories. This nice thing is, that Jira allows you to do that as well. All you have to do is to tell a user stories to which epic it belongs by setting the epic link field. What is even nicer is actually that this hierarchy is also synchronized with TestBench, so when you press the button and you have the epic link set in Jira you will get something like this:
Never mind the three open tasks, but the epic to user story hierarchy is intact.
In summary, it is pretty easy to set TestBench up in order to get all the information you might need for creating those tests of yours and to have all the information synchronized at the press of a button. This really makes it easier to get over the significant pains of hiding information and doubling information. So, you can run, but you can’t hide. And even automatically that is…
Christian Kram for TestBench Cloud Services