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?"
Push. Crash.
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.
Tuesday, March 03, 2009
Subscribe to:
Post Comments (Atom)
5 comments:
Matthew,
Good post. It sorts out some interesting points in my mind. I like the fact you neatly sum up the fact that test are rarely involved up front when in reality we could have spotted that potential defect during the design stages.
I have not seen this as clear cut as being able to predict any regular bug, but the ability to break software within a few minutes of getting it tends to have the same effect.
You begin to get involved earlier in the process.
I've long held the belief that testers need to be involved early in the process and here is a good example why. You also highlight though that you CAN still test even though you have had no involvement in the project - another very valid point.
How to be a first-class citizen?
1. Understand your mission.
2. Fulfill it.
People ask you to test because they have at least one question about their product or service or system that they want answered. As a tester, your mission is to help them answer that question but not necessarily to answer it for them in the way that they'd like right away. So in addition to producing products (like found bugs), we also have to be concerned with the packaging (that is, how we break the news). In either case, I don't worry much about when they brought me in. If I think it might make a difference next time, I'll mention it this time, but I'll try not to whine about it—since I can't be certain that I would have spotted a given problem, given the information and skill that everyone else had at the time.
Sometimes the question we're being asked is specific, like "Does the application crash when I press this button?"; sometimes there's a meta-question, like "Are there problems in this product that would prevent us from shipping?" If we're to be first-class citizens, we need to be very careful about the way we answer the second kind of question. The first part of the question is within our purview—the finding problems bit. The second part of the question—the decision to ship bit—is not our job. Management owns that one. Many of the misunderstandings between testers and the rest of the project community are founded on the problem of management trying to abdicate its role, or testers trying to usurp it, whether intentionally or unintentionally.
I think that being a first-class citizen is about establishing credibility as a skillful and honest investigator and reporter.
Being able to seek problems expertly is a very useful skill. Being able to find them is nice, but that depends on a number of things—not just the skill of the tester, but also things like the state of the product or the project, timing, information, imagination, and even, sometimes, luck. I don't see being able to predict the future as being a useful skill for a tester since, among other things, it's impossible. Being able to anticipate possible futures, on the other hand, is achievable and valuable. Shining light on things that might manifest those futures is our role. First-class citizens do that capably, in a way that respects the people and the goals of the project community.
---Michael B.
Nice post. I've found that with every new team, I've had to earn credibility. Developers don't want bugs to go to production, so they are happy to learn I can think of test cases they didn't think of, help them understand the customer's requirements and so on.
Even in a waterfall environment I was always able to elbow my way in and get involved from the beginning of a project, and show I could even be useful in the requirements phase. I always went to the developers to ask, "Do you have any small part of the code done that I could see in action?" And they were usually happy to work with me.
But I think I was probably lucky, I've heard of places where testers were made to stay in their place and not talk to anyone. So your means of demonstrating tester value is very effective.
Last year I experienced the first step to a "first-class" citizen. My test team chose to port our legacy shell-script based tests to FIT and we agreed to use a better approach while doing so. We started this off right before easter and had the first prototype finished by beginning of May. By end of June we were finished and celebrated the shutdown of our legacy tests. By that time the lead or our development team came over to check some difficult business cases in order to ask our customer on "how it should be". He had seven test data where he would like to get to know how the system currently behaves.
In our legacy test system it was hard to create larger account hierarchies due to the approach used (we had come up with test-reuse in order to get to test preconditions causing the biggest flaws in our test suites). The business use case was based on spreading money from one "father" account to all underlying accounts and therefore needed some account hierarchies as a precondition. We were able to give him the feedback he asked for on his seven examples in 10 minutes, which was quite overwhelming compared to the feedback we could provide beforehand.
Not only did we notice that our developers regularly came over to our desks to get that feedback after migrating our shell-script tests to a new approach based on FIT, but we also could produce timely feedback to our development lead and customers where necessary. I think this was somehow related to the experience you mentioned.
I had that exact experience. Working on a project in the mid-90s that involved building custom Visual Basic Controls. I noticed that the was no limit placed on the values that you could enter for size. I walked into the office of the dev manager and predicted that I could crash any of the new VBXs.
When he challenged me, I typed 65000 in the "height" field and crashed the whole thing with an integer overflow error.
Post a Comment