Tips for training testers

Get Started
1

Hi everyone,

At the company I work for, we don’t have many people who are explicitly “software testers.” More often, we get a group of people to help us test.

Up until now, they’ve mostly been rummaging around in the dark (“here, click around on this and tell me if you see any problems”). I want to now implement some official training to hopefully help save them and us (the developers) time and energy by reporting properly.

So, I’m just looking for ideas on topics to cover that I might not think of. I don’t want to turn them into completely professional testers, but I’d like to help provide them some guidance.

Here is what I have so far:

  • Types of testing: black box/white box (and that they are doing black box testing)
  • A run-down of our major software properties
  • Basics of template system (“you don’t have to report the typo in the footer 50 times”)
  • Entering random input (“if we did our job poorly, ‘; DROP TABLE Users;’ should be funny”)
  • What to report (browser/OS where relevant, steps to repeat, screen shot, URL, etc)

Anyone have any things that I should include?

Thanks.

2

I’m a big fan of making sure that testers use the bug tracking system appropriately… (especially priority! Argh, copy errors are not high prority :p)
(Are you using a bug tracker or ticketing system?)

Regarding the entering of random input, depending on your dev platform, that’s something that can be tested automagically using something like [URL=“http://code.google.com/p/skipfish/”]Google’s SkipFish or maybe some tools from [URL=“https://www.owasp.org”]OWASP might be helpful?
It would still be a good idea to get actual humans to test it of course; If you want them to test form submissions, I’m inclined to instruct people to “try and break it if you can” (because in testing, breaking something is good :))

The what to report is important to formalize, so people don’t send in reports like “Error on the homepage with widget x” .
An extract of www.supportdetails.com can be helpful with this part as well.
Make available some screenshot utility (like snag-it or something along those lines) where they can draw markups. (that reminds me, [URL=“http://markup.io/”]Markup.IO could come in handy here as well)

:twocents:

3

Thanks.

We do indeed use a bug tracking system (Bugzilla) and I’m going to mention what to input and where.

The tricky thing is we have multiple properties (of multiple types) that they are going to be testing. One of the major ones is even developed for us by a third party (and I avoid touching their code like the plague).

I’ll definitely be giving them some tips for trying to break systems as well: “Hey, putting ‘; DROP TABLE Users;’ is fun!” =p

4

I suppose that you could have some general guidelines for testing and for each individual component/property have some specific guidelines.

In terms of bug tracking it’s important that people know what component they’re reporting a bug against (some custom fields in Bugzilla perhaps?)

And bad 3rd party software … shudder

5

Yeah, that’s my general idea. Since we do develop software (for internal use), I’m planning on doing subsequent mini-trainings for each new property to bring them up to speed on what parts they should be paying special attention.