I did a Force Field Analysis brainstorm session with my team. We wrote down what we like and don’t like about our jobs as testers. Then, in the “didn’t like” column, we circled the items we felt we had control over changing. Here are what my testers and I don’t like about our jobs.
Items We May Not Have Control Over:
- When asked what needs to be tested as a result of a five minute code change, programmers often say “test everything”.
- Stressful deadlines.
- Working extra hours.
- Test time is not adequately considered by Programmers/BAs when determining iteration work. Velocity does not appear to matter to team.
Items We May Have Control Over:
- Testers don’t have a way to show the team what they are working on. Our project task boards have a column/status for “Open”, “In Development”, “Developed”, and “Tested”. It’s pretty easy to look under the “In Development” column to see what programmers are working on. But after that, stuff tends to bunch up under the “Developed” column. Even though their may be 10 Features/Stories in “Developed”, the testers may only be working on two of them. A side affect is testers having to constantly answer the question “What are you working on?”...my testers hate that question.
- Testers don’t know each other’s test skills or subject matter expertise. We have some 20 project teams in my department. Most of the products interact. Some are more technical to test than others. Let’s say you’re testing ProductA and you need help understanding its interface with ProductB. Which tester is your oracle? Let’s say you are testing web services for the first time and you’re not sure how to do this. Which tester is really good at testing web services and can help you get started?
- Testers lose momentum when asked to change priorities or switch testing tasks. A programming manager once told me, “each time you interrupt a programmer it takes them 20 minutes to catch back up”. Testers experience the same interruption productivity loss, but arguably, to a larger degree. It is annoying to execute tests in half-baked environments, while following new bugs that may or may not be related, along the way.
We will have a follow-up brainstorm on ways to deal with the above. I’ll post the results.