Failing testing by being Precise vs. Accurate

I have been to a course about estimations in the past and the first thing that pops out in my mind when I think about that course is that estimations are not precise, never were and never will be. There are so many things that could influence the timing of a project that every time we are under the impression that we have nailed it down we are taken by surprise by something we have never thought off (and this is valid for any kind of projects not only software).

But this post will not be about estimations; it will be about being precise vs. accurate in software testing.

We often tend to think that our goal is to learn to be precise when actually we really should start focusing more on learning how to be more accurate. I know that this could look like something that has nothing to do with software testing but just think for a moment about the way we are testing software.

High PrecisionWe start with an idea (actually, we start with someone telling that it is a new product to test in town but we will jump over this step)about how to start testing a product and without knowing it the next second we are up to our neck in that idea, trying to squeeze it as hard as we can to get more and more from it and when we get to the end we squeeze it one more time just to make sure that we haven’t forget something.

Continue reading

The Daily 5 Minutes (D5M) for the rest of us

I was reading about the Daily 5 Minutes (D5M) on Talking Story with Rosa Say blog and immediately something crossed my mind.

Why don’t we as individual contributors, people that work in the same domain (in my case software testing), on the same position or level in an organization don’t make this a common thing, a daily must-have task? I think that if we could surpass the “ego-centric” barriers and stop seing this as a threat we could learn a lot from what, how and why others are doing around us.

Not only that it would help us to better communicate with our colleagues but it would also help us build a stronger connection between we and them, a connection based or mutual respect and trust. Just think about all the information we could gain from one another (from our testing matees or colleagues you named it) if we would spend 5 minutes each day from our time to ask one of our colleagues what was the last thing they tested and what did they found and how did they found it. By doing this we could obtain insights in how others see and understand a product or a small feature or even an entire system and adding them to our present set of skills /insights can help us uncover hidden parts of your imagination.

I definitely must add this to my personal TODO list and give it a shot, who knows what it may uncover.

If they can do it so can we!

Yesterday, as I was scanning the internet for interesting stuff to read about I discovered the following video that convinced me that I really need to start trying out pair testing. The video shows 2 people playing a song at the time in pair on a guitar and not only that they managed to avoid each others fingers but they end up doing a pretty good job.

Until now I’ve only read or listened about the concept of pair testing and the benefits that could come out from it from different people but didn’t had the chance to try it out. The reasons why I didn’t try it out yet are found in any article, book or blog post that talks about pair testing – each time we thought about trying it there were the neverending “buts” that kept us from doing it: “but we are in the ending game”, “but we have to finish the certification”, “but etc”.
Now, after sawing this video I decided that I must take action and put “Try pairing w/ a colleague to test a feature” on my TODO list for the following week. All I have to do now is to search for some guidelines and then go and put them in practice.
I will come back with a another post about the learnings.
PS: This was my first blog post :) Yuppy! sharing my thoughts with the rest of world is a great step for me in improving myself as a tester.