Part 6/11: Three Questions About Training

Blog post series about testing development projects, part 6/11

Articles about planning software testing and managing it.

Point of views:

• Business critical development projects, where IT plays a strong role.
• One or more outside vendors.
• Client’s business personnel as testers. They are business professionals, not software testing professionals.
• Goals for testing:
  1. Make sure that the implemented solution supports the needs of the business.
  2. Make sure the implementation doesn’t endanger the business.

Can we afford not to train our employees?

I have heard these lines more than once about the cost of training: Can we afford to train vs. Can we afford not to train our employees? Here is an example about the costs of not training.

A common situation during deployment project definition of a new software:

• Vendor’s consultants do not understand the client’s business processes.
• Persons making the definitions for the client are not familiar with the software used.

Main reason for this is that there has not been enough training before starting the definition phase. There might have been some introductions, but not tangible enough.

The cost of not training:

• Vendor’s consultants complain about the client not understanding. They want to specify the current system to the new software.
• Client complains that the vendor’s consultants do not understand their business. Also, the software is not working as it should be.
• There are unnecessary change requests made, because the different logic of the new software is confusing to the client.
• Wrong decisions are made, because the consequences of those decisions are not understood  When we get to the testing phase, there will be big repairs.

After big software changes people usually say the same thing: “If I’d understood this in the beginning…”
Everyone wants to do good work. When they are trained properly, they have a chance at that.

Who should we train and when?

In my opinion, the test manager should specify the need for training in the development project.

Why that is: If the project group is not trained, testing is the one that suffers most.

• Unnecessary change requests
• Testing is going nowhere
• The quality of testing is not good
• The quality of the basic information is not adequate
• Motivation takes a big hit

Another reason, why the person answering for the training and the test manager should be working together, is joint resources. Often the persons from the business who were testing best, were training best too. To avoid overlapping resource reservations, making the plan should be a joint effort. The goals are shared, after all, too.

Every new person should get a basic knowledge of the system first, before starting testing.

What can we teach to acceptance testers when time is limited?

One point of view of this blog post series is: Client’s business personnel as testers. They are business professionals, not software testing professionals..

When starting the acceptance testing, the introduction to testing should be done lightly. Persons involved usually know their business processes, but preparedness for testing varies. Some of them have tested before, some never. Here are a few comments I’ve had during the years.

• “It’s an off-the-shelf software, why do we need testing?”
• “They said to come and find all bugs from that system!”
• “So you estimate that there’s 157 observations to be found? Why don’t you fix those first? We can test it when it’s ready!”
• “Well I’m actually so busy at work, I don’t have time to sit around here.”

When time is limited and there are a lot of things to do, there are a few things what the training for future testers should, at least, include:

• Motivate to test – Tell them why we are testing
• How to test and what techniques to use
• Technical part of testing + testing tools
• How to report defects
• Prioritizing defects and handling them
• The process of development ideas and change requests

Blog series part 1/11 was about: How to estimate the number of defects?

I often use this estimate as a motivation for testing: Our problem is not the number of observations or the quality of the coding, it’s the mistakes in our own definitions and overlooking things.