Lately I was asked by my supervisor about a list of key practices for a software testing responsible person in our projects. I decided to expose this list for discussion. Please also keep in mind that I know that this list is very context-dependent for the company I work in.
First of all welcome to a new aspect of your job. You are now in a position which you have never been trained for, never been taught about, and – most obviously – no one will help you with. The job you are now asked to fulfill is about people, and they should be your primary concern. Expect the unexpected, they might give you a hard time, but it’s worth it.
Start a personal journal
Starting a personal journal is crucial to your journey. Regularly you will need to reflect on your course, making corrections as you go. Keeping a personal journal is a key for this. Each day take at least five minutes to write something in your journal. In the beginning you will probably be unsure about what to write in it. Start small. Start with the remarkable pieces of your day and reflect over the day. If you don’t know what to write about, write about that. Try this practice for at least three months before dropping it. It’s crucial to start with this practice while your journey has just begun. When the time pressure rises you might want to drop it. Resist this temptation. You will need to reflect over your course more thouroughly when time pressure is highest. You don’t need to share the journal. Indeed in a blaming culture it might be wise to keep it for yourself.
Ask questions – however mysterious they might be. Indeed it’s a key practice for testers to ask the difficult questions. Transport this to the team level. Ask questions about the course. Why was the testing staff left out from that meeting? Why is the development effort more relevant for the promised dates than the testing efforts? Raise concerns about testing and the quality of the product. The latter might hide behind such stupid things as team morale or motivation. Notice hidden assumptions and left-out communication. These are most likely to hit back at you as a boomerang.
Start reading the concept documents as early as possible. Help your developers, pair with them, try to understand the code. Indeed this may seem difficult with particular developers or organizational cultures, but pairing with a developer may build trust. You provide the earliest feedback possible by then. The same goes for document reviews. You need not to sit beneath the writer of that document, but she will appreciate timely feedback on her documents. Get in contact with your customer and customer proxies. Try to reach a common understanding of the business domain in your team as early as possible. There are many facets how to get pro-active. Play around with what fits your context best and reflect on it in order to improve.
This may sound silly, but you should talk to your customer, to your developers, to your managers. Involve colleagues which work remotely. Get in touch with anyone holding informations you might need, and everyone needing informations from you. Talk to technical support as early as possible. Talk to your customer. Go out, walk in their shoes for some weeks and learn about the business. You will need this experience in order to get to know the value of the software you’re going to ship to them.
Make progress transparent. Make testing efforts transparent. Show what you have, but leave out interpretations about the numbers. For proper management to take corrective decisions, they will need the informations you have. Of course, you can influence the decisions by making interpretations or manipulating the numbers, but note that the boomerang is likely to hit back at you.
Take time for recreation
Take time for recreation. You will need it. Don’t burn your energy right from the start. Instead keep a steady and continuous pace. You serve your customer, your project and your team best if you get to work fresh and awake. Work out on your work-life balance. You will need it to get new innovative ideas and realize about your current course.
These are just some vague hints and ideas that I came up with. Most of them are controversial, and recently I have argued about one of them about it applicability in all contexts. Most of the time I try to use these practices intuitionally without thinking over it. Sometimes I skip my journal. Be thoughtful about your course, reflect over it, try small improvements, and watch the results. In order to learn about your current direction, you need to take careful steps – just like a small child learning to walk. Over time you might get experienced with your new position and like to work with people. The biggest payoffs are team members that engagingly work for the teams success. These occasions might be rare, but they are no less worth the effort.