The document outlines strategies for integrating quality assurance (QA) within agile software development, emphasizing early involvement and collaboration with development teams. It advocates for QA professionals to adopt a consultative role, focusing on design and testability, while developers maintain ownership of quality creation. Key recommendations include improving communication, utilizing shared tools, and participating actively in customer interactions to ensure the delivery of high-quality software.

1. Surviving in an Agile
Environment
Markus Clermont

2. Agile Software Development (1)
The Agile Manifesto states:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

3. Agile Software Development (2)
Some further principles:
Release early & release often
Open to changing requirements. Any time.
Much informal communication between stakeholders
Frequent refactoring; changes in the architecture and the
design of the software
Teams are meant to be self-organizing
Small "family-size" teams work on subsets of the
problem.
Functional decomposition
Little communication between teams required.

4. What does that mean for QA
Once the features are developed, QA is meant to make sure
it works
QA often starts only after the product is finished
Focus on testing
That makes us really QC, not QA,
Relying a lot on a well-known, well-defined process,
Clearly defined interface between "QA" and "dev".
We tend to take ownership of quality in the traditional
development.
That starts too often only when the development is
already finished.
There is Agile Development until QA gets involed.

5. What changes need to be made?
1. Don't take ownership of quality.
2. Get involved early.
3. Review the design, participate in code-reviews.
4. Give positive re-enforcement and point out problems.
5. Make sure that your team is an integral part of the dev-team
6. Make sure your tools are part of their toolbox.
7. Make sure that the needed skills are in the team.
8. Don't do the release-process.
9. Become an integral part in the customer - developer
interactions.
10. Working software that satisfies the customer is the goal.

6. Don't Take Ownership of Quality
Only the developers can create the quality.
We should make it really easy for them to create quality:
Be a consultant and suggest creative ways to solve
problems
Help choosing the right tools for the problem
Continuous builds
UI-Test tools
Testing frameworks
Provide customization of these tools.
Be the advocate for quality towards project-management.
Test-Automation is a common pitfall.

7. The Test-Automation Pitfall
Short release cycles:
Not enough time for manual testing
Not enough time to properly automate all the tests.
Lack of documentation:
No deep understanding how a certain scenario should
be tested.
No way to find out what changed in the system that can
make my tests brake.
Teams start to spend more and more times on investigating
and fixing breakages.
Credibility of the tests suffer.

8. So, what to do?
Start at the bottom of the pyramid:
Test-Driven Development
(Frequent refactoring)
High unit-test coverage,
Education & Best Practices
Reduce the number of "big" tests.
Make the smallest possible tests,
and a few big end-to-end tests.
Execute the tests at every change in the code-repository
Make the person who breaks them fix them
On the long run,
Have those who provide a new feature write the
integration- and end-to-end tests,
but make it really easy to do so.

9. Get involved early
Always look at the testability of new features,
Early feedback is likely to be taken into account.
Help to make time plans more realistic
Less pressure on the developers means better quality.
Time requirements for testing can be taken into account

10. Review the Design and the Code
Design - Quality is an important aspect of the software
quality:
Re-usability,
Maintainability,
Testability
Speaking up early can help to prevent these problems.
And it makes it easier to get more and better tests.
The same is true for code.
Two implementations of the same feat
Test-code is code, too.
Is the code easy to test,
are the tests sufficient, good, and adequate?

11. Give positive re-enforcement
Doing quality software should be fun.
Look for reward mechanisms inside your company
Use them...
Talk to the manager,
Spend money on an offsite
Do a testing-competition, with a cool prize
Don't forget to point out problems, too.

12. Team Integration
Agile development has a lot of informal communication, and
undefined processes.
If the QA team is not in the middle of that, it is almost
impossible to catch up later.
Allows to recognize testing / quality challenges early on and
react.
Giving early feedback becomes easier, too.
Increases the technical understanding of the product.
More valuable feedback
Better solutions to quality problems.
Gives a wider view on the problems a project is facing.

13. Tool Integration
The organizational separation of QA and Dev-Team often
reflects in separate "Tool-Worlds"
"Tools" for the developers:
Programming Language
IDE
Libraries and Frameworks
"Tools" for QA:
Process description
Test-Automation Tools, Scripts
Bug-Tracking
Transferring ownership is hard if the tools are unknown.
Try to speak the same language.

14. Skills
Not every test-engineer is a software-engineer.
Difficulties:
Communication,
Gaining technical respect,
Finding the best way to test a product,
Typically very low-level (unit-tests), and high-level
(end-to-end) tests.
No integration tests.
Finding flaws in the design.
What can be done?
Train your test-engineers about software-engineering,
Programming,
Design,
Unit-Tests.

15. Don't do the release-process
In the release process quality problems show themselves in
their most powerful way.
Whoever is driving the release-process has most interest in
following the best practices we preach
If not yet, wait 2 or 3 release cycles.
On-Call duty is a further incentive :)
The decision to release will always be a trade-off.

16. Participate in the customer - developer
interactions.
In agile development, UAT is often done by the customer (or
the direct representative)
The only person who really knows how the product should
work, is the customer.
The customer - developer interaction is the single most
important source for requirements.
Sitting on the same table with the customer helps to
clarify requirements when they are posed
figure out the pain points with the current solution
understand requirements ourselves for better testing
thereof.

17. Working Software is the Goal
For everything we do, ask:
How does that contribute to that goal?
Do we need to do it?
More often? Less often?
Can we do it different- better, faster, more effectively?
The common interest with development is to give the
customer software that satisfies the needs (see the "release
trade-off").
Constructive feedback.

18. Two case-studies

19. Questions?
Thank you for your attention!