In this episode you will learn about best practice approaches to getting started with Continuous Testing
A planning tool — JIRA and similar planning tools provide functionality for tracking, user stories, epics and tasks.
A version control system — Version control systems, like GitHub, allow development teams to track, collaborate and communicate on versions of the source code.
A build tool — Jenkins, Bamboo and similar tools will build and run unit and functional automation tests from the source code.
A testing tool — Tools like qTest Pulse insert the tester into this Continuous Delivery pipeline by providing test validation against JIRA issues and connect into source code repositories to streamline manual to automated test scripts.
Full Transcript Below
Hi everyone, welcome back to Whiteboard Friday. We are concluding our series today on how to win at DevOps with continuous testing. And just a quick recap of what we talked about. We talked about what DevOps is, talked about different forms of DevOps, whether it’s continuous integration, delivery, and then also deployment and how you may be at different stages where you are right now or maybe you haven’t even started any of those. And then we talked about continuous integration being the backbone of continuous delivery and deployment and where continuous actually fits into that model.
Then last week we went through and talked about how to get started with that and some best practice tips on getting started with continuous testing. And today we’re going to roll, kind of complete this with talking about some of the tools for continuous testing. So these are not the exhaustive list all of all the tools that are out there. You’ll see lots of different tools out there. But what we’re incorporating are a couple of things. One is a planning tool, so we’re going to be using JIRA for that for anything you’re doing in terms of tracking, user stories, epics, tasks, things like that. We’ll use JIRA for planning.
For development, of course, whenever your development teams are working on their stations, they’ll have their own IDEs and their own ways to actually do the coding. But the key thing is that you’ll need a version control system. We’re going to use GitHub for that. So a version control system allows everyone to talk and communicate with versions of the code. And it allows a source record for that code and it allows, for example, a continuous integration to occur with tools like Jenkins, which we’re going to use for our CI build process.
And then the last one we’ll kind of end up talking with our new product that came out from QASymphony, a part of the qTest platform which is qTest Pulse. And Pulse will integrate and we’ll show you how Pulse helps out with a certain stage in your continuous deployment where manual testers and automated testers are sometimes left out of that. So let’s walk through what happened in this pipeline.
So first thing what happened is when you’re planning a part of JIRA, the development team’s going to grab these user stories, they’re going to grab these tasks. So they’ll grab those. And what they’re going to do is they’re going to start developing against those. We talked a couple weeks ago about the features that they’re testing against. So when they develop code against these features or they’re tracking against what’s planned, then they’re going to check in that code into a version control system.
Now, what happens is the version control system will do something. What it will do is that as the changes occur, it alerts all developers of what changes have occurred, but what also happens is that Jenkins – we’re using it right now for our CI process – what it will do is look to see, oh, something has changed in this version control system. I’m going to build and run all my tests that I have against that code, whether a unit test. And if you have functional automation tests that are running as well that you have a back log for regression, it’ll also pick up those and run those. Think about if you’re using Selenium for that and you’re using Jenkins to kick that off.
So when that triggers and it’s right and it’s built, well now we’re kind of in an area where we’re maybe more into a new feature testing arena. So we’ve actually pushed and triggered a notification that says, okay, you know what, now we need to test against these user stories or features that may have not been covered with regression automation. And that’s’ where qTest Pulse comes in.
So Pulse, what you’re able to do is grab those user stories, grab those tasks, and since Pulse test cases are tied all the way back to your version control system, what will occur is let’s say I find a failure in this environment that I’m in. Well, what would occur is when I fail that, that test failure goes all the way back to the version control system where it alerts a developer. In this case we’re using GitHub, right? So when I alert the developer, the developer goes, oh, okay, great. Now I need to go and actually refractor some of the code and make some changes. This is where a key disconnect has occurred a lot of times with exploratory testing teams or manual testing teams or teams that are moving more towards automation where they’ve got manual tests that still haven’t been automated yet, right? If their tests are connected back with the source code, then developers are kind of out of the loop of what’s going on.
And if you don’t give this feedback to developers, then in this pipeline, what you’re kind of at risk of doing is pulling something out into production that shouldn’t have actually gone out there, right? So what Pulse will do is it’ll alert that. When you check something back in…we’ll say you refractor that, it’ll alert Pulse to say, okay, now I need to go and actually retest those activities. And when I retest, the same thing will happen, right? You’ll have a trigger of, hey, we had a successful pass. That’ll incorporate back into version control. And what that’ll also occur is trigger new builds into Jenkins to run all your automated tests and also incorporate any of those manual tests, right? So now you have a way to track any manual test execution and automated test execution that’s tracking a part of your continuous integration or continuous delivery pipeline. Now you have confidence to say, “Okay, you know what, now we can push all the way to production.” Everything’s connected back to that source code.
And the other thing that Pulse will do is this, is that when you get to a point where you’re saying, “Okay, everything has passed, we’re ready to go, when we’re tracking the user stories that are going from to do to in progress to code completed to a done state,” well then, what Pulse will allow you to do is actually automate that workflow back into an ALM tool like JIRA. So if you say, “Yep, I’ve checked all my passes, we’re ready to go.” I can move that to Completed and it’ll actually push it to Done.
That’s what helps out also with teams that are really caring about making sure that we’re not pushing code out into production if there’s failures attached to it. So we’re not just tracking failures and passes against a user story. We’re tracking it all the way back to the code that the user story is actually tied back to. So that’s a quick example of using some tools for continuous integration. We use JIRA for planning, we use GitHub for version control, and then we used Jenkins for CI and then we used qTest Pulse to show that workflow engine kind of operating with the manual testing team, the exploratory testing team.
And then the great thing about Pulse is this, is that at the end, let’s say you have your manual test done, now what you can do is grab all those test since they’re stored in version control, now you have an easy way to convert those manual tests to an automated fashion. So it’s a great way to connect those from your manual test team to your automated test team and also include them as part of your pipeline that traditionally they’re kind of left out of.
So those are some tools to help out help out with getting started with continuous assessing. We’ve enjoyed this time together on our Whiteboard Friday and we’ll see you next time.