Agile and QA... ma che ciazzecca?

download Agile and QA... ma che ciazzecca?

If you can't read please download the document

Transcript of Agile and QA... ma che ciazzecca?

PowerPoint Presentation

Agile and QA... ma che ciazzecca?Better Software 2010Firenze, May 5th-6th

Stefano Fornari, Funambol CTO

Agenda

Do we need QA in scrum?

QA vs Testing

Agile testing

QA in our team

Q&A

QA vs testing

Quality assurance is an effort to prevent defects from entering the system

QA vs testing

Quality assurance is an effort to prevent defects from entering the system

Testing is any activity to discover defects in the system

Test at the end

It is hard to improve the quality of an existing product

Mistakes continue unnoticed

The state of the project is difficult to gauge

Feedback opportunity are lost

Testing is more likely to be cut

DevelopmentTest

Delivery

Without test, there is no value delivered

If it's not tested, it's not done

If not done it's not accepted

If it's not accepted, there's no value delivered

Agile development

Iterative and incremental development

Cross-functional teams

All team shares the same goalsproduce value for the customer

produce high-quality software

the entire team is accountable for quality

All team participate in the development of value at each stage

All team members help in any tasks as required by the team

Each team member is equally-valued

Agile testing

Definition of doneIf a piece of functionality is not acceptable, it is not done

If test tasks are not complete, the team stops and everyone tests. Programmers can't get ahead of testers

Testing takes place at any timeTesting helps development!

It's impossible to run out of time for testing

Testing must be efficient and cost-effectiveTest automation!

Agile testing quadrants

Quadrant 2 testing: automatic vs manual

http://jamesshore.com/Blog/The-Problems-With-Acceptance-Testing.html

The agile testing pyramid

Do we need a QA team at all?

We currently do have a QA team

Main responsibilitiesDevelop a testing strategy amongst different scrum teams

Develop specific testing skills, competences, attitude, practices

Share the above between different scrum teams

Encourage automation

Let people express their most potential

Cultivate and encourage different perspectives

Human resources

Make sure testing has the same level of attention than development

Quadrant 1 testing

Technology-facing support the team

Test first/Test driven development

Unit and component testing

Fully automated

Internal quality

Quadrant 2 testing

Business-facing support the team

Define external quality

Define features

Drive development from high level

Driven by examples from the customers

Expressed in business domain language

Help the team to deliver the business value requested by the customer

Automation still under researching?

Quadrant 3 testing

Business-facing critique product

Critique as positive constructive word

Business-facing tests that exercise the software to see if it does not quite meet expectations as a overall

Trying to emulate real users usage

Mainly manual

The best tools are senses, brains, intuition, creativity, domain knowledge

Quadrant 4 testing

Technology facing critique product

Critique non functional requirements such as performance, scalability, robustness, security ...

Specialized tools/expertise may be required

Automation