What the investigation revealed...

I wondered what I did in a "typical" day as a tester, so I investigated my activities. I found out a few interesting things about me, about what I do...

The first thing I found is that I process things while I sleep and often wake up and write them down. Sometimes this is related to testing and sometimes it is of a more personal light... I can go to sleep with a puzzle in my head and wake up with the answer in the morning, and if not the answer, at least another piece of it. I like that this happens... even if I am not completely sure of why it does...

The second thing I found is that I test people and things all day long. I sometimes wake my children with tests... I might say something completely off base to check their "balance"... I might simply ask a question that makes them have to think first thing in the morning... I find this testing of my girls makes them sharper than average, more observant of words and body language. I guess, in a way, this type of testing is teaching.

Aside from my children, I often test my co-workers by taking what they say either literally or off the beaten path and repeating it back to them in a way that they see what they said differently. (This is also quite fun, especially when others play along.) I also test people I run into every day, such as the cashiers at the local stores. They may tell me how much money I saved making a purchase, and I will tell them I saved nothing, I spent such and such amount... The response is generally a look that says "I never thought of that" (the response/expression we likely all give when we find out we are looking at something one-sided/one-way).

The third thing I found is that I test for longer periods of time than I thought. I connected the fact that as I document, so do I test. I never document anything about the application/system/product in test without having it open and without "doing" what I am documenting. The same is true when I test documentation that is given to me to check for the application/system/product - such as help files/knowledge base write ups/user guides. This is still testing and still reveals bugs that I may have overlooked, were implemented incorrectly, or documented incorrectly.

The fourth thing I found is that I constantly test the processes. I constantly ask "where, what, why, when, and how" about all of the things I do. When I say "the processes" I include what I do when I test. This proves to me that I can never completely test anything... Why is that? Because one day I may be focused on performance, the next day I may be very nit-picky and go after the small things that seem to pose usability issues. I may decide I am going through "good book withdrawals" and concentrate on being an editor for the day by reading through documentation or checking out the overall look of the application/product/system.

Because I can come into testing with any one of many "persona's" on any given day, and because the application/product/system continues to evolve, I may find something six months later that I would have found earlier if I had my certain "test face" on that day.

The fifth thing that I found (and the final that I will mention here), is that I cannot actually track what I do in a day to a perfect measure. In fact, I have found that attempting to do so actually cuts my creativity and time spent testing.

How can I track my time spent on any one activity when it is actually only an estimate? How can I estimate the time it takes to test something when I could be the nit-picker one day and the performance tester the next? I should say, "how can I accurately" give time to these things? If I go to sleep at night and wake up and jot down on paper three things I need to test, do I write the time down and add that to the time spent testing? And what about the time I was sleeping... how do I know how long I was processing during that time?

Maybe I am just "testing" this part of what I do more than I am testing the others because those activities are so natural that I don't really have to think about them. Maybe it is because I have an aversion to measuring what I do. Maybe it is because I have a problem with the gap between "estimated" time spent versus "actual" time spent because of the fact that it is not going to be exact. Maybe I am over analyzing the measurement factor because of my experience in a 10Th grade algebra class...

Through this investigation, I have pretty much concluded that while there are typical activities done nearly every day in my job, there is really not a typical day. I believe this is one of the reasons that I love testing, it is not typical, it is ever-evolving, and it is challenging.

And I just received Michael Bolton's "highly sporadic newsletter", which just so happens to have "Project Estimation and Black Swans" as one of the topics. I will begin reading the "five part blog series" tonight. Talk about timing :)

What do I do in a "typical" day?

There will be changes to some processes for the team I work with. Since the changes will impact the time I spend testing, they got me to thinking about what it is I do in a "typical" day.

With thinking, along comes a bit of research... I wondered if anyone else has attempted to sum up a typical day in software testing. I found
A Day in the Life of a Tester, and read through it quickly.

In this description of a typical tester's day, about 4 hours and 40 minutes was spent actually testing - of course no distractions are included in this time frame. No visitors or phone calls or interruptions.

Also no meetings or documentation are included in this "typical" day of a tester....

This article on How Does a Software Tester Spend a Workday? really floored me. It says, "software testers spend most of their working days removing bugs and defects from programs". Yes, it seriously says that...

Google aside, time to actually think about the subject at hand, what
activities do I do in a "typical" day as a software tester... And how much time do I actually get to spend testing?

I think I shall investigate this...