I'm the lead developer in a team of 10 devs of varying skill / experience. The majority of the work that we do is in-house but the projects are getting increasingly complicated and the business is becoming more and more reliant on them to save money. We've decided to set up a small 3 person testing team to perform manual / interactive testing.

One of the testers is male and is extremely good at structured testing. He will look at an application, write a test plan and then work through it rigidly every time a new version is released. This approach works really well for us; he can quickly spot bugs and things that have changed, document them and explain them to whoever is developing that application. He's asked me to show him how to use the Selenium add-on in Firefox to quickly run a batch of tests. I personally think that testing this way is the only way but am open to having my mind changed.

The other two testers are female. The male tester has tried to explain this approach to them but they are adamant that it won't work for them. I want to try and be as flexible as possible over this.

Do male and female testers approach their work in different ways? How can I engage and teach my female colleagues the benefits of a structured approach to testing?

  • It is hard to automate something you cannot do manually. Manual test scenarios could be encoded as test scripts using Selenium. But scatter-shot approach to testing which your two other colleagues seems to prefer cannot be automated. Investigative testing is important but you need to have at least "happy path" scenarios to have a fighting chance to get consistent results. And yes you are right automating repetitive test is best done in Selenium, but writing automated tests is even more mentally demanding than just developing manual scenarios and following them. Jul 2, 2014 at 16:16
  • 3
    I would be reluctant to generalize any gender-specific differences you think you may observe to other testers.
    – user246
    Jul 2, 2014 at 16:35
  • are the "nom-structured" testers also finding bugs? Jul 2, 2014 at 18:28

2 Answers 2


This is definitely not a gender-based thing. I've worked with male testers who were less structured and preferred exploratory testing and females who preferred to create a detailed test plan and work through it.

What matters is that enough information about the state of the application in test is communicated to the rest of the team so they can make an informed decision on whether the application is ready for release. How that information is collected doesn't matter provided it's accurate.

That said, there are advantages and disadvantages to the two extremes you've outlined here:

  • If you're going to "look at an application, write a test plan and then work through it rigidly" you run the risk of missing things that aren't considered in the test plan. There will always be things that aren't in the test plan because it's simply not possible for any non-trivial application (which is almost all of them) to be fully tested.
    • Advantages of this approach: you can be reasonably sure (within the bounds of human error) that if something is in the test plan, any regression from it will be caught. It is systematic, and it probably covers most if not all of the high priority situations that need to be checked.
    • Disadvantages: it is mind-numbingly tedious and will continue to get worse as more features are added to the application. It's also prone to error because of the boredom of doing the exact same thing again and again and again. As an approach, it's not really flexible enough to handle rapidly changing requirements, with the result that test plans tend to get more out of date over time.
    • My preference: this is the kind of testing I'd look at automating ASAP. Doing this kind of regression manually is too error-prone and too boring. Most people will lose interest in the role if this is what they're being held to. Your tester who is doing this kind of testing is definitely on the right track in looking at a method of automation.
  • The less structured kind of testing works better for new feature development and the kind of "soft" information testers need to convey, such as look and feel, usability, and so forth. The biggest risk I've seen with less structured testing is the tendency for critical information to be stored entirely in one person's experience, which can be a major problem if that person moves elsewhere. It's easy to mistake exploratory testing for just randomly banging around an application if you don't understand where it's coming from.
    • Advantages of this approach: it is very effective when a skilled tester follows their intuition through a system or process to trace a potential problem. I've found it very useful for picking up potential usability issues, because I will always perform several sessions where I'm acting like as much like a user as I can. Things like broken keyboard shortcuts for power users, too many clicks to perform a simple action and the like may not seem serious, but to someone who is using your software all the time they can be the difference between keeping it or going with someone else.
    • Disadvantages: it's very easy to neglect to document this kind of testing. Documentation doesn't have to be massive: I'll usually have bullet point lists of what combinations I worked with (because the application I test has more possible combinations than I could test in a lifetime). It doesn't look as "organized" to managers who don't understand that testing is at least half black art (good testers develop an instinct for what is likely to be a problem and will do that without thinking that they're doing anything unusual), and it can be problematic when there are regulatory documentation requirements.
    • My preference: I keep a good screenshot tool in the background (I like Jing) and once I run into something odd, I'll start taking screenshots, see if I can duplicate it and start tracing more systematically to narrow down my reproduction steps before I create a new issue report. Annotated screenshots and short videos are invaluable tools for exploratory testers.

Neither of my lists here is anything like exhaustive - there are many more advantages and disadvantages to each approach. If your two less structured testers are convinced the heavily structured approach won't work for them, listen to them but compromise on getting enough information documented so others know what they've done (and they know when they have to come back six months later to check something). Get your structure-heavy tester to start automating and building a good regression test suite so the most tedious work is being done by computers.

This isn't like school where you get extra points for showing your work (at least, if you have decent management, it isn't). What matters is doing the job. If the exploratory testers are communicating accurate information about the application, it doesn't matter how they're getting the information.


You may want to take a look at a blog I recently wrote the role of the tester in a team: http://www.softwaretestingclub.com/profiles/blogs/a-conspiracy-of-quality

The primary role of a tester is identify risk (e.g. bugs) as early as possible in the application lifecycle and communicate that risk as early as possible. That means that communication (team meetings, emails, written bug reports) is critical to the testers role.

You may want to consider having the testers explore different roles, with the male tester acting as the "army" (e.g. test planning, automation) and the female testers acting as the "scouts" (e.g. exploratory, session-based testing focusing on identified risk areas). That combination can work well as long as everyone keeps up the communication and you don't grade testers based on bug counts, but instead how they work with the overall team.

Here is another blog I wrote on training a tester to perform structured, exploratory session-based testing that may help: http://www.softwaretestingclub.com/profiles/blogs/applying-the-lessons-of-rapid-testing-intensive

I hope that helps!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.