In the absence of information, people will make stuff up.
This is a phrase I share often with mentees and colleagues – most often when talking about progress on a project they’re working on. I once saw a colleague take a lot of heat for a project he was leading – he was making great progress and doing (almost) everything right, but he wasn’t sharing his progress – and when he did, it was incomplete. He really was doing great work – I remain impressed today at how much he and his team were accomplishing and the obstacles they overcame, but if you weren’t part of his team or closely involved, you didn’t know what was going on.
And – as I said above, without the information, people made stuff up. The situation was a bit of a mess for a while, but he learned his lesson, and his work ended up back on course (although it was never far off course anyway). The point is that if you’re leading any sort of project, you have to let people know what’s going on – that’s one reason short iterations, demos, and retrospectives on agile teams are good – it’s a method of sharing progress, and it removes a lot of the ambiguity from the process.
This sort of thing happens all the time. When a professional athlete doesn’t dress for a game, or doesn’t play, the team usually makes an announcement explaining the situation. Without the explanation, people would make stuff up (although in the case of sports rumors, people will often make stuff up even if they have information)
This morning, I was thinking about some of the thoughts and rumors about testing at Microsoft – particularly some of the musings about why MS only hires testers with coding knowledge for full time positions. There are many reasons for this move, and most of them are good reasons – but the role shift hasn’t been without its problems.
I have to admit that I somehow feel the need to offer correction when I see people post their random theories on why MS made the decision to move to programmer-testers and the role of testers at MS. It’s somewhat stupid of me to care. I can’t speak for ten thousand testers and what they do. I’m not a spokesperson for Microsoft. I wasn’t even in the room when the decision occurred. Still, I wish someone with authority would have done a better job explaining the role of the SDET years ago, because without any information on the why and how of the move, people make stuff up. And who can blame them for that?
When I decided to write HWTSAM, it was mostly to explain the role of testing at MS – at that time, I was speaking to quite a few Microsoft customers who had questions about how we tested at scale, or how we tackled certain testing challenges. After answering many of the same questions several times, sharing some of what we do in a book seemed like a logical choice. The book, however, covers a lot of the ideas we use, but doesn’t fully capture enough of the innovative ideas our testers come up with on a near-daily basis.
A prominent tester once described HWTSAM as a book about writing automation. Obviously, this person hadn’t read the book (or perhaps has a different definition of automation than I do), but I am pretty sure they never read a page of the book. In the absence of the information they would have had from reading the book, they made stuff up.
I’d love to tell a better story – one that eliminates the conspiracy theories forever…but even I probably don’t have all the answers. I can share what I know – and it’s probably more than most people, but I’m sure I’m not the right person to explain the details. When I think about it in context, it doesn’t really even matter. I want to be part of improving and advancing software testing and the role of the tester. There are plenty of valid reasons to pick on the programmer-tester role, but few of those advance our profession, so there’s probably a better way I can use my time.
Alan,
This post seems to have raised many questions
>>> And – as I said above, without the information, people made stuff up.
That is true and is a reasonable social phenomenon. One way to deal with it is provide information and make attempts to build information. Where do you think is the information?
>>>why MS made the decision to move to programmer-testers and the role of testers at MS. It’s somewhat stupid of me to care. I can’t speak for ten thousand testers and what they do. I’m not a spokesperson for Microsoft.
But you seem to be concerned about “false propaganda” right? something in you tells there is somewhere the right information. where is that information?
>>> I’d love to tell a better story – one that eliminates the conspiracy theories forever…but even I probably don’t have all the answers
Please tell us a better story of how Microsoft tests software – eager to listen – not looking for answers but broader directions and theme.
>>> I want to be part of improving and advancing software testing and the role of the tester. There are plenty of valid reasons to pick on the programmer-tester role, but few of those advance our profession …
Looking for more on how current approaches of testing in microsoft are advancing software testing…
Let me confess… I have not read HWTSAM and often make up stuff about microsoft’s approach to test software.
If my recent experiences with microsoft were to go by – there are surely certain one sided “you cann’t test if you cannot code” kind of testing approaches going on. This is my first hand experience of applying jobs at MS.
Shrini
My conundrum is, that I’m not the right person to tell the story – or at least I don’t think I am. I think it’s perfectly valid (and expected) that people make stuff up about testing at Microsoft – we don’t do a good enough job providing information about what we do. We (MS) can do better.
Such visibility of information is especially valuable to testers, who in some orgs have the very justification for their existence questioned. The best thing a test team can do is show clear value. Unfortunately even if providing clear value, teams don’t always show it (as in the example with your colleague). One variant of this problem is when a Dev or expects to see a Test org behave in a subservient manner, providing a “service”, instead the mature test leadership sees the most value in being a partner. The inevitable refrain can be summed up as, “You are not testing my stuff…what *are* you doing then?”