Key practices for Software Test Managers

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

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.

Be pro-active

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.

Collaborate

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.

Transparency

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.

Conclusion

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.

  • Print
  • Twitter
  • LinkedIn
  • Google Bookmarks

6 thoughts on “Key practices for Software Test Managers”

  1. Markus,

    Good tips. I would also recommend that Test Managers educate themselves about software test design methods such as pairwise and combinatorial test design methods. See, e.g.: the 7-minute video overview I posted on my blog on Oct. 20, 2009 on these techniques. They will often reduce the amount of time it takes to design test cases by 30-40% and will often also double the amount of defects found per tester hour.

    I also highly recommend Lee Copeland’s book on Test Design techniques.

    – Justin Hunter
    Blog: http://hexawise.wordpress.com
    Company: http://hexawise.com
    New Testing Forum: http://testing.stackexchange.com

    1. Good tips, Justin. Personally I left out the personal development through several learning techniques since I believe it’s a core value of my professional life. If I’m stop learning, I’ll be dead. I thought over this very well, and think that I will be striving to go into the craftsmanship movement with that blog entry. At least your comment made me aware of yet another book, I might want to read (besides the 10 I have on my shelf and the 14 I have on my orderlist at amazon – so much to read, so few time).

  2. Hi Markus,

    I really like this list. It’s realistic too. I think you are right to look at the person and their attitudes/skills than simply a list of technical abilities and test related training material.

    With this list you’ve made the most important point anyone can about software testing. It is all about the people. It is about their personality not the number of tools of skills they possess (as such). Good people, with a passion to learn and a fire in their belly are valuable. Essential even. And they will learn anything they need to.

    And you are right. There is no need to mention personal test skills development. If this is not something they do by default, then your entire list will make no sense to them anyway.

    Great post

    Rob..

    1. Rob, I think your “What tester are you?” really completes the view here. Unintentionally I realized that I did not only cover aspects of a Software Test Managers, but also a great deal of tester’s practices who are involved in a leading role in a project. Reflecting over the particular tester type would also make sense. And of course, from a tester in a leading role I would expect to know that she is constantly working on improving her own skills. I’m glad you liked my little write-up.

  3. Good post. I think that Manager technicall skills are important to convince team about his idea or advice.
    Other point, to improve process execution I propose this software: mytesting bank.
    It follows CMMI certification process.

Leave a Reply

Your email address will not be published. Required fields are marked *