You Were Not Hired to Find Bugs!
I have said this a number of times in the past, if your management thinks that your job is to find all the bugs in the product and deliver a defect-free release at the end of the process, I strongly recommend you find different management...
If you are lucky and work at a smart company, then the main objective of your work as a tester and specially as a test manager will be better described as follows:
To provide stakeholders with visibility into the status of the product and process, so they can make the correct decisions.
Don't get me wrong, we are still testing and reporting on our findings, but in this definition the focus is not on the product or even on the testing, it is placed on the stakeholders and the decisions they need to make (based on the information we provide them).
In order to explain this test management approach better, I want to start by giving it a name:
Decision Driven Test Management
Many experienced test managers already use DDTM or Decision Driven Test Management unconsciously in one level or another. In lots of ways it is the logical way to work, and many of us adopt this approach even without noticing it.
But I don't recall someone defining it explicitly or teaching it publicly yet, and so what I want to do is to help understand how we can all use this approach consciously to improve the value of our test management work, and to teach it to those who are still moving towards this methodology but have not yet made the jump.
In a Nutshell: Start From the People and Their Decisions, Then Plan Your Tests Accordingly
Most people assume that when you start a testing project you begin by learning the product, then you plan the tests you want to run, and then you create a work plan or schedule.
Well... this is wrong!
The truth is that most projects usually set their release dates and internal milestones long before they start thinking about testing.
And so you will usually see an experienced test manager start a project by learning and understanding these dates and milestones, only then will he or she move forward to learn the product, and then based on the understanding of the complete situation will he or she plan the work schedule.
The reason we look at the project plan first is that by learning our milestones we also learn a lot about the decisions that need to be made as part of the process, and so we are starting by understanding what information will be required from us and when will this information be needed, and then we can plan our testing accordingly.
6 Tips to Master DDTM
It is not always easy to grasp the small things that experienced managers do without even noticing, so let me try and explain the simple yet important principles behind this approach to test planning and test management.
What are the most important things you need to do to work correctly and efficiently with DDTM?
1. Map Your Stakeholders and Listen Carefully to Their Needs
Start by understanding who you are working for; and no, it is not (mainly) the end user!
Make a list of your project stakeholders and then prioritize this list based on who is more important to the project and to you. Then go and talk to them to understand what they need to know as part of the project.
Typical stakeholders are Product, Project and Release Managers; Development Leads and even Developers; sometimes your circle will be broader and it may include VP's of Marketing, Services, Supports and even Sales; and in some occasions when the project is very important or when the company is relatively small it can even include the CEO.
Each time you will have different stakeholders and you will need to make an effort to find all of them or at least the most important ones.
From my experience, the biggest challenge is that these people are not really aware of what information they need, so you will need to work with them to define these needs.
2. Plan Tests and Deliverables Based On the Information Needs
Take the information needs of your stakeholders and translate this into concrete information deliverables. You are looking here to plan your Metrics, Reports, Dashboards, etc.
Schedule these deliverables based on when they will be needed, many times these "delivery dates" are the milestones already defined in your project.
This will give you the internal milestone plan for your testing team.
3. Plan Your Tests According to Your Information Needs, Understand What Information You Want to Capture Up-front
Now you know what reports, dashboards, statistics and additional information you need to provide and when. This is what you need to plan your testing operations.
Make sure to explain to your testers why they are testing and what information to look for. Many times we feel that our junior testers do not care why they are running the tests we give them, and this is one of the worst mistakes to make.
Your testers are intelligent (and if they are not then replace them!) so make them part of your "Testing Intelligence Team" and help them bring forward the information that will help your team make the right decisions.
Sometimes these findings cannot be planned, and they will depend on the avid eye of a smart tester to be found and reported in time!
4. Be Ready to Change and Improvise
Fact No. 1: You will not have enough time to test everything you need to test in order to provide the information that is required.
Fact No. 2: Even if you manage to plan your schedule perfectly to fit every need known at the beginning of the project. As your project progresses, things will change and more stakeholders will require more information from you.
If this is the case, then you need to keep your eye on the ball all the time, and don't lose your mind when you realize that people have new questions, and that you will need to alter and improvise your plans in order to keep up.
People are not bad because they change their minds or modify their requests!
Change is the only constant parameter in most projects. :-) Embrace change, you have no other alternative.
5. Stream Information Via Multiple Channels
Here are 2 additional and important things to remember:
Different people absorb data differently.
Sometimes you will need to present the same information twice or tree times before it is absorbed and understood by your busy stakeholders.
It is more effective to use multiple channels to stream your information, and so help your goal of supporting the decision-making process.
Use Dashboards, Kitchen Monitors, Email Reports, Meetings, etc to pass along the information needs of your stakeholders.
6. Make This Work Iterative, Improve With Each Iteration
The first time you try this approach you will fail poorly!
The second time you will feel that you were almost able to help but not there 100%...
The third time you will start seeing a difference in the approach of your company and stakeholders towards your testing. They will begin noticing that you are proactively coming with the information they need.
From then on, they will come to you and ask you to be a more active part of the decision making circles.
This type of project, specially at the beginning, will be a continuous improvement effort. Knowing this may help you cope with it better :-)
* Bonus tip: Remember you are providing a service.
For some reason some of my best testers have been people who worked previously either selling things or waiting tables, really!!
Why? I think this is because they understand that they need to provide a service and so the "customer" is always the most important thing in their work.
I love geeks and computers, they are some of my best friends in life :-) But when you work in testing you need to have soft skills and not only analytical skills.
Do You Use DDTM in Your Process? Share Your Tips!
As I mentioned before, I am sure that many of you already work this way without even noticing it.
If you do, please go ahead and share with us your experience!
What works best, and what do you do to make it better in your team?
Leave your comment and help all of us improve our test management approach!