0
Agile Testing
Irina Popovici
Agenda
• Agile testing success factors
• Waterfall against Agile
• Scrum ceremonies
• Scrum team
• Agile Quality
• Tester ...
Agile Testing Success Factors
• Be cathedral builders not stone cutters
• Collective ownership
Testers are part
of the tea...
Agile Testing Success Factors
• Session-based testing,
agile test environments
• Informative workspace
Foundation of
criti...
Requirements
• Business
Requirements
• Technical
Requirements
Analysis &
Design
• System
Specifications
• Component
Specif...
Cost
of
Change
Time
Agile Approach
Iteration 1
Requirements
Analysis & Design
Code
Test
Iteration 2
Requirements
Analysis ...
Agile Values
Individuals & Interactions
Processes & Tools
Customer Collaboration
Contract Negotiation
Working Software
Com...
Scrum Team
Product
Owner
• Feature
definition
• Release dates
• Single decision
point
• Accepts or
rejects work
• ROI
Scru...
Scrum Overview
MyBTEC Product Backlog
MyBTEC Sprint Board
Sprint Burndown chart
Retrospective meeting
Test Approach – The Agile Way
Project Initiation Get an understanding of the project
Release Planning Participate in estim...
Agile Quality – A Team Deliverable
Agile Practice Benefits
Whole Team • Quality is not just a tester
responsibility
• Qual...
CritiquesProduct
SupportsDevelopment
Brian Marick’s Agile Testing Matrix
Functional Tests
Customer Tests
Story Tests/Examp...
CritiquesProduct
SupportsDevelopment
Tester Activities
Product Specifications
Test Ideas
Testing
UAT Design
Exploratory Te...
Agile Testing Iterations
Previous
Iteration
Stories
Working
Product
Q3, Q4:
Product
Testing
Current
Iteration
Stories
Work...
Test Automation Pyramid
UI Tests
Acceptance
Tests
Unit Tests
Manual Tests
Skills of Agile tester
• “Traditional” testing skills
• Automation / development
• Exploratory testing
• Communication and...
Benefits of being an agile tester
• Work together as one team towards a
common goal
• Less risk of squeezed test period
• ...
Thank you for listening!
Any questions?
Upcoming SlideShare
Loading in...5
×

Agile testing MyBTEC

519

Published on

Published in: Education, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
519
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
36
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • 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
  • Transcript of "Agile testing MyBTEC"

    1. 1. Agile Testing Irina Popovici
    2. 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. 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. 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
    5. 5. Requirements • Business Requirements • Technical Requirements Analysis & Design • System Specifications • Component Specifications Code • C#, C, C++ etc. • Big-Bang Integration Test • Validation Tests • Verification Tests DeployCost Of Change Time Traditional Approach - Waterfall
    6. 6. Cost of Change Time Agile Approach Iteration 1 Requirements Analysis & Design Code Test Iteration 2 Requirements Analysis & Design Code Test Iteration 3 Requirements Analysis & Design Code Test Iteration 4 Requirements Analysis & Design Code Test Deploy
    7. 7. Agile Values Individuals & Interactions Processes & Tools Customer Collaboration Contract Negotiation Working Software Comprehensive Documentation Responding to Change Following a Plan
    8. 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
    9. 9. Scrum Overview
    10. 10. MyBTEC Product Backlog
    11. 11. MyBTEC Sprint Board
    12. 12. Sprint Burndown chart
    13. 13. Retrospective meeting
    14. 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. 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
    16. 16. CritiquesProduct SupportsDevelopment Brian Marick’s Agile Testing Matrix Functional Tests Customer Tests Story Tests/Examples User Acceptance Tests Exploratory Tests Usability Tests Unit Tests Integration Tests Performance Tests Load Tests Customer Facing Technology Facing Automate Tools Manual Q1 Q2 Q3 Q4 Automate
    17. 17. CritiquesProduct SupportsDevelopment Tester Activities Product Specifications Test Ideas Testing UAT Design Exploratory Testing Usability Testing Test Ideas Test Development Testing Test Scripts Testing Test Analysis Customer Facing Technology Facing Product Owner Collaboration Customer Collaboration Q1 Q2 Q3 Q4 IT Collaboration Developer Collaboration
    18. 18. Agile Testing Iterations Previous Iteration Stories Working Product Q3, Q4: Product Testing Current Iteration Stories Working Product Q1: Testing & Collaboration Next Iteration Stories Working Product Q2: Planning & Test Ideas
    19. 19. Test Automation Pyramid UI Tests Acceptance Tests Unit Tests Manual Tests
    20. 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. 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
    22. 22. Thank you for listening! Any questions?
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×