Have you ever realized how much out of your day at work (as a tester) you are spending on real testing? You would be surprised to know if you calculate these hours. Let me help you out;

First of all, out of 24 hours let’s say you spend 12 for the work and 12 at home. Out of that 12 hours remove the average commute time from home to your office that could be around 2 hours depending on the distance you live from the office and the mode of transportation you use. That leaves, 10 hours. Remove, 1 for the lunch and some good 30 minutes for tea and coffee brakes, and if you are a smoker then remove 30 more minutes. That leaves 7 hours purely for Testing, right? Wrong!

Here is what I have in my pot; you can determine yours at your end:

- Computer Startup, email checking – 20 to 30 minutes – depending on the responses and urgency it required (We now have 6 hours 30 minutes)
- You use a centralized issue tracking then you need to gather up or accumulate your daily assigned tasks – 20 minutes added here (We now have 6 hours 10 minutes)

– Includes – In hand, work done, and coming up at your end.

- You have a separate testing environment – then you need to connect, reconnect and disconnect a lot of DBs from different clients.
- If you are not working on 1 product then add up the configuration timings for the product wise domains. (1 hour to 2 hours are added here) (we have 4 hours and 10 minutes).
- We have to send a request to the networks to restore client databases at the DB servers (Oracle, Sybase, and SQL) so the emailing and then the response, and then checking is our entire job. (Make it 3 hours and 10 minutes).
- You do automation? Then you do scripting and recording as well, you also maintain the changes in the system in accordance to your scripts – right? Then add a good 2 hours for that activity, which is not testing btw. (Make it 1 Hour and 10 minutes) (That is for test automation if you into it!)
- You have to do coordination meetings to understand new changes and enhancements? Well, weekly average sets that up 20 minutes at least for a live project (Make it 50 minutes) for testing.


Well, in reality it is actually an inflation deflation situation, where you adjust the timings alongside parallel running tasks and then see where you can readjust your schedules. I have done this exercise on a Day Scale, whereas if you put this up on a larger weekly scale, you will come up with a percentage of actual testing time. In addition you can also draw out the resource and task allocation throughout the week and come up with the areas which you can deflate or inflate to get the most out of the week.


What you actually need to do is to divide the day into several smaller 30 minutes sessions, and then see if you can adjust your testing time there. If you can do a full day testing (a perfect world scenario) then you will need to stop some critical maintenance work some point. So it will eventually pile up and gets you somewhere along the week.

This is a pure context driven situation, I know for a few of us maybe the situation is different and they are getting time for testing, then is it coming up to you in a continuous non-stop form? Or if you don’t have the assignments, nor any maintenance works, then what are you doing within those hours?

A lot of this workload is also due to the time testers spend on things which should have been done at the developer or the support team level. For example, an issue which seems like a bug at the moment but was not identified as a technical support matter is forwarded to the testing team, and one must realize that once it is in your pot, it is yours so the time Testing team will spend on investigation to determine that is it a bug or not will be added in the administration work.


On daily basis we spend resources and time on tasks which are not related to testing at all, but do make sure to give us that extra time out of the compressed day to test, discover and investigate bugs. You can also use these reports and matrices to enlighten the adjacent teams such as:

- Technical Support issues reported as bugs

- Developers Load

- Open Issues at the development

- Re-Works

- A metrics showing overall daily reporting of Bugs, Changes and

- Enhancements

Several other areas can be addressed to draw down the management on realization, such as coordination meetings for new enhancements and changes, resources allocation to projects as per their workloads and time line adjustments.

So, what are your intentions for the week ahead?

Keep us posted if you realize that you can spend more time on Bug investigation and testing @OuttaBoxPK, we would love to hear from you and then publish it on our blog as well!


Arslan Ali is a Software Testing and Training professional; he serves his passion at OuttaBox (www.outtabox.co) as a Training Consultant for various software testing workshops, and also works as a Senior Consultant Information Solutions at Sidat Hyder Morshed Associates – a renowned software solution provided in Pakistan.

Arslan has been around ICT industry past 15 years and have diverse experience in Software Development, Quality Assurance and Business Process implementation.

You can reach him out on twitter @arslan0644.

Share Button