views:

313

answers:

5

We tend to get a fair amount of churn in our testing department. I guess this is mainly because most of the people that move into testing get bored quickly and want to move up the chain into development positions (this is a good thing). As a result of this, as a developer I find myself on a fairly regular basis having to take a brand new tester who knows nothing and having to train them up.

There are a lot of things a good tester needs to know that they often do not start with. For example:

  • How to write a descriptive, but not overly detailed bug report
  • The importance of the issue title (ditto for emails)
  • Not wasting the developers time (too much) with non-issues such as "I can't install Oracle"
  • How to get core/memory dumps
  • How to narrow down the cause of a bug
  • How to write a good test script, and how to follow a functional spec so you aren't testing bogus stuff

What kinds of things do you find yourself "teaching" testers?

+6  A: 

Hire people that want to a career in software quality assurance rather than those who see testing as a stepping stone to development. I do a lot of both, and good testers are often poor developers and vice versa, as the disciplines involves quite a different mind set. Check the links on this post over on SQAforums for some great resources on this topic.

Edit: As requested, some of my experiences in terms of getting the most out your existing resources (time / people / budget) to produce a quality software product.

Rather than trying to add various ideas together to improve your testing, develop a detailed testing strategy in conjunction with all of the stake holders. (developers, managers, testers, and users having to deal with bugs). Start by establishing your requirements, i.e. what do you hope to achieve by testing. Is it primarily finding new bugs, improving usability, is it managing risk to the extent that the software complies with the supporting documentation, help files, etc... is it having the confidence that making small changes to you app will not cause the whole thing to come falling down around your ears?

Having figured out what you want to achieve through testing, you then need to come up with a plan of how to do this. Have you looked at automated testing for regression, exploratory testing for new and undocumented features, etc... FWIW, I've outlined the goals of my testing strategy here.

You may also want to consider what QA procedures you have in place such that there are fewer bugs to start with, e.g. Unit testing, TDD, Design by Contract, static code analysis, etc... Too many here can be as bad as too few where resources are limited as by repeating unnecessary testing you are drawing resources from other necessary testing.

Here's the most painful one. Are you properly resourcing you testing effort? What is the ratio of testers to developers? Do you need to reduce the amount of money spent on development in order to increase the amount of money spent on testing? Once you have developed your testing strategy, implementing it will require an appropriate budget. Unfortunately, good QA does not come for free, although carefully planned it can provide huge return on investment. Don't forget any budgetary constraints when developing your testing strategy.

As you may have gathered, proper testing and SQA is a complex technical discipline, and should not be thought of as an adjunct to the end of software development.

One more Edit: I found it very beneficial to immerse myself for a while in SQAforums as you can ask questions of very helpful experts in the field. (FWIW, I'm just a dev who also faced a major QA crisis a couple of years back, I'm not a QA).

And one last edit:

What kinds of things do you find yourself "teaching" testers?

I don't believe that developers should be teaching testers how to test, any more than testers should teach developers how to code. If anything, testers should be co-operating with developers to test efficiently and effectively. The 'education' goes both ways here.

Shane MacLaughlin
I agree - ultimately no matter how much you train, if someone is not interested in the job, you are going to have a problem. This is especially true in something like software testing where finding bugs and creating valid tests are something IMO require as much skill as developing software...
Nikhil
I know this answer got a lot of upvotes, but it is really missing the point of the question I was asking. What I am really interested in is the things you do to make testers good at their jobs
1800 INFORMATION
@1800 Information, ok I'll try to add a bit.
Shane MacLaughlin
+1  A: 

For testers who like development, you may assign them to develop testing framework/test scenario program/parallel run analysis program/...
I mean: testing can also involve a fair amount of programming.

However, it does first and foremost require good analysis skills to debug the deliveries, most often in black box scenario (which is when the developers-wannabe get frustrated: they want to debug internally the program!).

Regrading "Not wasting the developers time (too much) with non-issues such as "I can't install Oracle"", that would involve a Level-1 support team in charge to record the tester bug cases, and able to redirect the pertinent cases to the developers.

VonC
+1  A: 

There's probably some training to do on both teams, if you want to be successful in creating great software. Testers should not have to deal with stupid edge-conditions such as the user entering "foo" in a date-time box. That's something the developer (being an engineer) can do much more efficiently, but acquiring the rigor needed to think of all these cases requires some practice and/or training.

The testers should test for things that are not necessarily in the developer's field of competence, like:

  • testing in various hardware/software environments,
  • conducting usability tests,
  • automating test procedures where possible

If your testers are doing something your developers are too lazy to do, they're going to want to move to something else. Usability testing, on the other hand, is rather exciting and is a whole area of expertise in itself. Have the testers do that instead, you'll produce better software.

Carl Seleborg
+1  A: 

Fault isolation is an important tester skill: "the web server does not work" vs. "I cannot login on the server with Firefox".

Walk in customer' shoes: they generally knows the application better than the average user, and shall have this in mind while testing.

philippe
A: 

Few things I want to put light on: Testers ,who have the passion for testing never gets bored. They just love what they do and continue as testers. I'm sure that lot of my tester friends would agree with me on this point.

As far as training a newbie is concerned , First you have to make him think like a tester. Ask him to do the tests thinking himself as a customer , who is new to the application(This could help to improve you usability pf the system) Anybody can write a test script he needn't have to be experienced fella. You just have to show him how to write the procedures and objectives and whatever...but the quality is a constrain and it only comes from experience and the how much he knows about the system.

He has to make reading testing blogs and forums like sqaforum , a habit so that he knows whats he is dealing with.

For the memory dumb , errors and other programming related bugs you can give him some sort of traingin, showing him very simple examples..... like when u do what you get which error.....errr. got my point???

Ayreej