The key metric for any knowledge work – IT deliveries and testing in particular – is more than Mean Time to Repair (MTTR). While fixing fast matters – timing is everything. Timing in getting information to the people who needs it to make decisions. It’s no use if you can turn the ship around on a plate now, if you needed it yesterday. Key elements in calculating time to information is how far away the information is and how evolved the information is.
Continue readinginformation
The domain expert is the tester
Sometimes the best tester is the domain expert, the person that knows all the in’s and out’s and corners of the system. I have worked with testers that have had hands-on on a system since the late 1970’es, but I also know testers of mobile app’s that marvel in being the subject matter expert of the domain. Sometimes the professional tester doubles as agile Product Owner(1) too given their vast knowledge. The tester becomes the the SME …
The subject matter expert, though, is usually a business analyst, or perhaps a User Experience expert. Those persons might have a better stand to be testing the system, than testers with no prior knowledge. Often the SME is the best tester available. I see this happening in a shift-left setting – but also in settings with a heavy user and business involvement. Like SAP releases to enterprise systems – where the business users and SAP architects still spend a month off their “actual” work (user acceptance) testing corporate configurations and customization.
The UAT is not dead, but the classic role of the tester testing on behalf of the business is declining. The business would rather test their own, with in-house subject matter experts. The field is active, as there is tool support for this activity. Panaya(2) is a tool that specializes in managing the UAT of a corporate system like SAP, and one of the key elements is that test cases can be broken up in steps and handed over between persons. Not even classic HP ALM’s handle hand-over between testers well. While ALM’s support that the tester does the testing, Panaya supports that tests are distributed across many people. People that have other (“real business”) tasks during the work day.
Testing can also be pushed even further out to the users with crowd-based testing, beta releases etc. In both crowd-based and UAT-based testing, the role of the pro’ tester is missing but the testing is still happening. IT’s being done by the most skilled – most valuable for the task.
So what can we as testers do when our tasks are gone – skill up, go with the change and become the expert – or move out to other skills: Coaches, delivery leads etc.
- If they double as scrum master, she’s probably more a Test Coach
- this post is not sponsored. I’m just making observations – not recommendations.
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.
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….
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…
Things are the way they are…
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 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.
- No matter how it looks at first, it’s always a people problem
- Things are the way they are because they got that way
If you can start to understand the people in the system you are operating in, and why the [larger] system operates the way it does then you can provide them the information they need. But you can’t do that unless you stop, shut up, and listen.
See also: When it smells fishy, there is something fishy going on
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
[ 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
Complexity is a Matter of Perspective 