I know you need more info…

Leave a comment

Mapping testing Competencies


[ Recognise and Acknowledge Your Skills  | Ministry Of Testing – The Testing Planet | June 2013]

The below model is directly inspired by the Vancouver Agile Quadrant introduced in “Agile Testing: A Practical Guide for Testers and Agile Teams” by Crispin and Gregory 2009 based on the original matrix from Brian Marick in 2003. It consists of four primary branches – as seen on the illustration. It is not a matrix or a table, but four directions with each their cloud of buzzwords. For specific contexts a mind-map will be a better choice of illustration – try drawing your own competencies.

Tester Skills Matrix

Tester Skills Matrix

In a star team – the team gets the stars


If praise, recognition, promotions always come to a few staff members – the usual suspects – you have a hero culture. You have a hero culture – even though you might think you have a team culture. You can call it a star team all you want, if not the team gets the stars but the heroes, you are not walking the talk. Would you build a software relying on only a few persons? “He got hit by a tram” – is a true story, and it is happening again in software projects.  If you only give credit to those that pull out the big fires, you will nurture big fires. You get what you reward….

I did not open it to build it

Something silly

Sure, recognize the stars – but spread the goodwill. Even heroes needs help. Make every team member feel that they contributed. Try when you lead to reach out to everybody over the course of the project/months days. Recognize them all and say thank you.

Once I was a leader at a children summer camp. Every evening we would make a mentioning of the fun stories of the day. Obviously some of the kids where more “fun” than the others, but we kept a rooster to make sure all were mentioned – perhaps just with a little thing. It meant a lot to be mentioned, even for something silly…

Keith Klain put’s it this way in The Testing Planet 10 – Leadership issue: “Leadership in Testing – What really Matters”:  I want my team to take ALL the credit because they are the ones doing all the work!  I would rephrase this to: I want to praise the teams I help succeed, but I also need to know that I am part of the team that get’s the praise ;-).  

Strip me of all my power, my titles, my roles – and hand them to those that need it to have the courage to stand up, or that needs it to grow. I know I stand on the shoulders of software testing giants (like Keith), I may not reach high compared to them – but I can still lift someone else up, so that we together reach even further. We all have to start somewhere…

more on http://www.lovisastahl.com/eng_con.html

Things are the way they are because they got that way

1 Comment

attributed to Gerald Weinberg as quoted by Adam Goucher on [Set Course For Awesome (as a ‘Career Tester’)].

As Adam writes:

It was during RST with James Bach that I really understood that the role of a tester isn’t to ‘break the app’ or ‘find all the bugs’ but to provide information about the application. It wasn’t until some time later than I realized that it is actually more subtle than that. Our job is to provide information that matters. And how do we do that? Easy. We Shut Up and Listen. To what? That is also easy. To the people we are providing the information to. Now that I’ve completed PSL I can safely start quoting Gerry Weinberg so here are two useful things to remember.

  1. No matter how it looks at first, it’s always a people problem
  2. Things are the way they are because they got that way


As context-driven as context allows


I’m at theoretically yes, but realistically maybe – but I might be wrong

todays innovation becomes tomorrows commodity


[CSC Leading edge Forum | by Simon Wardly | Feb 2, 2012 ]

yesterday’s new ideas become today’s best practices and tomorrow’s commodity systems

also for Enterprise IT and social media services. It’s the social media bell curve at play. Read/comment on Simon Wardley’s Organizing IT for the Future blog posts here.

Testers need critical thinking

Leave a comment

[ Atlassian blog series | Lanette Creamer | Feb 6, 2012]

First, to be effective as a software testers, you develop a different kind of critical thinking in order to find the exceptions to a given rule. It can be said that if you hear hoofbeats, think horses, not zebras. Testers know you’ve considered horses, but can you handle a herd of zebras? This is one reason why our arguments may sound strange to you, but when your code is on Safari, will you be less sorry?

Another reason why testers often do not agree, even on things that seem simple to other people, is that testers need to convince other people in order to see changes happen. 

For many of us, the number of bugs we FIND isn’t important. It is only the number of bugs important enough to be fixed or that we prevented that adds value to the end user. 

We don’t intend to argue for bugs being fixed or prevented unless they ARE important, but when that bug is important, a good tester will be as convincing as a pitbull lawyer.

There will be research, evidence, and convincing testimony from bystanders. By the time you’ve reached many years experience as a professional software tester, you are as adept at explaining risk and sharing information with others as a good insurance agent, and that is a good thing, unless you happen to be debating against one.

See also A little track history goes a long way