Agile Software Development
Testing
Christopher Jones Fall, 2020-2021
School of Computing, DePaul University
Agile Testing
Traditional
• Strictly enforced gate. • Separate phase.
• Separate team.
Agile
• Team effort.
• Part of development “definition of done.”
• Whole team.
1/36
Agile testing values [1] are similar to the values we discussed with both XP and are rooted in the Agile Manifesto:
• Continuous feedback
• Deliver value to the customer • Face-to-face communication • Have courage
• Keep it simple
• Continuous improvement • Respond to change
• Self-organize
• Focus on people
• Enjoy
2/36
Cultural Challenges
3/36
Quality Philosophy
• Is poor quality tolerated in favor of meeting deadlines? This makes adjusting to agile more difficult.
• Does the QA function wield significant power? They may fear losing that power or that agile doesn’t embrace quality.
• The whole team should own quality.
• Testers need to adapt to less formal requirements.
• Focus on learning, training, and adaptation.
4/36
Sustainable Pace
• Overtime is not a measure of productivity or commitment.
• QA’s pace needs to be as sustainable as development’s. Tends to occur naturally as sprint velocities reach equilibrium.
• The whole team needs to commit to reaching testing goals, nit just the QA team members.
5/36
Customer Relationships
• Focus on collaborating with the customer rather than treating them like a client.
• Testers working with customers to learn the requirements and define the acceptance tests help prove that the software is fit for purpose and fit for use.
6/36
Organization Size
• Organizational hierarchy can reflect itself in the organization of software projects and code.
• Larger organizations have communication challenges, but smaller organizations are not immune.
• Separating testing teams from the development teams.
• Large organizations may make it harder to talk to actual
customers.
• Larger organizations make planning essential.
7/36
Empower Your Team
• Treat the team like professionals and allow them to make decisions.
8/36
Loss of Identity
• Fear that QA will lose support in favor of development.
• Fear that QA won’t have the necessary skills and will be let go. • Fear that QA will get lost in the new development model.
9/36
Additional Roles
• Might need new roles with new skills.
• Might need new skills and training in new QA techniques.
10/36
Lack of Training & Not Understanding Agile Concepts
• New QA techniques and tools. • Agile training is must.
11/36
Past Experience
• Previous experiences can make it difficult to try new things.
• Any new process takes time to iron itself out. This can be an uncomfortable time.
12/36
Cultural Differences Among Roles
• Almost every role will be impacted by a transition to agile.
• QA needs to find new ways to work within the new agile framework.
13/36
Talk About Fears
• Retrospectives are a good place to discuss fears and provide feedback.
• Consider producing a “Testers Bill of Rights” that describes the rights testers have as members of the development team. It can include anything, but often includes items like the right of testers to estimate testing tasks and have them included in the sprint estimates and the right to expect the whole team to be concerned about, and learn about, quality.
14/36
Give Team Ownership
• Make sure the team has the opportunity and authority to experiment and improve.
15/36
Celebrate Success
• Change is hard. Celebrate the little successes, not just the big ones.
16/36
Cultural Changes for Managers
• Agile doesn’t have phases and so there are no sign-offs to demarcate the movement from one phase to another.
• Each team needs to define meaningful metrics.
• Managers need to focus on removing obstacles instead of
defining when quality is “good enough” or in micro-managing
individuals.
• Managers require patience and the ability to support their
people during the transition to agile.
17/36
Speaking the Managers Language
• Look for ways to translate your needs into ROI. This might not need to be money, but could also be velocity.
• Be prepared to be creative. All teams have resource constraints.
18/36
Be Patient
• Better to make small, incremental progress.
• Find changes that can be made during wait times.
19/36
Let Them Feel Pain
• Sometimes failure is required in order to make the case for change.
20/36
Build Your Credibility
• Demonstrate an ability to help.
• Demonstrate that you’re willing to work with the team collaboratively rather than adversarially.
21/36
Beware the Quality Policy Mentality
• Collaborate, don’t enforce.
• Approach problems from the standpoint of finding solutions together rather than mandating one from on-high.
22/36
Vote with Your Feet
• You can’t change the unwilling.
23/36
24/36
Independent QA Teams
• Independent doesn’t mean separate. Separate is undesirable.
• Consider re-thinking QA to be a practice rather than a work center.
25/36
Integrating Testers into an Agile Project
• Don’t just embed testers in a development team and hope they’ll be successful.
• Testers will need training and coaching as well.
• Consider pairing programmers and testers, especially when troubleshooting issues.
• Testers need to be considered first-class citizens of the team.
26/36
Agile Project Teams
• In large organizations, people from different functional areas may be brought together into an agile project team.
• Try to start everyone together; don’t wait until testing is required to have testers on the team.
• Testers can collaborate with their functional area, but their day-to-day work needs to be managed by the project team.
27/36
Physical Logistics
• Co-location of testers with the rest of the project team is ideal.
• Be inventive – don’t just accept things as they are – find ways to improve them to make it possible to work more collaboratively.
• Can be challenging in geographically distributed teams.
28/36
Tester-Developer Ratio
• There is no one “right” ratio.
• There should be enough testers to keep up with the desired pace of delivery.
• Remember that everyone on the team is responsible for quality, so fewer dedicated testers may be required compared to models where a separate QA team is used.
29/36
Hiring an Agile Tester
• All projects have different needs, but consider focusing less on technical skills and more on their ability to collaborate successfully with developers.
• Perhaps emphasize more developer-centric skills such as programming or system administration.
• Look for people who don’t sit around and wait to be told what to do.
30/36
Self-Organizing Team
• Managers should not impose ideas on the team.
• Identify issues and challenge the team to find solutions for them.
31/36
Involving Other Teams
• Communication is critical.
• Scrum of Scrums can help keep teams coordinated.
• If teams are geographically distributed, find ways to get as much face-time as possible.
32/36
Every Team Member Has Equal Value
• Testers need to be invited to all meetings, especially if they involve the developers and the business experts.
• Testers must be able to ask for and receive help. This is often part of the “Testers Bill of Rights.”
33/36
Performance and Rewards
• Evaluations need to be crafted carefully to avoid incentivizing unwanted behavior. For example, developers who are evaluated based on the amount of production code they provide, will not want to take on testing tasks.
• Individual goals need to reflect team goals.
34/36
What Can You Do
• New testers on projects should find out what they can do to help rather than waiting to be assigned a task.
• Reach out to developers to begin learning their processes. • Identify problems and work to find solutions.
35/36
References i
[1] Janet Gregory Lisa Crispin.
Agile Testing: A Practical Guide for Testers and Agile Teams. Addison Wesley, 2009.
36/36