Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Testers in an agile world

155 visualizaciones

Publicado el

Slide deck of the Testers in an Agile World workshop, covering the mindset, role, expectations and practices of a tester of the agile kind.

Publicado en: Software
  • Inicia sesión para ver los comentarios

Testers in an agile world

  1. 1. Role Of A Tester Skills Testing Tools Team Structure Supporting The Team High Quality CI Feedback Loops ATDD/TDD Exploratory Testing Automation Company structure
  2. 2. Product Owner workshop by Practical Agile is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. A-HA wall Parking lot
  3. 3. Product Owner workshop by Practical Agile is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. 4
  4. 4. Product Owner workshop by Practical Agile is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. 5
  5. 5. Product Owner workshop by Practical Agile is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. Photos
  6. 6. Product Owner workshop by Practical Agile is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
  7. 7. In each Group: What are the 3 biggest issues your facing today, with you development process? Lets Discuss
  8. 8. Eliminate waste. Faster release cycles. Deliver maximum business value. Measure and improve. Respond to change. Increase quality. Have Fun.
  9. 9. SCRUM is very simple A complex process draws focus from real issues. SCRUM maximize feedback Using SCRUM everything is known. All the information to enable good decision making SCRUM is flexible Gives the ability to respond to change Inspect and adapt
  10. 10. First Step – Prepare the Product Backlog Stories Priority Estimate As a user I want to be able to input disability % data using a GUI, so it will be faster. 1 5 As a user I want to get the calculation result for a complex case 2 3 As a developer I want to be able to input disability % data using a text file, so it can be easier to test. 3 1 As a user I want to be able to store result to a file 4 1 As a user I want to be able to easily install the application. 5 3 As a user I want to be able to learn how to use the application 6 2
  11. 11. A story represents a requirement 3C’s – Ron Jeffries Card – Placeholder for conversation Conversation – discussion between implementer and customer Confirmation – Definition Of Done (DOD) Possible format: As a ____ I want ______ so that _____.
  12. 12. Stories Pri. Est. As a user I want … 1 5 As a user I want … 2 3 As a user I want … 3 1 As a user I want … 4 1 Stories Pri. Est. As a user I want … 1 5 As a user I want … 2 3 As a user I want … 3 1 As a user I want … 4 1 As a user I want … 5 3 As a user I want … 6 1 As a user I want … 7 1 As a user I want … 8 3 As a user I want … 9 1 As a user I want … 10 1 Sprint 2 Rest Stories Priority Estimate As a user I want … 1 5 As a user I want … 2 3 As a user I want … 3 1 As a user I want … 4 1 As a user I want … 5 3 As a user I want … 6 5 As a user I want … 7 3 As a user I want … 8 1 As a user I want … 9 1 As a user I want … 10 3 As a user I want … 11 5 As a user I want … 12 3 As a user I want … 13 1 As a user I want … 14 1 As a user I want … 15 3 As a user I want … 16 5 As a user I want … 17 3 As a user I want … 18 1 … … … Product Backlog Stories Pri. Est. As a user I want … 1 5 As a user I want … 2 3 As a user I want … 3 1 As a user I want … 4 1 As a user I want … 5 3 As a user I want … 6 5 Sprint 1
  13. 13. Sprint is a short cycle in which work get done. Typically between 1-4 weeks Once started, content does not change Goal Allow the team to work, without interference, in order to produce a potentially shippable product that will increase business value. A sprint results in a Product Increment.
  14. 14. Product Backlog Sprint Planning Story To Do In Progress Done As a user… As a user… As a user… As a user… Stories Priority Estimate As a user I want … 1 5 As a user I want … 2 3 As a user I want … 3 1 As a user I want … 4 1 As a user I want … 5 3 As a user I want … 6 5 As a user I want … 7 3 As a user I want … 8 1 As a user I want … 9 1 As a user I want … 10 3 As a user I want … 11 5 As a user I want … 12 3 As a user I want … 13 1 As a user I want … 14 1 As a user I want … 15 3 As a user I want … 16 5 As a user I want … 17 3 As a user I want … 18 1 As a user I want … 19 1 As a user I want … 20 3 As a user I want … 21 5 As a user I want … 22 3 … … …
  15. 15. Stand up meeting held every day (15 minutes). Each team member answer 3 questions (only) What has he done the previous day, What is he going to do today Is there anything holding him back (that the team can help with). Goals Daily planning Communication with other team members
  16. 16. Get feedback General feedback – are we headed in the right direction Specific feedback – to the stories completed feedback should reflect in product backlog.
  17. 17. Scrum is an adaptive process Review what went well and we want to keep, and what needs to be changed. Team forming Let the team be heard Let the team handle issues Reflect on overall plan Changes to release plans. Changes to goals.
  18. 18. Agile = no process Scrum is a rigorous process. Agile = No Documentation Agile stresses only needed documentation. Agile = No Design Design is an ongoing activity. Agile = No Planning Just in Time & just enough Information. Agile = Small Teams Has been scaled to very large groups (hundreds).
  19. 19. Goal Setting (on many levels) Responsible for the ROI. Responsible for the product backlog Writing Stories Prioritization Updating backlog Helps the developers understand what needs to be done DOD – Definition Of Done Conflicts resolution Approval of work.
  20. 20. Part of the Team No Authority on the team Roles Obstacle remover Facilitator External communication Responsible for the process Shield the Team
  21. 21. Estimate story size Split stories into tasks (sprint planning) Estimate tasks Build the product In charge of quality Communicate progress and impediments Improve!
  22. 22. In each Group: Go over the list of issues we have and see if you can find things in the process that might address them. Lets Discuss
  23. 23. Team size should be 5-9 members. Focus on team results: • Team must share a common goal. Team should be heterogeneous: • Include coders, testers, DBA, GUI,… Self Contained teams: • All required skills are present at the team level. • Allow the team to progress at full speed.
  24. 24. 1. Forming polite but untrusting. 2. Storming I know best. 3. Norming Maybe they can help me. 4. Performing They are really good. Tuckman added a 5th stage 10 years later: 5. Adjourning Time to move on.
  25. 25. Versatile Should be able to do several things. Responsible Take ownership of the process Collaborative “Lone wolves” generally does not fit an agile team.
  26. 26. Development and QA are often operational silos. Tests are derived from detailed requirements and specifications. Usually don’t actively participate in planning Almost never help in the product design
  27. 27. Testers are often viewed as second class citizens They are not active partners at building the product Developers considers testing as an obstacle in the delivery process. Testers do not get the necessary knowledge (from R&D) to test effectively.
  28. 28. Represents the customer. Approve new work. Improve the testing process. May help in defects handling.
  29. 29. Help define and elicit the acceptance criteria (or requirements) Preferably in the form of automated acceptance tests. Work with the customer (PO) to identify risks If its hard to test it might be very hard to use. Provide information to customer about Quality.
  30. 30. Performing regression tests When major changes are about to be committed. Validate acceptance criteria's Exploratory testing Put more testing effort into the areas where the developers tests (unit and integration) are weakest.
  31. 31. Quality must have an owner. Train developers in effective testing. Build specialized internal testing tools Identify trends and areas of deteriorating quality.
  32. 32. Two main strategies Handle as they come Postpone until next cycle and schedule as any other feature. Pragmatic approach Allocate resources for treating critical defects as they come. Postpone the rest (or when allocated resources are not enough)
  33. 33. Reproduce Defect Work with customer to understand the issue. Initial investigation Is it a defect or a misunderstanding. Root Cause Analysis Defects are not acceptable. Verify fix To make sure this wont happen again.
  34. 34. In each Group: Find a volunteer. Have him map out his team/company testing process. Write down the different kinds/Levels of testing they perform. Try to find how much effort is allocated to each kind Lets Discuss
  35. 35. The testing quadrants: Q1: UTs, component tests Q2: Functional tests, examples, story tests, prototyping, simulators Q3: Exploratory tests, Scenarios, Usability testing, UAT, Alpha/Beta Q4: Performance & load tests, Security tests, “illities” tests
  36. 36. The foundation that supports all of the rest. Make up the majority of the automation test scripts Written usually in the same language of the production code is, to increase communication within the team members, using xUnit family of tools After mastering TDD, these tests are with the most ROI, which means the least expensive ones Very effective at catching regression bug Usually done by the programmer who writes the code
  37. 37. Most of the automated business-facing tests Functional tests that verify we are “building the right thing” Operate at the API level, “below the GUI” Because these tests bypass the presentation layer, they are less expensive to write and maintain, and they are less brittle Should be written in domain specific language, that customers understand They run more slowly, to cover complex scenarios
  38. 38. Focus on GUI operated tests: Provides the lowest ROI in the pyramid Manipulate the system via the presentation layer Written after code is completed, to critique the product Likely to change often – as often as GUI changes Run slow & breaks often– so we try to lower the number of tests there. Never use a recorder to generate them
  39. 39. Have a lot of value Should be intelligent (not scripted) Utilize human advantages over the computer (exploratory testing)
  40. 40. If I Could have 3 magic boxes, I would like to know: 1. Am I doing things right? 2. Am I doing the right things? 3. Am I Adding Business Value?
  41. 41. This is what unit test are used for. Unit tests: Are fast Test each unit in isolation Enable me to test all paths of my code Will improve my technical design
  42. 42. E2E tests are a good tool for: Help me understand the requirements E2E tests: Goes through all the system Help me understand how the system behaves Help me refine Acceptance Criteria
  43. 43. Automated Unit 60% - 70% Automated E2E 20% - 30% Exploratory 20% - 30%
  44. 44. Unit Testing An integral part of the coding phase. (TDD) All code should be tested before it moves to next stage E2E Testing Most of the effort is done as part of the requirement. Actual automation in parallel to coding Exploratory Testing Final activity before Done.
  45. 45. Unit Testing Programmers (Each on his own code) E2E Testing Product + Testers (Programmers) – define the test scenarios Test Engineers/Programmers - Automation Exploratory Testing Expert testers
  46. 46. Developed by Elisabeth Hendriksom
  47. 47. The system need to work We need to be able to deploy it Satisfy minimum functionality Enough is enough Minimum viable product (Lean Startup)
  48. 48. The system needs to work well Scalability Security Availability… Enough is enough Quantify your goals.
  49. 49. Can the system be used? User Interaction design Graphical design Creating a community
  50. 50. The system needs to help the users Are the feature in use? The 80-20 rule Take out the feature which are not used they have negative ROI
  51. 51. The system solves a business problem Does it saves money? Does it save time? What are the business goals? Was it right for the business in the first place?

×