To contrast my last post, I thought it would be fun to list when I feel good as a tester. See if you relate.
- I ask my devs so many questions they begin discovering their own bugs during the interrogation.
- A BA spends hours executing redundant tests to verify code I know is reused. I verify it with a simple test and move on to more important tests.
- A persistent whiteboard discussion finally sifts out the worthless tests and the worth while tests present themselves.
- A dev cannot test their own code after integration because they don’t understand how the application works in its entirety.
- The project manager looks at me and asks which parts of the release are ready for prod. I have an answer prepared with tests and bugs to back me up.
- I write tests in my head for non AUTs. When I can’t resist, I execute one and find a “bug in the wild”.
- A BA sends me an email with about 20 repro steps. I determine 90% of their observations to be irrelevant and reduce it to two repro steps, the dev is grateful.
- I write a program that provides valuable feedback, on the quality state of an AUT, after running unattended.
- Another tester asks me for advice on how to test something complex.
- During bug review meetings, the stakeholders bump most of my bugs up to “Showstoppers”.
- I find a bug that leads me to accurately predict several more.
- I execute tests that find problems, before the UI is developed.
What makes you feel good as a tester?
4 comments:
Subscribe to:
Post Comments (Atom)
RSS
When a release goes out and the majority of 'bugs' found are PEBKAC errors or spelling mistakes.
A dev cannot test their own code after integration because they don’t understand how the application works in its entirety.
That on its own is an important test result.
The project manager looks at me and asks which parts of the release are ready for prod. I have an answer prepared with tests and bugs to back me up.
The tests and bugs are really important information, but I would hope that your reply doesn't include an answer as to whether it's ready for production. That's a business decision, to which the test report is information. There's other information to be considered.
I write a program that provides valuable feedback, on the quality state of an AUT, after running unattended.
How do you do that? Quality isn't something that a machine can tell you about, since it's a relationship between the product and some person. In addition, as testers, we must beware of affirming the consequent. "All my tests pass, therefore the program is of high quality." Can you see the problem in that statement? There's also a problem with this one: "One (or more) of my tests failed; therefore the product is of low quality." Can you spot it?
All that said, one thing that makes me happy as a tester is seeing other testers describe how they go about their work. Good on you, Eric!
---Michael B.
I think the following would also be a high for the tester.
1) Challenging/Outdoing the Business Analyst in terms of how the application functions and demonstrating the knowledge gleaned (through many hours of study/testing) in terms of correct application behaviour.
2) Being very organised in terms of information gathered via study, investigation and analysis and bugs logged which is demonstrated by quickly coming up with information on the fly or being able to say relate steps "x" with bug "y".
3) The application area previously tested by a tester being voted clean by the customer.
4) Customer commending the knowledge / contribution by testing team/tester.
Michael,
Thanks for catching me on the whole "ready for production" thing.
There's also a problem with this one: "One (or more) of my tests failed; therefore the product is of low quality." Can you spot it?
Sure. First, you have to make sure the test itself does not have a bug. Next, it depends on how much the stakeholders value what the test verifys.