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.
