This has been on my mind for quite some time. During the past week I read three blog entries which reminded me to write this down. First of all there was Vesna Leonard who wrote that she was not like any other qa or tester that her colleagues had met. Second, Lanette Creamer wrote a tale of two testers. Finally Alan Page blogged about the Tester DNA. Having referenced my inspirations, let’s take a look on things that us testers do, but should stop doing, and most importantly why.
Continue reading 10 things us testers need to stop doing!Monthly Archives: August 2010
What if God was counting?
Two weeks back, my niece was christened. During the ceremony the priest read the Parable of the Pharisee and the Tax Collector. I was amazed to see parallels between management in software testing and a 2000 year old story. Here’s the story as I found it online by searching for it:
The Parable of the Pharisee and the Tax Collector
To some who were confident of their own righteousness and looked down on everybody else, Jesus told this parable: “Two men went up to the temple to pray, one a Pharisee and the other a tax collector. The Pharisee stood up and prayed abouta himself: ‘God, I thank you that I am not like other men—robbers, evildoers, adulterers—or even like this tax collector. I fast twice a week and give a tenth of all I get.’
“But the tax collector stood at a distance. He would not even look up to heaven, but beat his breast and said, ‘God, have mercy on me, a sinner.’
“I tell you that this man, rather than the other, went home justified before God. For everyone who exalts himself will be humbled, and he who humbles himself will be exalted.”
(see Luke 18)
Now, the priest explained how God would look at both of them. In fact, the Pharisee tells all what he has achieved and how disciplined he is about his religion. He uses 31 words to describe that he is superior to some other folks, and names a few, even referencing the tax collector as a bad example. On the other hand, the tax collector knows his wrong steps, and asks for mercy in barely 6 words.
The priest continued that God could judge the prayers from both based on the number of words they used to reach him. Clearly, the Pharisee looks better here, as he has the larger number of words, 31, as opposed to the 6 words from the tax collector. But instead, we get told, that God rather takes a look on the one who knows about his failings, and simply asks for forgiveness. Wonderful.
That was when I started to wonder whether God would be counting lines of code or test cases…
Waterfall in Theory or why blaming doesn’t help at all
It seems, the theorists on waterfall got it all wrong. Waterfall software development is not Analyze, Design, Implement, Test, Release, it’s rather Analyze, Design, Implement, Look for whom to blame. Andy Glover – The Cartoon Tester was kind enough to draw this into a neat little cartoon for me:
Of course, not waterfall is by all means the problem in the above scenario. It’s rather the incongruent coping style that makes the situation really bad. Let’s explore why blaming is a problem in software development in general.
Continue reading Waterfall in Theory or why blaming doesn’t help at allA coding challenge
I got a quick coding challenge. Since I didn’t find a solution to the problem, I don’t dare to call it a kata, though this might become one. The challenge is easily described: Write a converter for Gregorian Calendar dates to Nepali Dates, also called Bikram Samwat – and back. The format MM/DD/YYYY shall be used for both calendars, not need to go for the unicode based Nepali names of the months – but it would be a nice addition.
You may choose any programming language as you may see fit. You may trawl any knowledge together that you need to fulfill the requirement. There are a few reference converters on the web. And I’m sure you will find them as well. I don’t put a due date on this, but if you get me something until end of this week, that would be awesome.
Summer hole
In Germany there is a smaller stream of news hitting the newspapers. It’s called the summer hole in that time. I seem to encounter a similar trouble right now. Though there are now some updates that I would like to share. August so far is pretty busy, but I felt that I couldn’t keep these any longer than necessary.
First off, the Software Testing Club published chapter 6 of my little tale about a tester. Check out The Deliberate Tester chapter 6 called The Presentation here. I have planned two more chapters so far. In case there won’t be any new ideas, I will end this mini series by then.
Second, I scheduled a webinar with the EuroSTAR conferences during their webinar week. The webinar will be on Alternative Paths for Self-education in Software Testing and it will be on September 10th 2010, 2pm London Local Time. Check out this link to check when this will be your local time. The talk will be a shorter version of the conference presentation, filled with topics such as Cem Kaner’s Black-box software testing course, Bach’s buccaneer scholar lessons, as well as Weekend Testing and the Miagi-Do school of software testing.
Last, but not least, we are currently in serious trouble in the European Weekend Testing chapter. Given the fact that two of our most active facilitators change jobs over summer, we need help to continue this great community. So, in case you are interested in helping us out, generating new ideas, or just helping with session preparations, please get in touch with me. Thanks. It’s engaging, and it’s a learning in its own rights.
On being the worst
Over the course of the past year I have ran into the term “be the worst” several times. First, Dawn Cannan had an article on being the worst in the Agile Record. But I ran into this even before that, when I read Apprenticeship Patterns from Dave Hoover and Ade Oshineye. Recently my paths crossed the principle in some more books as well – unfortunately I don’t remember all of them.
To me, a previous swimmer, ambitious by nature, being the worst means to work hard in order to achieve the current work at hand as well as to improve myself. It’s a constant driver for most of the things I do, to master them.
That said, at some point between the Agile Testing Days and XP2010 I came to the conclusion that it’s time for me to move on. Most of my colleagues are already aware about the fact, that I will leave my current company by the end of this month.
That said, I leave with a crying and a laughing eye. Looking back for the four and a half years that I stayed at my current company, I learned a lot. Initially starting the product development as a software tester, I got appointed a group leader position after one and a half year. Seeing my team’s struggle, I worked with them to improve the situation, thereby diving more and more into Agile software development. We were able to apply what we learned quickly, and continued our journey. Getting the appreciations from a co-worker recently really made me aware that I made a big impression to him – which made me proud.
For the laughing part, I am going to start a position at it-agile GmbH starting from September. Some of my future colleagues I got to know at last year’s XP Days Germany – many of them I admire.
I don’t know what is right in front of me, but I know that the decision for me to move was right. It depresses me a bit that I have to leave my current company. But the warm welcome I already receive from my future colleagues makes me look straightly forward with a smile. I know that I’m going to be the worst among this great team, but I also know that I am set up for the job.
So, I will spend the remaining three weeks that I got with the tasks remaining, talking to colleagues, and reflecting back, but also looking towards a new step in my life.