Part IV QA Paradigm
1. QA Paradigm #1: Quality Assurance is Testing
(1) Most QA people are actually employed as testers
(2) “Did you QA this?”
(3) “Independent testing is better testing”
(4) Are used to testing untested code and struggle when working with agile developers
- E.g., overuse of boundary testing is common
2. QA Paradigm #2: Quality Assurance is Process
(1) Role defined by CMM and IEEE
(2) An approach that many QA groups aspire to
(3) The Process Police must force discipline on the developers
(4) However, test teams that also try to enforce process may undermine their effectiveness as testers
- discourages communication
- reduces trust
- may cause delays
(5) Also, tend to enforce waterfallian practices, which is counterproductive for agile teams
3. QA Paradigm #3: Quality Assurance is Team Responsibility for Customer Satisfaction
(1) “Whole Team” means that QA can’t be delegated to a person or subgroup
(2) Everyone is responsible for raising quality issues
(3) It’s not enough to say that you did what they asked for
(4) Quality ultimately is defined by the customer, not by process standards, nor by stale documents
(5) This is the approach preferred by Agile teams
Part V. 4 Practices for Agile Testing
1. 4 Practices for Agile Testing
- Conversational Test Creation
- Coaching Tests
- Providing Test Interfaces
- Exploratory Learning
2. Conversational Test Creation
(1) Who should write tests?
- Customers are often too busy.
(2) Defining tests is a key activity that should include programmers and customer representatives.
(3) Don't do it alone
(4) Testers facilitate the conversation.
3. Coaching Tests
(1) Use acceptance tests to drive development
(2) Tests provide:
- Goals and guidance
- Instant feedback
- Progress measurement
(3) Tests are specified in a format:
- Clear – so any one can understand
- Specific – so it can be executed
(4) Testers help analyze the business
4. Coaching Tests: Specification By Example
(1) Defining requirements is difficult
- Often ambiguous
- Often harder to specify requirements than design
- Easy to become out of date
(2) Defining them by example is incremental, and easier
- Concrete
- Run them to see if they are current
(3) Examples…
- Ground concepts
- Define expectations
- Demonstrate progress & conformance
5. FIT tests
(1) Scrape tests from HTML docs
(2) Keep requirements & tests together
(3) Check automatically
(4) Browse results online
(5) Understandable by everyone
6. Providing Test Interfaces
(1) Developers are responsible for providing the fixtures that automate coaching tests
(2) In most cases XP teams are adding test interfaces to their products, rather than using external test tools
7. Exploratory Learning
(1) Plan to explore the product with each iteration.
(2) Look for bugs, missing features and opportunities for improvement.
(3) We don’t understand software until we have used it.
Reference
- Agile Methods, Testing and Quality Assurance, Bret Pettichord, March 2005
- Agile Testing and Extreme Programming, Bret Pettichord, March 2003
- Agile Testing What is it? Can it work?, Bret Pettichord, October 2002
留言列表
