Let’s say you don’t get involved “up front.”
Let’s say you are not invited to the big meeting.
No, you don’t have executive buy-in, nor are you the process police. You can’t tell the developers what to do.
Instead, at the tail end of the process, someone gives you a CD or website or rules to build you own web-server – and asks you to test it. They seem, for some reason, to view this as a reasonable thing.
So you’re sitting with the app, testing it. Until you come up with some bugs, the devs, project management, and possibly even an executive may have little to do. They may hang out by your cube, complaining that QA is the “bottleneck.”
Then you have that moment. You’re looking at the app and you realize, even before you ue it, that a particular piece of code is probably broken. You speak quickly to the dev, PM, and Vice President: “You see that button – right there? I bet that if I push it, the whole app crashes.”
The Dev smiles and points out that he wrote a unit test for exactly that functionality. The PM points out you have a bad attitude, and the Vice President asks “why wouldn’t that work? Of course it will work.”
So you say “well, I don’t know the underlying architecture, but I know a little bit about common failure modes, and I just don’t expect that to work. Let’s just press the button and find out, shall we?”
It may take years for you, as a tester, to get to that moment. However, I submit that once it happens, it’ll begin to happen more frequently.
And, all of a sudden, you’ve gone from “verification/bottleneck guy” to “person who can predict failures.”
Do it twice in a row, and suddenly you are a first-class citizen in the development community – and people invite you to the big meetings.
Predicting failure is just one example, but it fits my premise well – if you want to be a first-class citizen, one way to do it is by focusing on demonstrating value and competence.
At least, that’s been my experience. What has worked for you? Please leave a comment and sharpen my thinking.