2. Agenda
• Agile testing success factors
• Waterfall against Agile
• Scrum ceremonies
• Scrum team
• Agile Quality
• Tester activities
• Skills and benefits to be Agile tester
3. Agile Testing Success Factors
• Be cathedral builders not stone cutters
• Collective ownership
Testers are part
of the team
• Drop the “Quality Police” mindset
• Focus on team goals & customer value
Agile testing
mindset
• Automate tests wherever practical
• Need rapid feedbackAutomate tests
• Balance against developer focus on
technical implementation
• Use agile test matrix as guide
Look at the big
picture
4. Agile Testing Success Factors
• Session-based testing,
agile test environments
• Informative workspace
Foundation of
critical practices
• Collaborate with customers
• Collaborate within team
Collaborate
• Team retrospectives
• Personal training: reading, blogs,
QAI, local QA groups
Continually
improve
7. Agile Values
Individuals & Interactions
Processes & Tools
Customer Collaboration
Contract Negotiation
Working Software
Comprehensive
Documentation
Responding to Change
Following a Plan
8. Scrum Team
Product
Owner
• Feature
definition
• Release dates
• Single decision
point
• Accepts or
rejects work
• ROI
ScrumMaster
• Removes
obstacles
• Ensures Scrum
process
• Facilitator
Team
• Self organizing
• Cross-functional
• Estimates
• Collaborates
• Attempts to build
a ‘potentially
shippable
product’ every
sprint
14. Test Approach – The Agile Way
Project Initiation Get an understanding of the project
Release Planning Participate in estimating stories
Create Test Plan
Each Iteration Write and execute User Stories tests
Write and execute new functional test cases
Pair tests with other testers, developers
Automate new functional test cases
Run automated regression test cases
System test / End Game Perform Load Test
Complete Regression Test
Perform UAT
Perform Mock Deploy
Participate in Release Readiness
Release to Prod / Support Participate in Release to Prod
Participate in Retrospectives
15. Agile Quality – A Team Deliverable
Agile Practice Benefits
Whole Team • Quality is not just a tester
responsibility
• Quality is more than just testing
• Testing role shifts to quality infusion
throughout project life cycle
Continuous
Integration
• Developers cannot check in code
with failing tests
Continuous
Testing
• Avoids long delays with “big-bang”
testing after the “final build”
• Bugs found closer to when they are
introduced making them easier to fix
20. Skills of Agile tester
• “Traditional” testing skills
• Automation / development
• Exploratory testing
• Communication and collaboration
– With developers in their language
– With customers in their language
21. Benefits of being an agile tester
• Work together as one team towards a
common goal
• Less risk of squeezed test period
• Test all the time, not just at the end
This is the “perceived wisdom” – the way that we have been taught.Developed by Royce – “Managing the Development of Large Scale Systems” Proceeding, IEEE Wescon, August 1970 This model has been misinterpreted – Royce meant to show that this was actually a “bad idea”! “the implementation described above is risky and invites failure … one can expect up to a 100-percent overrun in schedule and/or costs” However in practice we have the prevalent notions of: Get it right the first time. If only we did a better job of defining requirements then …The agile community argues that: The cost of change curve is as much a result of the process rather than intrinsic to software development Requirements, analysis & design should be
This is the “perceived wisdom” – the way that we have been taught.Get it right the first time.If only we did a better job of defining requirements then …
Agility is built on a holistic approach: Values -> Principles ->Practices.Agile methods emphasize face-to-face communication over written documents. Most agile teams are located in a single open office sometimes referred to as a bullpen. At a minimum, this includes programmers and their "customers" (customers define the product; they may be product managers, business analysts, or the clients). The office may include testers, interaction designers, technical writers, and managers.Agile methods also emphasize working software as the primary measure of progress. Combined with the preference for face-to-face communication, agile methods produce very little written documentation relative to other methods. This has resulted in unwarranted criticism of agile methods as being undisciplined.Customers don’t always know what they want:Hello. I’m a Traditional Developer. I’m going to build your product. I do what the BA tells me.Hello. I’m a Business Analyst. I’m going to articulate requirements for the developer. I listen to the product owner.Hello. I’m the Product Owner. I’m responsible for what goes in it. I’m going to tell the BA what it should do. I listen to the sales Manager to find out what features the product needs.Hello. I’m the Sales Manager. I know what features my customer wants, I listen to them.Hello. I’m Head of Procurement. I’m responsible for selecting the product. I tell the Sales Manager in the product company what we want. I know what we want because I listen to the Division Managers.Hello. I’m the Division Manager. I want a product that does %%&***£$%£ to drive my sales. Give me a product that does that.Hello. My name is Sally. I use the product. You know, the thing I really like about it is $%$£$$£^. And here’s a list of what I really hate. Give me a bit of $££%£$”£ and I’d be so much more productive. But no-one listens to me.Hello. I’m on an Agile Team. I’ve just sat with Sally for the morning and seen what she’s done. And you know what - we’re getting this wrong. What she really needs is ########. That would really add value. And it’s is far simpler, quicker and cheaper to deliver than what you were proposing.Change:Customers can’t express what they want (they usually don’t know until they see it).Even if they could express it – how effectively can you capture it – especially when there are multiple stakeholdersEven if you can capture it- how well can you write it down – English is ambiguous and it is tough to capture the intangible e.g. “user-friendly”Even if you can write it down – how well can it be interpreted by the development team?Even if it is interpreted correctly – how well can requirements actually be met?What if there is new technology, customer acquires a new company, new competitive forces, internal business changes?Reality Check: Change is inevitable: No amount of up-front work can guarantee that you know everything at the start: So deal with it.Harness change for delivering better customer value and winning customers over by listening and acting immediately (without a lawyer or an accountant in the room)
Team sprint focus is to get a failing customer to pass.Team daily focus is to get failing developer tests to pass and then refactor.
Q1: Test Driven DevelopmentMeasure “internal quality” of systemSmall unit tests drive design of small part of code.Larger integration tests drive system designAutomated, in same language, done by programmersRun often and at every checkinQ2: Story Driven DevelopmentMeasure “external quality” of systemStory tests drive higher level system designTests are more functional; more examples & combinationsTests boundary conditions, error handling, presentationQ3:Some tests in Q2 may be incorrect or incompleteTeam may misunderstand, agile customer may omit or forget somethingEmulate how a real user would use the systemManual testing – requires a humanExploratory/session based testingQ4:Performance, robustness, security etc.Sometimes not given enough focus on agile teamsOften requires specialized tools & expertise* Tests on right hand side feed into stories/tasks for left hand side
Q1: Test Driven DevelopmentMeasure “internal quality” of systemSmall unit tests drive design of small part of code.Larger integration tests drive system designAutomated, in same language, done by programmersRun often and at every checkinQ2: Story Driven DevelopmentMeasure “external quality” of systemStory tests drive higher level system designTests are more functional; more examples & combinationsTests boundary conditions, error handling, presentationQ3:Some tests in Q2 may be incorrect or incompleteTeam may misunderstand, agile customer may omit or forget somethingEmulate how a real user would use the systemManual testing – requires a humanExploratory/session based testingQ4:Performance, robustness, security etc.Sometimes not given enough focus on agile teamsOften requires specialized tools & expertise* Tests on right hand side feed into stories/tasks for left hand side
pair testers with developers for: exploratory testing testing bug fixes recreating newly found bugs automating tests fixing and testing "trivial" bugs as they are found - bugs that will only get fixed in geological timeframes have testers report on overall product quality (I was recently introduced to "Low Tech Testing Dashboards" by Paul Carvalho that is perfect for this) use testers as "consultants" and treat them as experts shift testers to a lead role directing whole team testing close to release use cards to drive exploratory test sessions consider bringing in "outside" testers for fresh perspectives voids the waste of tracking
