Interesting article on the place of dedicated testers in Agile. So far I haven't seen much demonstration of the benefits or problems of dedicated testers in Agile teams with the use of metrics etc, but at least this puts some discussion points together around the issue.
Too often I have heard developers say they test the code 'very well' and unless they are TDD guns, it's likely I could write another umpteen tests that assess more critical parts of the system/function/blancmange on top of their tests. This is mainly due to developers not being taught testing skills, just as few testers are taught development skills. With that in mind, and considering that the developer's strength is in their ability to write code, and to continue with the theme, a tester's strength is in their ability to skeptically analyse a specification and consider the most critical parts to test with well constructed and organised scenarios that expose predicted weaknesses.
Therefore a dedicated tester, or at least a part resource that can evaluate the story/requirement with such criticality that additional test cases (and hence defects discovered) are designed that otherwise would have been missed.
Perhaps this isn't even restricted to Agile but should encompass all IT projects; there seems to be a concept that testing is a tiresome necessity but we have forgotten why. The main reason it is there, is to provide a deep and skeptical appraisal of the system, on the behalf of the customer or end use. Who is the best person to do this? Do you read other independent reviews of a car that you are interested in buying? Do you buy a car without having a test drive first? Do you expect that the manufacturer does some internal testing? I started off on foody type analogies with cooks, chefs and waiters, but they all amount to the same thing; you expect a product to have a variety of levels of quality assessment (notice I didn't use quality assurance) before you even get close to it. I mean, would you buy an Operating System or some such thing that required the customers to perform their own defect detection activities?
An English immigrant IT consultant in Australia. This is my journey learning to surf, consult, mountain-bike, train, hold down a decent relationship, hold my weight down, purchase as many CDs as possible before they become obsolete, grow up, grow facial hair, develop a stand-up comedy act and stand up on my own two feet.
Showing posts with label testing. Show all posts
Showing posts with label testing. Show all posts
Sunday, 30 August 2009
Agile Research
Trying to get notes together to provide a bit more meat behind a course presentation. I always reckon a mix of real-world anecdotes, theoretical approach, and a whole bunch of tools and tricks, supported by plenty of hands on provides the right approach. Some people's learning style is about getting dirty with stuff, some like talking about it at breaks, some like listening, others like drawing diagrams to express themselves, while some like taking notes. There are some that require energetic debate for it to be taken on-board.
Anyways there is some great stuff out there for Agile these days, and being loving caring hoooomans there is plenty of sharing going on.
Great Agile cheat sheet.
- Great blog with some nice links here on xprocess and their site here
- Another blog here with some good stuff on velocity.
- Version One have a good Agile 101 here
- Good site with definitions and graphs here.
- Another good but of course obvious place to start research is with the various relatives of Agile such as ScrumAlliance which has a good glossary of terms.
- Agile FAQ is here.
- Another good blog which describes the estimation process in Scrum is found here.
Subscribe to:
Posts (Atom)