How to teach a non-tech person to test an app

My company hires a few interns every summer. Sometimes they are hired for a specific department related to their major. Other times they rotate departments and help where needed. One of the interns was recently assigned to my department to help me "beta test" a web app we're releasing soon. This is awesome but I have no idea how to teach a college student with limited tech experience how to "test" a web app.

How would you teach someone to test your web app?

What kind of pointers or instructions would you give them?

What kind of bug report would you ask for when the person testing isn't a dev?

So far I've asked her to:

• Go through the app like you were a normal user.
• Click everything!
• Try to use different browsers at different sizes including your mobile phone.
• Let me know if something doesn't do what you expect.
• Let me know if something doesn't look right.

Anything I've missed?

Comments

[Austin S. Hemmelgarn]

Short list of other things I can think of:

• Explain the reasoning behind testing responsiveness and how to test it properly, ideally using something that actually does it right as an example. This is an area where it's almost impossible to create bias, because whether it works or not is usually blatantly black and white. This is also an area that most people new to development work (especially if they have no web development experience) will not know a thing about, and are thus either not likely to test, or not likely to test right.
• Explain how to explain what's wrong. In short, teach them how to write an at least passable bug report. Most people (even many experienced developers) don't know how to do this, and it will save you time later. An issue template is good here.
• Don't tell them anything about the UI. Just tell them what the app is supposed to do. This avoids introducing bias regarding how the UI is 'supposed' to work, which can make it harder to determine if the UI actually makes sense or not for what you're trying to do.
• Discourage them from looking through documentation. Normal users don't look at documentation in most cases, so your testers shouldn't either. This also helps make sure the app is intuitive, which is a good thing.
• Ask them to focus on verifying that the app behaves as expected more than that it's appearance. Bugs in the core logic will have a much bigger negative impact on how your app is perceived than bugs in the UI unless those UI bugs are really big ones (and UI bugs that big should have been caught during alpha testing). This also makes it less likely that you get complaints about minor differences across browsers (for example, differences in the layout stemming from a different default font size in one browser).
• If you can observe them the first time they are going through any given part of the app, do so. Their behavior can very easily indicate things that they themselves don't consciously notice. Maybe it takes them a moment to find a button that you thought was located in an obvious place, maybe they get slightly confused by the wording of a notification, maybe a control does more than they expected it to. All of this will usually show up in their behavior even if they don't consciously notice it, and most people won't mention this type of stuff even if they do notice it.

[Ashlee (she/her)]

I would refrain from giving them any pointers or instructions in order to prevent imposing your own bias on their experience. When users can freely roam your application, you might find that they use it differently than you imagined.

Additionally, if you have the ability to observe the person while they are testing (which it sounds like in this case you do), pay attention to their body language. For example, if they frown a little or tilt their head after performing some action, it's likely that the result wasn't what they expected. Being present when this happens allows them to directly ask questions, which also can bring a lot of insight to you about the user experience of your app.

[Josh Brown]

I'd also suggest that they try and break as many things as possible. Try the edge cases, try putting numbers into boxes where you'd only really expect a text string, try putting negative numbers in boxes where you'd only expect positive numbers, etc.