The Seven Habits of Highly Effective Testers
Part 2 of 7
This is the second post in a series based loosely on Stephen R. Covey's book but focused on what you can do to be more effective as a software tester.
A long time ago in another life I was listening to an audio tape of motivational marketing guru Zig Zeigler. In this tape, Zig said "Nothing happens until somebody sells something." Though I don't totally agree with Zig on this, he does have a point. He also has a really cool name, but I digress.
If you are going to get paid to test software, somewhere along the line, someone has to pony up some money. Traditionally, this has been the customer. For the customer to make the decision that your software is worth their money, there are at least two things that she needs to believe:
1) The software should work
2) The software should solve some problem for her or fulfil some need
As testers, we tend to focus on #1. We get specs (when we're lucky) then we design and execute tests to determine if the software does what the specs say it should. The origins of these specs will be different for different companies, but usually they are written by some combination of marketing, sales, and development. But whos to say if the specs are right and if the resulting software will be what the customer really needs?
You are.
Before your first test case is even a twinkle in your eye, you should be reviewing the specs, and making some noise if you don't think they are right. Sales and marketing might know the customer best, and development might know the inner workings of the code the best, but it is the test team that is the expert at the intersection of the two. Testers know how to use the software better than anyone, so we have insights into the the design, the features, and the UI that are crucial.
Your company can produce solid software with nary a bug, but if it is not what the customer needs, it will not be sold, and as Zig reminds us, that is when everything starts to fall apart. This is a BAD THING that you can help prevent with carefully and critically reviewing any and all specs, and always asking yourself "Is this something the customer will want to buy?"
Previous Posts:
1 - Be protractive
Next Up:
3- Put Worst Things First
Monday, October 8, 2007
Wednesday, October 3, 2007
Be Protractive
The Seven Habits of Highly Effective Testers
Part 1 of 7
This is the first post in a series based on Stephen R. Covey's book but focused on what you can do to be more effective as a software tester.
One of the interesting challenges of software testing is caused by the fact that testing usually happens at the very end of the release cycle. This is a problem when all the milestones before testing are pushed back while the milestones after testing are unchanged. For example, the test-handoff is three weeks late but the GA date remains the same. That's called the squeeze, and it means that testers rarely have enough time to test as thoroughly as we should.
What can be done? You could try to push on the developers so that the software is delivered to test on the scheduled date. You could also try push on the executive's for a large corner office and a company Ferrari, with about as much luck. For many reasons, legitimate and otherwise, development is going to take longer than planned - so learn to live with it.
The other option is to be to be protractive and push back the GA dates as necessary to give your test team the time it needs. This will not make you popular because nobody likes to miss the GA date. If you want to be popular, I'll suggest to you that Software Test might not be best profession to pursue. Instead, you need to be firm. As bad as it is to be late, it is much worse to be on-time and buggy
One company I worked for had a policy that there would be a day-to-day slip of the GA date for every day the software was late into test. This policy showed a commitment to quality and a strong belief in the importance of test. That is not to say that as testers we can't or shouldn't work extra hard to make up some of the slip. If we can dothat, everyone wins because the software is less late, less buggy, and the testers are the heroes.
So, be efficient but thorough and make sure you take the time you need to test the software as much as you know it needs to be tested.
Next Up - Habit 2: Begin With the Vend in Mind
That is not to say tha
Part 1 of 7
This is the first post in a series based on Stephen R. Covey's book but focused on what you can do to be more effective as a software tester.
One of the interesting challenges of software testing is caused by the fact that testing usually happens at the very end of the release cycle. This is a problem when all the milestones before testing are pushed back while the milestones after testing are unchanged. For example, the test-handoff is three weeks late but the GA date remains the same. That's called the squeeze, and it means that testers rarely have enough time to test as thoroughly as we should.
What can be done? You could try to push on the developers so that the software is delivered to test on the scheduled date. You could also try push on the executive's for a large corner office and a company Ferrari, with about as much luck. For many reasons, legitimate and otherwise, development is going to take longer than planned - so learn to live with it.
The other option is to be to be protractive and push back the GA dates as necessary to give your test team the time it needs. This will not make you popular because nobody likes to miss the GA date. If you want to be popular, I'll suggest to you that Software Test might not be best profession to pursue. Instead, you need to be firm. As bad as it is to be late, it is much worse to be on-time and buggy
One company I worked for had a policy that there would be a day-to-day slip of the GA date for every day the software was late into test. This policy showed a commitment to quality and a strong belief in the importance of test. That is not to say that as testers we can't or shouldn't work extra hard to make up some of the slip. If we can dothat, everyone wins because the software is less late, less buggy, and the testers are the heroes.
So, be efficient but thorough and make sure you take the time you need to test the software as much as you know it needs to be tested.
Next Up - Habit 2: Begin With the Vend in Mind
That is not to say tha
Subscribe to:
Posts (Atom)
