QASymphony / Blog / Adding Exploratory Testing To Your Testing Strategy PT 1
Adding Exploratory Testing To Your Testing Strategy PT 1
We’ve discussed exploratory testing, the benefits of, what it is NOT, but we haven’t discussed how teams can introduce it to their overall testing strategy. Today’s White Board Friday video is part one of two for introducing exploratory into a teams overall testing strategy and highlights three main ways this can be accomplished.
Hey everyone, welcome to Whiteboard Friday. Today we’re going to be talking about how to incorporate exploratory testing into your overall testing strategy. Before we even talk a lot about the theories behind exploratory testing, the do’s and don’ts and here we’re going to be talking about three ways to really use and leverage exploratory testing in different facets of your business.
Whether it’s going to be paired testing, doing it in teams and then also incorporating that it into a UAT cycle of testing. So let’s talk about paired testing first. First thing we want to kind of notify you is about when you actually do testing just by yourself or doing sample testing, there’s usually three things that will come up that are really not efficient for your testing process.
The first thing is that when you find a defect and you’re all by yourself, you don’t really understand whether that’s due to requirement or due to a coding mistake that’s actually going on in your organization. It could be a wrong requirement that’s been written or it could be the program needs to be updated or the user story needs to be updated. You don’t really know that, you’re just logging defects against blindly something that’s either in the code or against a particular user story or requirement.
The other thing is when you’re taking defects and you’re creating them, what you’re doing is you’re just throwing them over the wall to the developer. What happens is that without actually communicating with that developer there’s a bottleneck that occurs.
So you have all these defects that the developers are constantly in the backlog you’re working on and it’s surely just going to really not get to an area where they can be resolved because there are so many defects being pointed to them to work on.
The last thing is that there is too much time between that developer and tester to resolve some things, even if you’re passing defects over to the developer, you have no idea when they’re actually going to be resolved. The more defects you pass over without having immediate feedback the more miscommunication you’re going to have and the more delay in that defect being ready to be reproduced in an actual test environment.
So with paired testing, what you’re doing is trying to get rid of all these issues. The first thing is that when you’re actually doing paired testing with a business analyst or a developer, what you’re able to do is actually have a closed integration with another person of that development team.
What that means is that we can minimize all that miscommunication because the developers can be sitting right next to you or they’re maybe a couple of steps down the hall from you right? Or if you’re using Skype or something like that where developers are in different regions of the state or even in the country. You can use that as a way to communicate back and forth when you’re actually testing a feature.
The other thing is you’re getting immediate feedback right? As soon as the new code is being delivered, you can get immediate feedback right away. The developer can say, “Hey it’s been released into production, okay I’m going to do an exploratory test session and we’ll go out and test that new feature.” And if I need to reply back to the developer, I can do that right away.
The last thing is that it really helps out with the fact that when you do find a defect and you are talking to the developer, the developer is actually then going to go and fix that issue right away. Once the issue has been fixed, the time it takes to reproduce that defect or to retest that test session, you can do that right away because that new code is being delivered into that new environment with the fix.
You can also incorporate…Aside from paired testing is a team based method for exploratory testing. This means that you have a bunches of teams that are set up, they’re doing step by step script test cases and what they want to be able to do is to say, “You know what, I want to have a group of members go out and do exploratory test charters, test sessions and actually do those in with one another.”
You’ll notice that, and the reason why we like to do this is because it’s really easy to learn how to actually get started with an exploratory test session. We talked about that earlier how you don’t have to do all these predescribed scripts, you can have objectives, you can have charters of actually where you’re going to do these sessions, and it’s just really easy to get started and ready to go.
The other thing is when you’re incorporating this team view here, what you’re doing is, or the team based sessions rather, what you’re doing is you’re having those team views with different perspectives and viewpoints. So if I were to assign five different user profiles to one team that’s doing an exploratory testing, I make it five different viewpoints as well when I’m actually doing maybe the, or testing that same feature that’s being rolled out.
The other thing is that we talked about reducing your overhead. Exploratory testing is very minimal in overhead, so there’s not a whole lot of what things to do to prep these teams. You can get them started with those sessions and they’re often ready to go.
Lastly we talked about user acceptance testing. User acceptance testing is actually one of the best times that I loved being involved in when I was a tester before I came to Huey [SP] Symphony. The reason why is because they are the subject matter experts, they know what to do. They are actually using the system more frequently than I was as an actual tester.
There are challenges with managing user acceptance testing. The reasons why they are challenging is because one is that UAT testers aren’t familiar with typical syntax that goes on with test case management software. They are not familiar with the configuration or environments even or step descriptions or step variables.
They just merely go test a certain feature. The other thing is that they’re not really trained in tools as well to use in traditional test case management software. So what we want to be able to do is remove that and then move them over to being able to just saying, “You know what, take an exploratory test chart that you have, go off, perform the business flow that you would normally do but then also have a charter that can map out exactly what you found so that we can also give that to the development team and also the testing team to help you resolve those issues.”
We’re going to focus on being able to help them document defects better without having to go through a step by step overhead of the test case that they may have to do. The other thing is that UAT testers usually have a short period of time to do this. They have other jobs that aren’t traditionally in the testing environment or testing field and also they don’t have the actual attention span to test six to eight hours a day. So we want to keep them very much engaged in the application they are testing and the last thing they want to do is to sit down and go through a bunch of steps, six hours a day to find defects.
They want to go off and do their business processes to find that. Again they have that short period of time, a window to actually give feedback to the features they’re testing. Again what we want to be able to do is with exploratory testing, you are allowing the UAT testers to not necessarily have to stick to a prescribed script.
You are allowing them to say, “You know what, you find a different area of doing your business process where there’s an opportunity there to find defects or to find new features, go off to that direction. We’re giving that ability to do that so that your attention span isn’t going to be so short.”
Also what we’re trying to do is with exploratory testing, again with all that overhead you’re really going to be able to maximize the short amount of time you have to your UAT testers because they’re going to go off and do those business processes and dedicate only to exploratory testing rather than pre-described scripts that you have. So that’s part one of how to incorporate exploratory testing and your testing processes. Come back next time, we’ll talk about part two and incorporate some other things. Thanks for watching!