Articles about planning software testing and managing it.
Point of views:
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:
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:
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.
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.
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.
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.
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:
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.
Download a guide on software testing in development projects. You’ll avoid many common mistakes and succeed in the implementation.
Improved testing efficiency, 70% less emails and real time reporting
Easily plan and execute even the most challenging development project