A QA Guy's Radio WeblogThoughts from Dave Liebreich(Untitled)- July 28, 2002 Start of a Thought I need to flesh this out more, but . . . Are there some basic incompatibilities between testing and managing As a tester, you go right for the weakest areas, trying to determine defects and faults. As a manager, you find out what each person is capable of, and build on strengths. You most certainly do not keep poking at the weak spots of your staff. How much of a problem is this dichotomyhttp://radio.weblogs.com/0100102/2002/07/28.html#a207 (Untitled)- July 26, 2002 2002 Bulwer-Lytton Fiction Contest Winners Announced. This year's winners of the annual Bulwer-Lytton Fiction Contest have been announced. What makes this contest unique is that the objective is to produce bad fiction, with humorous results. kuro5hin.orghttp://radio.weblogs.com/0100102/2002/07/25.html#a206 (Untitled)- July 22, 2002 I Lied Well, maybe "lied" is too strong a word. If Linda is on the ball, she'll tell me that the customer for our software (COTS, embedded systems, OEM stuff, etc) is the product manager. He or she is the middleman, or reseller, who is paying us to develop the software in the believe that he or she can sell it to others and recoup that cost. Therefore, the PM's requirements are the parameters that should drive testing. In some companies, the PM role is split across sales, marketing, and...http://radio.weblogs.com/0100102/2002/07/21.html#a205 (Untitled)- July 21, 2002 IT Blinders In response to this StickyMinds article, I wrote Linda, While I believe your analysis holds true for software developed in-house or on-contract for a business customer, I don't think it's a good approach for other testing situations. Yes, testing against requirements (and testing the requirements) are part of customer-acceptance testing (or customer-acceptance testing by proxy, as would be the case for COTS, some OEM deals, and some embedded systems). But there is more to the...http://radio.weblogs.com/0100102/2002/07/21.html#a204 (Untitled)- July 21, 2002 Nothing wrong with eating dessert first So, the test plan is a living document, but you have to have the basics of a test plan complete before you start in on test cases, right Nope. The only document you need first is the test strategy. And that doc can read: 1. perform a number of tests, and write them up as test cases 2. figure out ways to group test cases together 3. write up the test plan based on how the test cases can be grouped. 4. repeat. I wouldn't go too long without a test..http://radio.weblogs.com/0100102/2002/07/20.html#a203 |