5 simple tips to keep testing simple

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.

Tips to keep testing simple- building bricks

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

tips to keep testing simple- 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!


About PractiTest

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.


4 Responses to 5 simple tips to keep testing simple

  1. Mauri Edo October 3, 2012 at 10:23 pm #

    Dear Joel, I confess: I made testing complicated.

    I refer to this in the past tense, not because I have overcome this huge problem, but I’d like to think I’m in the path to do so. The first step has been realising about it, second one has been (and is, right now) being honest, accepting it and saying it out. Now I am ready to get better. Now I am ready to think about ways to simplify my testing tasks and duties.

    Why I did that? Because I had no technical background and felt threatened by an increasingly technical environment. This caused me being opaque in my job, and claim for the high difficult of the things I did, that nobody knew which they were.

    But complexity (fake or real) tends to lead to slowness, and this makes you look like a bottleneck, so eyes are put on you to solve that issue (or somebody will solve that for you), this may reveal that your complexity is fake.

    I was kindly warned that my testing was turning to be a bottleneck and given a new teammate, to be teached about that complex stuff I was doing. This was the U-Turn for me, I started teaching my new colleague with plenty of transparence, highlighting pros and cons of my current approach, being honest about complexity, about my non-technical background, about bottlenecks… and suddenly we were thinking together on how to solve that issues and deliver better quality and simply, until now (and hopefully more to come!).

    Specific things we are doing to get things simpler:

    In a personal level, I started fighting my non-technical background, to beat the reason that made me be opaque, so that I don’t feel tempted to be like this anymore.

    On a daily basis, I watch constantly what we two are doing and why, to detect blocking situations, tasks that take too long to be done… Once a “deadlock” is identified, a brainstorming is performed (either personally or in team) to come up with ideas that may help beat this situation. Detection is paramount.

    Specifically on testing…

    * We try to be present early in the development cycle, if possible in the analysis phase, if possible in the requirements collection with the stakeholders, discussing specifications, and thinking about what to test and how early in the cycle.

    * We have no “traditional” test cases. Test documentation is mostly mindmaps, created per project (easy to create, easy to grow up, not need to reuse as they are easily created and next time you’ll need to test a feature it will be different, so rethink about it!).

    * I borrowed a great idea from Darren McMillan (www.bettertesting.co.uk) named “show and tell” and turned into the following: Once the layout of the test plan is made, we explain it to the developers in an informal meeting at the tester’s desk, so the developer can provide insights about it, whether is complete or not, whether it can be improved or it is too much… Sometimes bugs arise in this phase, way before the tester starts actually testing, which is great 🙂

    * We have three long scripted “traditional” test cases. The top critical ones. These tests have a separated environment which is always ready to be used for these executions (versions, apps, even test data). These tests are executed in every sprint/iteration/project, when release is ready. We won’t automate this, cause they cost us 15 minutes to be executed manually (as the environment is ready) and they are so critical that I want the seven senses of a human tester in them.

    * Concretely in automation, we splitted up our use cases / user stories into atoms, simpler and smaller use cases, easier to prepare test data for them, be automated and maintained.

    I am not saying these are correct practices, I like to think about them as first steps in a continuous testing improvement path, but as a matter or fact, the testing area is not seen as a bottleneck anymore, one year after.

    Now I am fighting against regression testing, that takes us too much time, to get it done simpler. Hope to start winning this battle as well!

    Thanks for a great post, a great blog and a great mindset.


  2. Thanh Huynh October 4, 2012 at 8:24 am #

    Thanks Joel for the another great post.

  3. joelmonte October 10, 2012 at 8:29 am #

    Hey Mauri,

    First of all, and as it was posted also on twitter by a couple of people, you just wrote a whole post as a reply to mine… thanks! 🙂

    You need to proud of the process you are undertaking, it takes real guts and courage to accept that you have important things to improve, and you are doing this in an exemplarily way.

    Like you I was a non-technical tester at first, and I remember trying to make my work seem complex to hide the fact that I didn’t know how to improve it technically. My suggestion here, other than the great stuff you mentioned above, is to understand that gaining technical abilities is like any other process, you start slow and increase constantly and surely. I remember that I started with a book, following it step by step, and before I knew it I was writing code (not to complex!) and most importantly I was able to enter into real technical dialogues with the rest of my testing team and my developers… The first 3-5 steps are the hard ones, from then on it gets easier.

    I also liked the idea you brought forward about the “show and tell”. I think many of us do it informally, but by making this part of your process you are gaining a lot and most importantly you are introducing your developers “head-first” into the testing process. Good move!

    In short, good luck on your improvement process. It sounds like you are on the right track already!




  1. Why Mobile Testing is So Hard and How to Make it Easier — Neotys Testing Roundup - November 22, 2017

    […] 4. Five Simple Tips to Keep Testing Simple […]

Leave a Reply