In the early days of my Testing career, I found that when Test Managers looked at their metrics on how the project is progressing, and thought it appeared we weren’t on target; they would just throw more staff at it.
This seems a simple and obvious solution to the problem, but often they only assigned this extra person for a small amount of time, sometimes even just 1 day. So once this new person has been assigned to your project, you end up giving them a run-down of the project; explaining what the project aimed to achieve, some known bugs (so they don’t waste time investigating and relogging known issues), and then show them where the tests are to run.
So you may have taken an hour to do your introduction presentation, then they have bugged you several times throughout the day, causing time loss, and you lose your train of thought; slowing your progress down further. So at the end of the day, there may have been a net gain in productivity for the team, but it wasn’t twice the productivity that the Test Manager planned. It ended up being more like two people running at 60% effort. But then sometimes they ask you why you weren’t productive. “Erm, it was your fault for making me train someone up”.
Some days I’ve even gone through the who introduction to the project, only for the Test Manager to change their mind and take them back to their original project. All that does is increase stress for your team as you are closer to the deadline with nothing to show for your efforts that day.
Luckily, things have changed since then, and the team structure is more set in stone. Instead if the testers want help, the developers will chip in with running test cases. This means that they are already familiar with the project and functionality, and you can have them running tests as long as required.
Stranger Coding Tings 