I’ve been doing a lot of reading around testing for a good couple of years and I’m only just starting to get some clarity around the issues which face us as testers. When I read about testing I come across material which details ways to go about resolving problems, usually in isolation, and very rarely do they appear to tie up with other problems which is where it can become difficult to understand how all these models or techniques can come together.
For example
this post highlights two solutions to two problems and is one of the few examples of articles I’ve seen which link the two and show how they overlap.
Problem 1: You don’t know what to test, or how the program works, or what to test first
Solution 1: Use a mnemonic, or an application tour
Problem 2: How do you transform those tours in to tests?
Solution 2: You apply oracle
Result: Provide the tester with the tours, or mnemonics and the possible oracles, and they can start to test a system using their own brain, rather than a prescriptive test.
Problem: It’s dangerous to assume that a tester understands all the problems detail above:
- I can’t test everything
- Hold on, what is everything?
- Ok, how do I now choose what to test?
- Sometimes I won’t know where to start
- Sometimes I won’t know whether I’ve got a problem or not
In my experience I worry that tester training is somewhat disjointed and we don’t do a very good job of educating new testers on the key problems which face testers, and the techniques which they can use to solve those problems. Is it that we teach new testers how to run the tests, rather than how they think about what tests they need to run, and how they decide if those tests are problems which need escalating. Is it that we teach the solution, which is often inflexible, rather than how to think of a solution, which is infinitely more flexible?
The AST Black Box Software Testing Foundations course , along with some of the reading I’ve recently done has highlighted to me some inadequacies in how I’ve seen testers trained, and how I’ve been trained previously, which makes me want to further understand what kind of knowledge / understanding any tester should have before they pick up a mouse and start testing on a project.
Therefore, I’d be interested on hearing how other teams train new testers or what wisdom / reading experienced testers look back on as material which provided them with clarity on what it means to be a tester, and the techniques we can use to overcome the problems we’re exposed too.
Finally, apologies for a fairly unstructured blog, free time + energy on topic = blog!
5 comments:
Maybe you should get the book "How Doctors Think" ?
Reviewed and recommended on a lot of testers blogs
Ben Simo - Quality Frog
Michael Bolton
Jonathan Kohl
On the test team that I work on, I have noticed a couple of differences in the testers themselves. Some are aiming for management, some are aiming for development, some are aiming for a paycheck, and some are aiming to be the best damn testers they can be. These differences play a role in determining who finds "what" information to be beneficial to them.
When I started testing, I was taught the basics of testing the programs that the company developed by a couple of co-workers. I was taught how to write defects that could withstand criticism, and how to run manual, atomic, scritped test cases. When I began to understand what I was doing and was asking questions left and right, my boss handed me a couple of books. One of these was the every-software-tester-needs-to-read "Testing Computer Software" by Kaner, Falk, and Nguyen. On my own I began finding and reading blogs regularly. I took a couple of classes to understand programming a bit more (enough to understand some of the principles, I did not have a desire to program anything). Then I was lucky enough to attend a 3 day Rapid Software Testing course, this triggered a lot more knowledge about what I need to learn to improve my skills (more along the mindset that you are referring to).
When I find that a tester shows a bit of enthusiasm or excitement about what he or she is doing, I share what books I have read, blogs that I read, point them in the direction of groups/communities like the AST and the Software Testing Club.
I believe that because the field of software testing is so diverse and so are the people that are in it, there is an enormous amount of self-directed learning that needs to take place on an individual basis.
I think if a new tester is showing excitement and enthusiasm, the best thing is to fuel the fire within them by encouraging them. And, if possible, mentoring them.
That's a great post Michele and I think you hit the nail on the head, for me, with what you summarise in your first paragraph.
I second that praise for the comment by Michele - excellent post
Yep - excellent post from Michele.
I personally have never really been taught how to software test. I started a low paid job in a test team with no coherent direction and no company wide approach. Although this sounds awful it was actually the best place to work in terms of me learning how and how not to do testing.
I think a huge amount of the testers ability comes down to the tester themselves, another large amount to the test environment they work in (flaxible, creative, old school, waterfall, agile, automation etc) and then a small amount regarding how they are taught.
I've managed testers who need no training at all. They come in straight from school or uni and just get it. Others have been testers for 10 - 20 years and are pretty much useless. Of these people who were not very good, every single one of them held the ISEB certificate yet still missed obvious issues, couldn't write good defect reports, couldn't analyse a spec and find gaps and couldn't sit and think of creative ways to break things.
You can only teach a person so much before they reach their capacity for learning.
It is also important to point out that testing is more about socialogy, psychology and communication than it is about computing, maths and coding. I've often found that a 'Jack of All Trades Master of None' type person are more respected and appreciated that the 'master of one trade' type person.
Enough rambling. Good discussion post though.
Post a Comment