Paired testing

- [Instructor] One way to add some structure to your testing is to pair up with someone else. In paired testing, two testers are working together on testing the same piece of software at the same time. There are a number of benefits to this. The first thing to mention is structure. You'll need to work with each other to decide what to test and how you're going to pair, sitting beside each other, screen-sharing, et cetera. This of necessity adds structure to your testing. There's also a great deal of accountability in paired testing. There's two sets of eyes in play and so we can have more confidence that we've done the things that we need to do. Another important aspect of paired testing is creativity. Each of us sees and notices different things. And as we work together, we can often get some new ideas and thoughts that we never would have had if we were each working on our own. There are a few different approaches that we can take to pairing. We can't get into all the details in one short video, but I do want to walk you through two different ways that you could do paired testing and then briefly mention a third option. So the first way of doing it that we will talk about is probably what most of us would start doing by default if we were to start pairing. We'll call this traditional pairing. So in this style of pairing, two people sit together at a computer. One person is operating the computer while the other one watches and takes notes. At some point in the process, there will probably be a switch of roles between the operator and the observer. So the person sitting at the computer will switch places and start taking notes. Now this certainly can be beneficial especially around generating new ideas because you see how the other person interacts with the product and it gives you new ideas, but it can also lead to lower engagement since the person not operating the computer doesn't really have that much to do. So for this reason, some people will suggest trying something known as strong style pairing. The key idea of this style of pairing is that ideas can only come from the person who is not operating the computer. So you have two people. One is the navigator and her job is to tell the other person, the operator, where to go and what to do. So the operator, the person at the keyboard and using the mouse is only allowed to do things that the navigator tells them to. At first glance, this seems like it wouldn't work as well but it actually does have a number of benefits. First of all, it keeps everyone on the same page since all the ideas have to be expressed out loud as the navigator tells the operator what to do. It also keeps both people fully engaged in the process and it can also give a bit more structure and organization since expressing your ideas out loud forces you to think them through a bit more. A key element to keep in mind for either style of pairing is that you'll want to switch roles a few times through the session. If only one person takes one role the entire time, it gets tiring and difficult. So switch roles to help leverage the skills of each person involved. And then one other thing I want to mention briefly is something that isn't strictly speaking pair testing, but it's something called mob testing. And in mob testing, there's just many people simultaneously testing the same thing. I won't really get into it in this course, but I thought I'd mentioned it as something you might want to look into or consider as I have seen it work quite well in the past. So there are a different ways to do paired testing, but how do you get started with it? Well, I'm going to watch you through a step-by-step process to help you get started. So step one, come up with a couple of test ideas. I want you to come up with at least three test ideas, the first one around a part of the product that you know very well but using a style of testing that you're not an expert in. So maybe something like accessibility testing or security testing. Then I also want you to come up with a test idea around a part of the product that you don't know as well but that the stuff that you work on interacts with. So maybe something like administration preferences or something like that. And then also I want you to come up with a test idea around technical work related to testing that you don't understand as well. So things like maybe test automation, unit tests, build pipelines, things like that. So that's the first step. The second step is to find people to do the pairing with. And here what I want you to do is to make a list of two or three people that meet the following criteria. First of all, someone who has an understanding about a part of one of your test ideas that you don't understand as well. So for example, a tester who knows a lot about security testing or a developer who understands a unit testing framework. But then I also want you to find someone you would enjoy working with in this and that's open to trying new things. So that's step two. Then for step three, I want you to approach the people on your list. So you've made a list of people that are open to this, approach those people. But when you do that, come prepared. Ask them if they're willing to experiment with you on two paired testing sessions and explain what you're trying to do and why you're trying to do it. So if they're open to the idea, have a discussion with them to figure out the details. You can talk about things like when are we going to do it? What are we going to test? How long will the session be? What will the general structure and organization of it look like? Whose computer will you use and things like that. So that's step three and then for step four, do it. So try to do this at least four times. So two different people with two different styles of pairing each. But then when you're done, you're not done yet. You still have step five which is retrospect. So think back on what you've done. Reflect with your partner how it went. Was it beneficial, did you enjoy it? And then at the end of your session, review your notes and summarize what you liked and didn't like and what approach you preferred, and that's it. If you follow these steps, you'll have made your first foray into paired testing and you'll have a pretty good idea of what works for you and what might be worth continuing or changing.