Perhaps it’s just the nature of the tester, but I’ve seen a lot of complaints from testers recently. “Managers do the wrong thing”, “Testers need to do more ‘x’”, “Testing isn’t taken seriously”, “These people don’t understand what I do”, gripe, mumble, etc. Of course, it’s easy for me to tell you to quit your griping and fix it (in fact, I’m sure I’ve done that in previous posts), but solving problems is much bigger than that.
Let’s say, for example, that you want to make a change in your organization (I’ll leave the exercise on how to change the world) for another post. Just for fun, let’s say you would like to do a lot more Exploratory Testing in your organization (bad joke removed – should have picked a different example).
What do you do first?
The number one answer I expect (and I’m usually right) is that you need to convince management that ET is great (or that you should do more of it), and they’ll make a top down decree, and everything will be unicorns and rainbows(tm).
Bzzzt!
Management is one faction, but there are more. What if the rest of the testers on the team don’t see the value in ET? What if they don’t know how to do it? What if your customer demands that you only deliver automation results (or something else silly). What other factions can you identify? You need to think about everyone with an interest in the results – then take time to understand where they’re coming from and how the change impacts they’re thinking. With any change, you have gains and losses. What do you gain by doing more ET (note: also define “more”). What do you potentially lose by doing more ET? Top down edicts rarely work, so if you want a chance of success, don’t start there. Identify your factions, and come up with a strategy for working with each of them.
The important thing to remember is that you don’t change the process, you change the people. If you don’t think about how change impacts people, you will probably fail. Whenever I’m dealing with a performance gap, the six boxes model helps me think about how change happens.
|
Environmental and Team Factors |
Expectations and Feedback · Roles and performance expectations are defined; employees are given relevant feedback. · Work is linked to business goals. · Performance management system guides employee performance and development. |
Tools and Processes · Materials, tools and time needed to do the job are present. · Processes and procedures are clearly defined and enhance individual performance. · Work environment contributes to improved performance. |
Consequences and Incentives · Financial and non-financial incentives are present · Measurement and reward systems reinforce positive performance. · Overall work environment is positive, employees believe they have an opportunity to succeed; career development opportunities are present. |
|
Individual Factors |
Knowledge and Skills · Employees have the necessary knowledge, experience and skills to do desired behaviors. · Employees are cross-trained to understand each other’s roles. |
Capacity · Employees have the ability to learn and do what is needed to perform successfully. · Employees are recruited and selected to match the realities of the work situation. |
Motivation · Motives of employees are aligned with the work. · Employees desire to perform the required jobs. |
The six boxes model (sort of based on Maslow’s hierarchy of needs) is a model to help think about all of the factors that go into change.
Box 1 is where management can help. Defining the expectations and feedback loop for the change helps people understand what they need to do.
Box 2 pertains to tools (e.g. sysinternals.com tools), and resources (including computers, a quiet place to work, etc.).
Box 3 is where most change efforts fall short. This is the “what’s in it for me” category. Prizes, bonuses and other material rewards fall into this category, but it can also (and often more effectively) be some other type of reward. The points awarded on xbox live or on stackoverflow are a form of box 3 reward. Done really well, box 3 can be satisfied by making the job more fun and interesting, and creating higher quality software.
Box 4 deals with the skill gap. For our example, it is the plan for how to teach or demonstrate necessary skills for ET, and may include instruction, reading material, coaching, etc.
Box 5 is about the people on the job. Are they capable of carrying out the necessary tasks? If not, you probably won’t be successful.
Box 6 is dependent on the other boxes. Binder says that if the other boxes are positive then this one is positive. My view on box 6 is that box 6 is free will – and you don’t mess with free will. Sure – keep box 6 in mind, but don’t f with it.
Now that you’ve thought of your factions, and mapped out the human element of the change, you’re just about ready to go. Before you start, remind yourself that while you have a plan, and you’ve anticipated as much as you can, things will change. You need to adjust your plan (revisit the motivations of your factions, examine your six boxes evaluation as you learn more information – hey – this sounds like “exploratory leadership)). Organizational change is often a moving target and being ready for that will help you be successful.
If all of this sounds like too much work, there’s always plan b – quit and go shopping.
Plan B isn’t always such a terrible idea. If creating the change you want to see is clearly impossible in your current organisation, then perhaps it’s just not a good fit for you (at this point), and there’s no shame in recognising that and deciding to move on to somewhere that you feel you’ll be able to make a greater contribution. (Of course, if you’re unlucky enough to work in the sort of organisation where Box 3 includes “Suggesting a change angers the boss as it suggests the company isn’t already perfect – you’re fired!”, then you might get that ‘opportunity’ sooner rather than later…)
But yes – good points all. For an example of someone successfully arguing for change in their company, I found this post really valuable:
http://www.developsense.com/2009/11/testing-checking-and-convincing-boss-to.html
I think Michael’s post must have been in my head when I wrote the blog. Although today, I can’t imagine why I ever picked ET as the example of change for this post.
The letter from Michael is great at explaining value in a way the stakeholder understands. The six boxes approach ensures that motivations, skills, etc. are also in the strategy for change.
Thanks for the comment and link Anna.
I don’t expect you to publish this, and I don’t need you to. Although you can if you want. This message is for you.
[Alan] Thanks for taking the time to respond. I have no problem sharing your thoughts with the world and continuing this conversation.
Alan, what’s with the snarkiness? How does this help you? There is no ET club. If there’s a club, it’s the club of people who study testing and help others do so, as well. If you feel excluded from that “club” please consider the possibility that some of us, including, periodically, me, knock on your door yet feel that no one in there will answer.
[Alan] There was no intention to be snarky. To me (and others), you and MB and some of the others act a little elitist at times. Could be just by perception, so it was wrong of me to make “the club” joke. I honestly thought it was a friendly jab and didn’t mean for it to belittle what you are trying to do. I love learning and ET and have no problems with you or any of the other big-time proponents.
I sat with you and Whittaker at StarEast– do you remember that? I rolled out some complaints and ideas to him, all of which he contemptuously dismissed (like sapient testing– he said I was making up words– Huh? Don’t they have dictionaries at Microsoft?). You sat there silently. Neither of you engaged my points. It seemed to me I was the one being excluded from YOUR club.
[Alan] When my wife and her mother fight, I don’t step in there either. In that situation, I thought it best just to take mental notes and mind my own business. I don’t think JW had the intention of reaching any sort of conclusion from that conversation, so I didn’t want to prolong the arguments.
Not that I mind, but as long as we’re talking clubs, let’s be clear what’s going on with Microsoft’s SDET cult. Cem and I came there years ago with talks and training that was favorably received. I worked with Noel Nyman, Roger Sherman, and others. But just a few years later, a decent new tester can’t get a job there, and good testers were being forced out. All hail the tool-jockeys!
[Alan] Now that’s a perception based on ( I think) a limited insight into the company. I know you see MS SDETs as tool writers and code monkeys (and I’m sorry to say that in some organizations that is indeed a problem), but for the most part, we hire real testers – the kind of person you would call a tester. We just hire people with computer backgrounds – not so they can write millions of automated tests, but so they can understand how the underlying systems work and dig deeper than the average tester. BTW – it sort of bothers me that you referred to HWTSAM as a book about test automation. It has one chapter on test automation systems, and probably a few other sprinkles of code in other chapters. I would ask you if you actually read it, but I know that you don’t read testing books (relax – it’s not that big of a deal).
I think it’s fine that you talk about ET, except that you give me, in the substance of what you say, lots of fodder for criticism. Once again, in this post, you seem to be conflating freestyle ET with ET in general.
[Alan] ET was just a (real) example. Teams at MS are trying to do more ET and we’re trying to help them (there’s 5 of us and 10k testers, we do our best). All of the reasons that you and Michael have discussed about convincing management that ET is a valid approach and help them understand the value are true everywhere. Tell me how to change the post to make it represent ET most accurately and I will. The point of the post was to talk about organizational change, not ET, but I don’t mean to misrepresent anything.
Nobody disputes the value of ET. Exploratory behavior is a basic behavior of humanity. The people who *think* they dispute it are confusing ET with something else, or are merely complaining about unskilled or irresponsible behavior in general, which is found just as much in scripted testing, and arguably more (I do make that argument in my talk on faking a test project.)
I spoke with another guy at Microsoft, a few days ago, who asked me to come down and mentor him on how to create a professional testing culture in his group. I asked him if he had contacted your guys, and he said yes. He said he talked to several people and gave me some names– none of whom I recognized. He said that he felt the Testing Excellence people don’t know about testing skills, and don’t talk about them. He said that their advice always seemed to be “better tools and more automation.”
So, he came to me.
[Alan] – well that’s a bummer (not that he came to you, but that he felt we couldn’t help him). But I can’t help but wonder if he talked to one of the “divisional” test excellence teams. In our group, we rarely talk about tools -in fact we can’t really, since different teams use different tools. We talk about practices, approaches, patterns, etc.. I wonder if some of your misperceptions are caused by your small touchpoints within an org containing such a huge amount of testers. Those guys you met in the podcast, for example, ore two of thousands who think the same way. I think your impression of Microsoft testers has the minority and majority mixed up. You’d be surprised.
Other than your occasional strangely barbed comments on Twitter, and here, I haven’t had a problem with you.. I hope someday you take a deep cleansing breath, make a new commitment to your education, and enter a genuine conversation about testing practice with one of the leading CDT folks. Then at least, when you criticize us, it will have some basis in reality.
[Alan] – I take that breath almost every day. Thanks again for taking the time to comment.
To me (and others), you and MB and some of the others act a little elitist at times.
I do advocate development of testing skill to high standards, but I would hope that’s true of all of us. If you can point me to evidence of elitism, which I think is something different, I’d be happy to discuss it—and retract it, if it represents elitism.
It’s not that I don’t understand what elitism might be. Insisting that testers must have a computer background to be considered for a testing job sounds like elitism to me.
Cheers,
—-Michael B.
You left out the part of the quote where I said it could just be my perception. I debated saying anything in the first place because I don’t know why I feel that way. I know through hallway conversations that others feel the same way, but it’s sort of not fair for me to make a claim without something to back it up. I thought the “perception” addendum to the comment would alleviate that, but I guess I was wrong.
I too, hold testing to high standards (I don’t doubt for a second that you do). I think the way you address “low” standards may be perceived as attacks by some (I don’t know if that constitutes elitism or not). I do know that many who disagree with your points are afraid to engage with you directly – but that doesn’t necessarily have anything to do with elitism either. In the end, I suppose I really don’t care, it doesn’t bug me, and I honestly believe that you and James are trying to improve the craft of testing.
As an aside, I have to tell you that I was reading your comment and was nodding my head in agreement, then you threw out the silly jab at the end. I addressed that point in my reply to James above (and elsewhere over the years). The short answer is, that for the majority of the types of activities we expect testers to perform (and for the career path we provide), we’ve found that testers with CS backgrounds are better equipped to take on those challenges. We have plenty of non-CS testers as well. If you want to call that elitism, that’s fine – I call it hiring the best people we can find for the jobs we expect them to do. I didn’t mean for that reply to James to result in a game of “I am rubber, you are glue”, so I’ll just leave it at that.
I believe it is easier to fix the things that are in your direct control. For a regular QA guy, it is easier to develop a script or to find a tool to simplify his/her work. If that tool, technique, approach, etc. works well, other people might find it useful too, then it will grow and influence the team. My approach is to show that it works first before going and convincing everyone on the team and selling it to management.
But I agree with those guys, management do not understand … 🙂