“Introduction to Agile Process Management” Slides

Had great fun last week at the ALM user group meeting. Great audience with great questions and feedback, as well as meeting old and new faces.
For those who missed my presentation, and those who want to refresh their memory, here are the slides:

Read more »

Posted in: Agile Management,Events

Must programmers know how to Test?

I was never asked before if a programmer should know how to test. The underlying assumption is that programmers know hoe to test their own work, and therefore are skilled at testing. Problem is that they are not. And the sad thing is that so far they have managed to get away with it. I’ve been a professional programmer(that is writing code for a living) for more than 10 years, in all the places I’ve worked my managers did ask me if I tested my work. And my answer was always “of course”.  But never was I actually challenged on that. No matter how many bugs were found in my code, no matter how much empirical proof there was that I did a bad job at testing. None of my technical managers ever told me, “please take this work back and test it again, and this time for real”, ever. And never have I seen it happen to any of the other programmer I worked with. I did get work back from time to time with claims that some of the functionality was missing, I did get a lot of bugs to fix. At times it was so bad that my “testing” activity usually only included making sure it compiled executed and didn’t crash on my machine. and that what I called testing.

Programmer who Cant test will become obsolete

As automation gains more hold in our industry people start to expect much more from testing at the unit level. In my last work place doing test reviews was part of our on going process, in fact we probably invested more time in reviewing test code than actual production code. For us it was extremely important to make sure that written code was properly tested (verified) at the unit test level. I expect this is very common to all software teams doing TDD. And while I’m sure many of us just wait  for this weird TDD notion to go away. its my strong believe that it wont. on the contrary latest surveys suggest that as agile is gaining in our industry the necessary engineering practices are also

Programmer – catch up on your testing skills

if you as a programmer want to stay relevant in future markets, you should really start increasing their testing skills. Yes there is still time before testing skill will be listed as one of the mandatory skills in job posting. The growing need for writing automation at all levels, gives a definite advantage (at least in my book) to programmer that has some sort of formal knowledge or experience in testing. (and yes I will need to see some actual proof and will verify such claims during interviews). No I don’t think a programmer should be a professional tester as well (although that might help), but basic concepts of QA, properly designing test suites and understanding that there are more than just unit testing is something I would expect every self respecting programmer to know. In  my limited experience I have found that programmers that posses this knowledge and skills are just better programmers.
And if you want to know how to start here’s something you can try: STARTING TDD – ONE DAY EXPERIMENT

Bottom line

As a programmer you should want to know how to properly test your work(at least at the unit level) ,in order to decrease the time you will be looking for a new job

Read more »

Posted in: Agile practices,ATDD,Random Thoughts,TDD

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