Agile testing MyBTEC

  • 444 views
Uploaded on

 

More in: Education , Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
444
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
34
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    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

  • 1. Agile Testing Irina Popovici
  • 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
  • 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. 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. 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
  • 9. Scrum Overview
  • 10. MyBTEC Product Backlog
  • 11. MyBTEC Sprint Board
  • 12. Sprint Burndown chart
  • 13. Retrospective meeting
  • 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
  • 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. 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. 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. Test Automation Pyramid UI Tests Acceptance Tests Unit Tests Manual Tests
  • 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
  • 22. Thank you for listening! Any questions?