I’d like to thank my friend Kobi Halperin for the comment he left on my last post that prompted me to write this one with some concrete examples of things you can do (as a tester, a test manager, or as any other type of service provider) to make your job simpler and more efficient.
A simple approach
I think that a lot of my approach is directly derived from my Agile way of looking at work.
I don’t intend to sound like an expert on making things simpler (my wife would even say that I always make simple things complicated!), but I like to think that my approach to managing testing projects comes from experience and boils down to working as straightforward and simply as possible.
Basically I follow a small number of principles to help me organize the work of my team, making sense of the mess caused in today’s working environment characterised by the chaotic “right-here right-now” syndrome.
But enough chatter… Here are my 5 simple tips to help you keep your testing simple:
1. Divide and conquer
There are almost no real complex tasks, as long as you are willing to look for ways to break them into smaller and simpler components.
Many times I meet QA managers who explain to me how they manage their tests using a small number of (very long) excel sheets or wiki pages. When I ask them why do they work this way they explain to me that they started with small documents that grew over time…
One of the first pieces of advice I give these managers is to divide and conquer. By breaking down their very long and complex testing procedures into smaller and more modular test cases, they can gain flexibility and achieve faster and more accurate coverage.
But this advice is not only good for the size of test cases. If you look into any testing tasks and break it down into smaller testing tasks then you will be able to manage your team more efficiently and provide better visibility to your internal customers.
Let me use a specially hard example that people always use to explain why some tasks cannot be run as modular activities – Load Testing.
If instead of scheduling all the load testing activities towards the end of the test plan (based on the premise that you should tests only once your whole end-to-end system can be tested for the performance and correct response time) you schedule smaller and more focused load testing sessions on specific components during the development process, you will be able to find issues faster and without the need to run complex load scenarios and even more complex analysis operations to find the actual bottlenecks.
My experience shows that by running more focused load sessions you will spend less time testing overall and reach better results than by working based on more traditional – once all is in place – scenarios.
The same goes for any testing activity, break your complex testing operations into smaller tasks and try to run them as soon as possible. This will help you to find the issues fast and help your developers solve them even faster.
2. Keep your eye on the “important” ball/s at all times
Managing any services organization is always about juggling tasks (and yes, testing is a service). You have many things that need to be done and only a small number of resources to do them. No matter how much you try, you will not be able to do everything, specially not at the same time, and never with the level of coverage/thoroughness/attention you intended at first.
Once you understand this it becomes trivial that at any given time you can only focus your attention on a limited number of tasks. So it is better to have a good definition of what are the important tasks that you want to focus on, and make sure all your team is in the same page with you.
A practical idea is to make sure that during your weekly QA meeting (if you don’t have a weekly meeting with your team then stop reading this post and set up a recurring meeting NOW, it will be the most valuable thing you do today!) have a whiteboard handy and each week make sure you write down the important tasks or things that should be on everyone’s radar.
Give your team the chance to comment on these tasks (or any they think should be there) and make sure you are not missing something important that they know and you don’t.
Leave the list in a place that everyone can see – not an email!
You can even start each week’s session by going over the list from the previous week and catching up on the events that happened around these tasks.
BTW, regarding the “juggling balls” analogy, an important part of it is to realize that you will not be able to keep all the balls in the air. At one time or another you will reach your limit and some of the other balls just bounce… It’s a fact of life and of Test management.
3. Categorize tasks based on Importance, Complexity and Last Start Date
Directly related to the previous point, is the need to be able to categorize and prioritize your tasks. This is the best way (the only way?) to know what is important and what tasks will be left to fall.
After working with many parameters, wighted algorithms, etc. I know use a simple method where each one of my tasks (I am talking about the smaller testing tasks, and not of the very big tasks your Project Manager is always talking about) has 3 individual and unrelated parameters:
I) Importance – What is the business importance or the priority your company gives to this task? Would it be risky if you don’t run this test? – High / Medium / Low.
II) Testing Complexity – What is the complexity level of the tests to be run? This parameters incorporates the difficulty to test as well as whether this test can be done by any tester/developer or only by an experienced tester.
III) Last Test Start Date – An important parameter that will reflect when is the latest you can run this test and still be relevant for your project.
These 3 parameters won’t give you a calculated index or any way of automatically deducing what tasks should you be doing or when. I personally don’t believe in these algorithms mainly because reality is constantly shifting in our type of projects, but they will help you to sort and filter your task backlog and make sure you always know what to focus at what time.
Remember that as a Manager, the task of managing cannot be delegated to any algorithm 🙂
4. Learn to say NO
Wow, this is a hard one! Maybe the hardest one in the list.
You need to learn how to say to No, and also when to inform your customers that you cannot do something that you previously said you would do.
As I stated before, the reality of our projects is that they are in constant change (I remember someone once saying that the only stable part of our projects is change itself!), and as so you will need to be flexible and also to teach your internal customers that this is the reality of the game.
The math is simple: If you pull the blanket on one side of the bed then someone will be left out on the other side…
Stop committing to tasks you know up front you cannot perform, and start updating your users as soon as you understand you will not be able to perform a task that you previously committed to do.
Timely information is the key to making the correct decisions and compromises.
5. Give full visibility into your work
Hand in hand with prioritizing and saying NO comes the practice of providing visibility to all your work and tasks, as well as to the prioritization and the changes affecting your work.
Some managers think that if they “show all their cards” they loose part of their power, their flexibility and the ability to make thrir own decisions. This could not be farther from the truth!
By working in full transparency with your customers and peers you will show how professional your work really is. You will also allow them to provide inputs that will help you make better decisions for your team and for the success of your project and your company.
Do you have any other ideas or tips?
Transparency and sharing is the key to growing and improving.
If you have any other simplifying ideas share them with us!
Practitest is an end-to-end test management tool, that gives you control of the entire testing process - from manual testing to automated testing and CI.
Designed for testers by testers, PractiTest can be customized to your team's ever-changing needs.
With fast professional and methodological support, you can make the most of your time and release products quickly and successfully to meet your user’s needs.