Don't know where QA/Testing Team fit with Agile Development Teams?
Submitted by Antony Marcano on Wed, 01/03/2006 - 08:10.
agile
[textile]Could it be that you didn't know where they fit in before? Could it be that giving the software to someone to test was just something you had to do to get a tick-in-a-box? A tick in the 'someone else has tested it' box? Did you ever really think about the valuable information you could get?
If you are using XP then your customers and your developers' might not be the best people to describe behaviour in the form of a 'test'. Your testing team are the 'testing experts'. They can act in a consultative capacity in a session where the Stories are elaborated into Acceptance Tests. They may increase the comprehensiveness of the Acceptance Tests. They may ask, "so, that's what it should do, but how fast should it do it?" identifying performance requirements. They may ask, "how many people will be doing it" (load and concurrency) or "what are the constraints on that data" (field validation on size/type/content)... and so on.
Your Testing team can represent customers' interests during an end-of-iteration evaluation... for example to perform exploratory testing to identify tests that are relevant to the new feature(s) but hadn't been considered before building the code. They can represent the customer in areas where the customer doesn't have the skills to evaluate the behaviour, e.g. in testing the configuration options of an application's role-based-security model. They may carry out spikes to explore "qualities" (non-functional capabilities) of the infrastructure or software architecture.
They may pair with developers on unit-tests to help encourage developers to cover both positive and negative cases (e.g. exceptions). Some developers may already 'think like a tester' and explore exception cases with their unit tests already but not all do...
Testers can be capable of adding immense value by testing and by being your local experts on testing. Due to the exposure to the usage of the software that's built, test-team can also become a source of domain-experts if customers are hard to get time with. To enable this collaborative way of working, a 'Collective Ownership' attitude needs to become embedded in the culture of the project and testers need to focus on adding value, not purely on filing 'bug-reports'.
note: If you are in a team called "QA" or "Quality Assurance", maybe you might wish to also "read this":http://www.testingreflections.com/node/view/827
Brought to you as a "Single Serving Sachet":http://www.testingreflections.com/node/view/3241
If you are using XP then your customers and your developers' might not be the best people to describe behaviour in the form of a 'test'. Your testing team are the 'testing experts'. They can act in a consultative capacity in a session where the Stories are elaborated into Acceptance Tests. They may increase the comprehensiveness of the Acceptance Tests. They may ask, "so, that's what it should do, but how fast should it do it?" identifying performance requirements. They may ask, "how many people will be doing it" (load and concurrency) or "what are the constraints on that data" (field validation on size/type/content)... and so on.
Your Testing team can represent customers' interests during an end-of-iteration evaluation... for example to perform exploratory testing to identify tests that are relevant to the new feature(s) but hadn't been considered before building the code. They can represent the customer in areas where the customer doesn't have the skills to evaluate the behaviour, e.g. in testing the configuration options of an application's role-based-security model. They may carry out spikes to explore "qualities" (non-functional capabilities) of the infrastructure or software architecture.
They may pair with developers on unit-tests to help encourage developers to cover both positive and negative cases (e.g. exceptions). Some developers may already 'think like a tester' and explore exception cases with their unit tests already but not all do...
Testers can be capable of adding immense value by testing and by being your local experts on testing. Due to the exposure to the usage of the software that's built, test-team can also become a source of domain-experts if customers are hard to get time with. To enable this collaborative way of working, a 'Collective Ownership' attitude needs to become embedded in the culture of the project and testers need to focus on adding value, not purely on filing 'bug-reports'.
note: If you are in a team called "QA" or "Quality Assurance", maybe you might wish to also "read this":http://www.testingreflections.com/node/view/827
Brought to you as a "Single Serving Sachet":http://www.testingreflections.com/node/view/3241