First Time Quality Engineer – 2010

Posted on November 13, 2010 by Catalin Anastasoaie

First Time Quality Engineer, one of the projects I really enjoy working on, has reach its 3rd anniversary. But before saying more on this year edition let me tell a little about the project overall.

First Time QE, as we call it, is free course offered by a few passionate romanian software testers to students and fresh grads who want to find out more about software testing and how it’s made. The course is spread through out four days of presentations and exercises and its main purpose is to introduce the participants to the fundaments of software testing. And we try to do this in an interactive and fun environment (or at least we do our best to make this true).

This year I was the person driving the entire process, and believe me this is not an easy task, at least not as easy as I thought it will be when I rushed myself in accepting the challenge. As we speak there are 2 more days until the event will begin and 3 more days till the day when I will have to do my best in front of 12 people, eager to learn everything about software testing. (PS: I am very nervous and I still haven’t finished my presentation)

More info on this year’s edition you can find here (!Warning – the text is written in Romanian) - First Time Quality Engineer – 2010

Also, the list with the 12 participants can be found at the following location (also written in Romanian): http://edu.myadobe.ro/2010/11/13/participantii-la-first-time-qe-2010/

Stay tunned for a retrospective and also for the How it’s made story.

When to ask the questions

Posted on July 14, 2010 by Catalin Anastasoaie

Discovering your product and finding out what is the actual need that it is trying to solve and who will be the users that will use it is one of the keys to success.

With that being said, take time in discovering your product. Don’t jump over this step just because you think that it will win you more time for testing. Not knowing what your product is about and how will it be used and, most importantly, by whom will always cause you trouble.

Software testing is not about funding all the bugs in your product, software testing is about the important bugs as soon as possible. And in order to do this you have to spend some time first in understanding what exactly is it that you need to test and how.

I’m writing about this idea because I think that this is one of the most common mistakes testers do and because I, as a tester, did a lot in the past (and still doing it from time to time). With my mind set on findings bugs fast I was assaulting the product with the first idea that was popping out in my mind on how to test it. But not to far from where I was starting I was realizing that I am running straight towards a dead end.

When testing without a mission a lot of time is spent in searching and learning new things about different aspects of the product but not so much in finding bugs within the actual product. This isn’t always a bad thing but if your time is limited then spending it all just on learning might not be such a wise thing to do.

Having a goal helps me to canalize all my energy towards reaching it and saves me from spending time searching for information that is not relevant in the context of my goal. A clear mission also gives me a structure on which I can rely and to which I can always come back for validation/verification.

Testing with a mission will also help you in answering questions like: How much of the product did you test? What areas of the product did you covered? How long until you will finish?

Contributing to DailyTestingTip

Posted on June 27, 2010 by Catalin Anastasoaie

It all started 2 months ago when I have first discovered the @dailytestingtip project and decided to contribute to it.

But before going thru my story let me tell you a little about this project and how it works.

The DailyTestingTip project has been started by Anne-Marie Charrett (http://mavericktester.com) and, quoting from the Daily Testing Tip website (http://www.dailytestingtip.com), “… is a group of dedicated testers who have come together to bring you little gems of testing goodness to your Twitter account.”

How does it works?

With the exception of Tuesday and the weekends, each weekday has a person assigned to it who is responsible of sharing a testing tip with the community. The tip is sent from the @dailytestingtip twitter account 3 times per day at different hours in order reach all the major time zones.

From the moment you enroll yourself in the project you have to contribute with a testing tip per week for the next 6 weeks.

Tuesday, is the day of week reserved for Tag Tuesday when people all over the glob can share their testing tips on twitter by simply adding the #dttip tag to their tweet.

How can I subscribe to these tips?

It’s easy, you just have to follow http://twitter.com/dailytestingtip

Want to contribute to the project?

If you would like to contribute to dailytestingtip and believe you can consistenly supply a daily testing tip just send a direct message to @dailytestingtip from your twitter account.

Continue reading →

Failing testing by being Precise vs. Accurate

Posted on June 8, 2010 by Catalin Anastasoaie

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.

We 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 →