Must Testers know how to Program?

One of the most common question that rises when talking to testers in an Agile context is
“Does testers have to posses programming skills in an agile team?”
For a long time my answer to that was no, since testing includes vast number of activities which doesn’t require programming skill there will always be room for testers who cant program.
However I think that I was mistaken. these days I would expect anyone who claims the title of a professional tester to posses some level of programming skills. 

Testers who cant program are obsolete.

This fact can not longer be ignored.  As automation gains a firm hold in our industry a tester must be able to significantly contribute to all automation effort. And while certainly one can contribute to this effort without knowing how to program, the room for these is relatively limited.
Yes, even 10 or twenty years from now our industry will still have a large number of testers who cant program. The same way that even today there are still professional Cobol programmer or programmers who cant do object oriented programming.  But I would expect that this will be the minority

Testers who cant program – CATCH UP

If you want to stay valuable in the market, start learning the basic skills of programming today. no, I don’t think you will need to become an expert top notch developer (not that there’s nothing wrong with that). The actual skill level required in order to become a productive test automation engineer (i.e. significantly contribute to automation effort) is lower than that. But Unless you will start to aquire these skills soon you will find very hard to find new open positions.
Here’s an interesting post that backup these claims with some concrete data. And while I don’t consider this in any way as scientific proof or even big enough to indicate anything with significant statistical confidence, it still suggest that   ~80% of testing job posting indicated a programming skill as necessary. Also notice, this post was published as early as 2010.  My personal observation of recent job ads, which is certainly skewed towards Agile culture, suggest that the percentage is even higher.

Bottom line

As a tester you should want to know how to program in at least one major programming language ,in order to decrease the time you will be looking for a new job.

Read more »

Posted in: Agile practices,Agile Testing,Random Thoughts

Agile Practitioners IL– Group meeting #11

On Monday we met again at Kontera offices to hear Guy Nachimson talk about “How to help others take more responsibility”.
In the talk guy explained about a Christopher Avery's Responsibility process. this model deals with how people react and behave when they encounter a problem they need to solve. The model deal with various states that describes how a person reacts:

1. Denial – First reaction is to ignore the problem. it didn’t really happen.
2. Blame – when we cant ignore the problem we look for someone else to blame. “it wasn’t me it was XXX”
3. Justify – when we finish blaming, we then start to look for justification on why this happens. (the situation forced us to do this, things just didn’t let us do something different,…)
4. Shame – after we finish to justify our actions, we understand that it something we did and then we are a shamed that we did this and that
5. Obligation – here we understand that something needs to be done, however we don’t do what we want to do but something we feel we must do.
6. Responsibility – this is the state we want to be. here we take ownership of the problem and use our ability to deal with it and make things better
7. QUIT – sometimes, before we assume responsibility  we choose to give up and just let go.

According to Christopher, this model is quite universal and there is no way skipping this stages, the trick is to recognize where you are and try as much as possible to pass through these stages as fast as possible in order to reach “Responsibility”.

What did occur to me while hearing Guy describe the model, is that this model is not only applicable to individual, but can also describe organization culture. Personally, going over some of the companies I encountered, this model can be used to better describe how the organization as a whole is behaving. The easiest one to spot of course is the Blaming culture.

We finished off the session by doing a nice exercise in which guy used a friendly competition to show how one can better spot where a person might be located in this model by listening to what people are saying. things like:

• “but our group is only 3 people so we need more time” – justification,
• “We should have done XXX” – shame.
• “But we must do YYY” – obligation

All and all a very interesting session, I cant wait for December 17th to hear Christopher Avery himself going in depth into the subject. Two hours is not long enough to really cover this subject

Read more »

Posted in: Agile Management,Agile Practitioners IL,Events

Want to be a speaker at the upcoming Agile Practitioners Conference in Israel?

I’m so pleased to tell you that we will be running the second Agile Practitioners conference at the end of January 2013. If you want to help us make this conference just as great, please help us gather the best content out there. Specifically, if you have a new idea, thought or experience to share   drop at :
http://agilepractitioners2013.com/call-for-papers/
and propose a session for the upcoming event.

If you have any related question feel free to contact me directly – either by posting a question here or at my email: lior at practical-agile dot com.

Read more »

Posted in: Agile Practitioners IL,Events

Why should you become Agile

One word:

I believe that a developer work should be one filled with the joy of creation. When I started out to become a programmer I thought that it would be great. my work will be filled with:

• Joy of creation when working on building a solution to other people problems

• moments of joy when completing new things and releasing them to the market

• moments of satisfaction from work well done

• moments of eureka when I find great solution to difficult problems

• moments of collaboration when I work with my team members to achieve a shared goal

a few years later I found out that:

• its not fun when you finally get your product to the market realizing you just solved the wrong problem

• Its annoying that whatever you are doing always seems to take longer then expected

• its frustrating when you never have enough time to actually complete your work as it should be done

• its not easy to work along other people which are stressed out just like you.

• its disappointing that you never get a chance to learn something new because now is not the right time and we first need to finish.

• its depressing to continuously get a stream of defects on the code you write

• its terrible to work 3 days straight to understand why the system keeps on crashing at your client, when it behaves perfectly ok in your own environment

• its frightening to work on unknown parts of the system not knowing if what you will do will only cause more bugs

So why should you become Agile?

Because being agile is one major step towards bringing the joy back to work:

If you really become Agile, you will gain back the control over what you do and how you do it.

If you really become Agile, you might get the chance to truly collaborate with you’re the rest of your team

If you really become Agile, you will work according to market feedback and needs on the important things first

and if you really become Agile, you just might bring some of the joy back to your work.

Read more »

Posted in: Agile Values

Why should you Learn TDD

One word:

I believe that a developer work should be one filled with the joy of creation. When I started out to become a programmer I thought that it would be great. my work will be filled with:

• Joy of creation when working on building a solution to other people problems
• moments of joy when completing new things and releasing them to the market
• moments of satisfaction from work well done
• moments of eureka when I find great solution to difficult problems
• moments of collaboration when I work with my team members to achieve a shared goal

a few years later I found out that:

• its not fun when you finally get your product to the market realizing you just solved the wrong problem
• Its annoying that whatever you are doing always seems to take longer then expected
• its frustrating when you never have enough time to actually complete your work as it should be done
• its not easy to work along other people which are stressed out just like you.
• its disappointing that you never get a chance to learn something new because now is not the right time and we first need to finish.
• its depressing to continuously get a stream of defects on the code you write
• its terrible to work 3 days straight to understand why the system keeps on crashing at your client, when it behaves perfectly ok in your own environment
• its frightening to work on unknown parts of the system not knowing if what you will do will only cause more bugs

So why should you learn TDD?

Because TDD is one major step towards bringing the joy back to work:

If you do TDD right, many of the stupid defects will go away.

if you do TDD right, your system design will improve making it easier and faster to change

if you do TDD right, you will have a safety net guarding you from mistakes.

and if you do TDD right, you may be able to bring some of the joy back to your work.

Read more »

Posted in: Engineering Practices,TDD