QASymphony / Blog / Adding Exploratory Testing To Your Testing Strategy PT2
Adding Exploratory Testing To Your Testing Strategy PT2
Welcome to another Whiteboard Friday! Last week we discussed a few ways teams can begin to introduce exploratory testing into their overall testing strategy – you can check it out here. This week we’re continuing our discussion on incorporating exploratory testing into an overall testing strategy. Enjoy!
Hello, everyone and welcome to Whiteboard Friday. And today, we’re going to be talking about part two of our series on how to incorporate exploratory testing in your testing processes. First thing we are going to talk about is beta testing. How to use proper exploratory testing methods in your beta testing to get the most out of your feedback and then also how to use exploratory testing to replace a lot of those prescribed testing methods or testing steps that you currently in your process that’s taking a lot of time. For beta testing, there are usually two problems that come up when you want to get your product out for your end users to start testing to provide that feedback for that beta program.
The first thing is that even when you have an efficient beta program in place, only around 30% of the people that are actually incorporated with that beta testing provides feedback. Around 70%, they don’t just give feedback at all, maybe it’s not for their program and they may not really give anything to you. One of the reasons is because there is no really clear direction on what they are supposed to be doing, so the solution to that would be to provide an exploratory testing charter, a guide as you will, to help them navigate and go through whatever application area you need them to test against in that beta program. What that does is that it allows them to have a focused area of testing but then also it gives them accountability on basically what they need to participate in.
The second problem is that there is a lot of different use cases that are either over-tested or they’re under-tested during that beta testing so you can imagine you’ve got maybe one high point of your application, maybe everyone should drive into that area and only focusing on that new widget or that new color scheme or whatever, right? And what they are not doing is really looking at all the other areas of the application that are incorporated in that beta program. The solution to that would be to provide not only a charter but an assignment that is in those specific charters that are really revolving around coverage that you want them to test against. So we’ve got some kind of grid here that talks about a traditional beta versus an exploratory testing beta, and really what it does…we’ll post this on the blog here. What it really does is it shows you that incorporating a beta exploratory testing method, gets you a lot more focused attention to have them give you the feedback you need for that beta program.
To take explanatory testing and actually incorporate it in your daily activities and replace a lot of those prescribed testing steps with expected results and having those prescriptions on the test steps itself, very repeatable steps, what we want to be able to do is take a lot of those test cases that are either reused or take a lot of time and move those into exploratory testing charter. We’ve talked about this before, but we know that if you were to give an option for explanatory testing to your testing team, we know that innovation, job performance, job satisfaction, and workplace satisfaction, it goes up by nearly 10% across all this different categories. If you give the option for exploratory testing versus not giving it, you can see that there is going to be some real value adds for your testing department as a whole, for them to really embrace their job and really love coming to work and really embrace that exploratory testing.
But how do you go about replacing and figuring out what scripts need to be replaced with exploratory test charters in sessions? Well, there are two things, two schools of thought in doing that, one is to look for tests that have resulted in really low failure rates and replace those with exploratory testing. We know that if you’ve got a test case or multiple test cases that continually pass, aren’t finding new defects, that test case may be archived or may not even be used. What we want to be able to do though is take those steps we had, throw them into a charter and really encourage them to veer off the path and actually find defects that they previously may not have found with that low failure rate of a test case.
The second thing is that you’ve got a test case that is extremely long, that is run frequently and it’s just taking a long time for those test steps to do, the data prep, with each expected result, each step description that they are going through. So what we want to do is be able to take those test cases and really embrace exploratory testing to give them more job satisfaction out of those test cases. For example, if I were to do 100 steps of a test case and redo that even 10 times a day, I am going to be very bored. I’m not going to be encouraged to look for defects. I’m just going to be hitting the buttons and hitting the keyboard to actually go through that testing process. So take those redundant, very long test cases and encourage them to incorporate that in an exploratory test session where they maybe can find more defects and more opportunities to test.
How do you structure exploratory testing? We’re going to post some examples of session charters as well on the blog, but just always keep in mind that you can do that different ways by keeping testing notes, logging the issues you have in the bugs, in the charters, in those test sessions. Again, lots of different ways to break down that session for a debrief later on. We’re going to put in some kind of best practices on how to do that on the blog. We won’t get into it today. This has been how to use exploratory testing in your testing process. Thanks for stopping by. We will see you next time.