My apologies for my english readers, the following post is written in romanian.

Joi, 7 Iulie 2011, va avea loc prima editie din Tabara de testare (http://tabaradetestare.ro), o initiativa ce-si doreste sa adune cat mai multi oameni care lucreaza in domeniul IT si care vor sa afle mai multe despre ceea ce inseamna testare software (sau software testing) si nu numai.

Vor fi 4 prezentari, fiecare a cate 30 minute, speram noi relevante pentru cei mai multi oameni din sala.

Prezentari:

1. Hello, I’m a tester!
2. Why be a tester?
3. How to demotivate your testers
4. A career in software testing

Locatie:

Intalnirea va avea loc la sediul Adobe Romania, Bd. Timisoara 26Z, cladirea de birouri Anchor Plaza, etajul 9.

Mai multe detalii gasiti pe pagina evenimentului – http://tabaradetestare.ro

Pentru orice lucru legat de Tabara de testare nu ezitati sa lasati un comentariu sau sa-mi scrieti un email.

Did someone ever asked you to test a pen or a pencil? Or, did you ever had the curiosity to see how many test cases can you find for a pen(cil)?

Well, I did! And here is my 101 list of possible test cases for a given pen(cil):

Do you have another one in your mind? Leave a comment with it and I will add it to the list.

Download the PDF containing the entire list – 101 Test Cases for a Pen

Reference:

• To come up with this list I’ve used heuristics, wikipedia and running.

I also want to personally thank my colleague, Mihai Balan, for some of the best images I have ever had in a presentation.

Related Posts:

First Time QE – 2010

Here is a list of 10 things that every tester should NOT do.

You can find all the items bellow as being the reason of many discussions between people lately. I think that it has something to do with the “agile” bubble but I might be wrong. My opinion is that all of them are valid no matter how your team is doing software.

1. Don’t talk to the developers
2. If you do talk to them, and they ask you out for beer, say No
3. Always follow best practices (Come up with a process to resolve another process)
4. Never ask for help when in distress
5. Say No to any new idea that doesn’t come from you
6. Keep everything you know for yourself / Don’t communicate with your colleagues
7. Don’t look into the code
8. Start testing only when you have the complete specification
9. Don’t ask what to look for when testing new features
10. Avoid peer reviews as much as possible (e.g. test documents, test cases, test media)

Leave a comment if you feel like adding your Dont’s to this list …

DISCLAIMER: The list above contains the most commons mistakes made by software testers. You should NOT follow any of it if you care about your project.

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.

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?

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.

Now lets get back to my story:

I started sharing my testing tips thru Tag Tuesday and soon after that I was given the chance to actively contribute to the project. The next thing I know was that I had to provide a testing tip each Thursday for the next 6 weeks (don’t get me wrong here I was more than enthusiastic about this ).

Providing 6 testing tips looks easy but believe me it isn’t as easy as it sounds. The challenge of providing great testing tips and the pressure of the audience has put me in difficulty a few times during the 6 weeks period.

But in the end, the last six weeks were both fun and challenging for me and I really enjoyed the “pressure” of thinking of and sharing the best tips I have.

Now, after 6 weeks, I can only say that I’ve enjoyed it so much that I have enrolled myself for another 6 weeks (with a little bit of luck , Rob Lambert – http://thesocialtester.posterous.com had to pull out from his six weeks contribution). Only that this time I have to provide a tip each Wednesday instead of Thursday.

In the end I would like to congratulate Anne-Marie Charrett (http://mavericktester.com) for her initiative and for being a great driver. And also, I would like to thank her for giving me the opportunity to actively contribute to her project.

Congratulation and my best wishes, Anne!

And if you were wondering what were my 6 testing tips here they are:

Don’t be afraid to fail while exploring new horizons. You’ll be surprised on how many things you could learn on the way.

“Automating chaos creates chaos faster” – plan your automation carefully in order to succeed http://bit.ly/cK6at4 #softwaretesting

Always focus on improving yourself by finding new, better and more productive ways to do your job. #softwaretesting

Ask your developer(s) to give you feedback on your test cases and your test strategy #softwaretesting #testing

Every day you’re asked about your testing. Learn to tell a compelling testing story so that you can get the most out of it #testing

Don’t hesitate to ask the uncomfortable questions. Issues which are not clearly described can be the gateway to others #softwaretesting

Update:

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.

This often makes us overlook important aspects of the product we test, and most of the times this will only make us more precise while losing the accuracy. What can we gain from this? At the end we could say that from one point of view, the one with the idea from which we have started, the product is tested thoroughly.

But if I think about all the products, or features, I have worked on I can say that I have found myself not only once but multiple times, believing that I have tested the product thoroughly and finding at the end the I have missed some important aspects or bugs that could have been covered or found with only a small effort. But with my head deeply buried in the sand I had ears and eyes only for idea I have started with. I was like a racing horse running to the finish line right after the last corner in the last lap.

So what do learn from this? Every time we test something we must have our mind open to new ideas on how to better test the product and create new ones as we learn more and more about the product we are testing.

In the end the accurate factor must be higher than the precise one. There is nothing wrong in being more precise in some aspects and less in others. But it is very wrong to be precise in some aspects and not knowing anything about the others, we lose the accurate factor.

The horse alone will not win you the race.

Question: If you would have only 3 questions to ask in order to find more information that will help you find the locker combination what would they be?

Demonstrating that software testing isn’t as random as it seems

This exercise is inspired from @jbtestpilot‘s(Jon Bach – Software Tester, Consultant – http://jonbox.wordpress.com) passion for playing with lockers to find their combinations and a locker I’ve found at my office, which by the way was use by someone to make a practical joke on one of our colleagues.

The exercise:

The story starts with my brother who had a not so pretty surprise at the end of a practice game with the town’s handball team in which he was playing when he was in high school. His teammates thought that it would be a lot of fun to tie his bicycle to a fence with a locker taken from another teammate who volunteered to give up his locker for the fun of story. Now image the expression of my brother’s face when he saw his bicycle tied to a fence with an unfamiliar/unknown locker!  :-)

The locker you have in your hands is the locker I am talking about and as you can see my brother didn’t managed to find the right combination and so he chose the easy way to unlock it.

Now your goal is to have fun while trying to figure out the combination lock.

Clues:

- At the time the story was happening my brother was in the 10^th grade

- There were 15 members in the team

- The teammates were all between 15 and 18 years old at that time

- The practical joke happened at one of the town’s handball team practice game

Debriefing:

At the end of the exercise we will analyze the used combinations and the questions that have been asked to resolve the puzzle. The goal of this exercise is to demonstrate that testing is not so random as it seems and that it is based on a strong cognitive process.

More Clues:

- Most people don’t use hard to remember or to figure out combinations.

- For setting their lockers people often use information from their own personal life or their own families life.

- Try to put yourself in the position of the locker owner and think of what code you would have for unlocking it.

——-

What do we have to learn from this?

Same as in the case of this puzzle, asking the right questions in order to find out more about the software you are testing and it’s context is THE key to software testing.