Successfully reported this slideshow.
Your SlideShare is downloading. ×

Being an Agile Tester

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Upcoming SlideShare
Scrum training day 2
Scrum training day 2
Loading in …3
×

Check these out next

1 of 85 Ad

More Related Content

Slideshows for you (20)

Similar to Being an Agile Tester (20)

Advertisement

Recently uploaded (20)

Being an Agile Tester

  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. Help in Story Writing Help to define the scope of the stories Write Acceptance criteria Think on Testing aspects What other thing we need to consider? Planning Help with Story estimation Make sure there is enough time to test
  14. 14. 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.
  15. 15. 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 … … …
  16. 16. Understanding the story Explain how this is going to be tested Ask question that will help to set clear scope boundaries Task decomposition Add testing tasks (what about automation) Make sure programmer do some unit test What about setting up the system? Help with estimation
  17. 17. 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
  18. 18. Report on your progress Push work to testing as soon as possible Guard the sprint time-box Will there be enough time for testing? “Code that isn't tested doesn't work— this seems to be the safe assumption.” Kent Beck 2002
  19. 19. Get feedback General feedback – are we headed in the right direction Specific feedback – to the stories completed feedback should reflect in product backlog.
  20. 20. Share your story What have been done (and tested) Where do you feel are the weak points? Provide general feedback to the PO & stakeholders
  21. 21. 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.
  22. 22. 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).
  23. 23. “The Product Owner is responsible for maximizing the value of the product and the work of the Development Team… The Product Owner is the sole person responsible for managing the Product Backlog …. The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable. … The Product Owner is one person…” – Scrum guide
  24. 24. 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 Product conflicts resolution
  25. 25. “The Scrum Master is responsible for ensuring Scrum is understood and enacted … The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.” – Scrum guide
  26. 26. Finding techniques for effective Product Backlog management Helping the Scrum Team understand the need for clear and concise Product Backlog items Understanding product planning in an empirical environment Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value Understanding and practicing agility Facilitating Scrum events as requested or needed.
  27. 27. Coaching the Development Team in self- organization and cross-functionality Helping the Development Team to create high- value products Removing impediments to the Development Team’s progress Facilitating Scrum events as requested or needed Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.
  28. 28. Leading and coaching the organization in its Scrum adoption Planning Scrum implementations within the organization Helping employees and stakeholders understand and enact Scrum and empirical product development Causing change that increases the productivity of the Scrum Team Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.
  29. 29. “The Development Team The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. … Development Teams are structured and empowered by the organization to organize and manage their own work…” – Scrum Guide
  30. 30. They are self-organizing. Development Teams are cross-functional Scrum recognizes no titles for Development Team members other than Scrum recognizes no sub-teams in the Development Team Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.
  31. 31. 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
  32. 32. 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.
  33. 33. 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.
  34. 34. Versatile Should be able to do several things. Responsible Take ownership of the process Collaborative “Lone wolves” generally does not fit an agile team.
  35. 35. 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
  36. 36. 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.
  37. 37. Represents the customer. Provide feedback about new work. Improve the testing process. May help in defects handling.
  38. 38. 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.
  39. 39. 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.
  40. 40. Quality must have an owner. Train developers in effective testing. Build specialized internal testing tools Identify trends and areas of deteriorating quality.
  41. 41. 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)
  42. 42. 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.
  43. 43. Stakeholders always have questions: What’s the status? When will you finish? Why is it taking so long? Is the testing of __________ finished?
  44. 44. A report containing Product Areas vs. Test Effort, Coverage & Quality Assessment vs. Time
  45. 45. Testing Dashboard Ver. # - 1.1.4.31 Last Updated: 3/12/2016 Area Effort Cov. Qual. Remarks Suppliers Ship 3  Search Flow High 2+  Def 1674 Booking Flow Pause 2  Automation broken Auxiliary Operation Low 1+  Asmx Low 1  Memory leak Cont. search Blocked 0 No testing Env. Scoring & Connosuir Start (20/12) 0  MarkUp None 0
  46. 46. None - No Plan to Test Start - Expect to start testing soon Low - Mainly regression, keeping cov. High - In focus, increase cov. Pause - hard to test/stopped for now Blocked – Cant test this for now Ship - Final testing before live
  47. 47. 0 We don’t know 1 Sanity only 1+ some functional, not all 2 Finished Common cases + some 2+ did some error & edge cases 3 All Corner cases covered
  48. 48.    We don’t know about any problems that should stop production or suspect any. We know of possible showstoppers, or suspect there are some severe issues We have issue that should not reach production,.
  49. 49. 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?
  50. 50. 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
  51. 51. 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
  52. 52. The foundation that supports all of the rest. Majority of effort should be invested at this level. Very cheap to write and maintain, have high ROI. Very effective at catching regression bug Usually done by the programmer who writes the code
  53. 53. Should & can be automated Relatively cheap to write and maintain Business-facing tests Functional tests that verify we are “building the right thing” Should be written in domain specific language, that customers understand Operate at the API level, “below the GUI” They run more slowly, to cover complex scenarios
  54. 54. Focus on GUI operated tests: Written after code is completed, to critique the product Likely to change often (high maintenance)– as often as GUI changes Run slow & breaks often so we try to keep the number small Never use a recorder to generate them
  55. 55. Have a lot of value Should be intelligent (not scripted) Utilize human advantages over the computer (exploratory testing)
  56. 56. In Pairs: Find a volunteer. Have him map out his team/company testing process. Write down the different kinds/Levels of testing they perform. See if you can draw out his pyramid Lets Discuss
  57. 57. Automated Unit 60% - 70% Automated E2E 20% - 30% Exploratory 20% - 30%
  58. 58. 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.
  59. 59. 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
  60. 60. Developed by Elisabeth Hendriksom

Editor's Notes

  • Learning competition: Each team has a different color of sticky notes, The team with the most post-it’s on the wall wins.
    Feedback. please use the wall throughout the day so i can adapt to your needs.
    At the end of the day you have a free choice of which shade of green to use as the feedback card.
  • Always feel free to ask questions
  • Or hear from me…
  • Ask permission to take photoes
  • Theory Vs Practice
  • Lets talk in general about scrum
  • Agile Key Principle:
    Power Of Three (QA+Product+Programmers) (bring everyone to the table)
  • Working In High Quality
  • Feedback – Excercide – what can you do in your team to shorten the feedback loop?
  • Late Feedback is useless
  • The Process – Scrum
  • Debrief and Draw scrum on a flipchart
    (Probably a good time to take a break)
  • Lets do a deeper Dive into the process
  • Pigs and chickens
  • Not its done and we tested,
    more like:
    “its done and were very confident it works well and the entire system are is rock solid.”
    There’s a tough decision to make – can we release this?
  • Roles
  • For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one is allowed to tell the Development Teamto work from a different set of requirements, and the Development Team isn’t allowed to act on what anyone else says.
  • Scrum guide
  • Scrum guide
  • Scrum guide
  • They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;
    Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment
    Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person;there are no exceptions to this rule
    Scrum recognizes no sub-teams in the Development Team, regardless of particular domains that need to be addressed like testing or business analysis; there are no exceptions to this rule; and
    Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.
  • But first a short demonstration – circle with two friends
  • Provide feedback
  • Lets draft a job posting
    Focus on:
    What is the goal of the role? – 5 minutes
    What will he do/be in charge of? – 5 minutes

    What skills would you must have, - 3 minutes
    What skills would you like to get as well

    What kind of Traits the person should have

    What kind of experience/Education do you need from him
  • And they always lack patient to hear all the details!!!!
  • Product Areas – 10-15 no more. Major parts of the system, which are important/significant to stake holders
    (wht are the top 10 things you system need to do?)
  • Feel free to change add your own levels, make sure everyone understand what they mean
    Use red to mark significant problems
    Use green to denote were done, everything else is green, and we can ship (or almost there)
    Black – in process
  • Color green if coverage is enough for shipping
    Otherwise balck
    0 -1+ does this product work at all
    2 most of testing – 50-90% fnctionality coverage
    2+ - did some ilities testing, can this product work in live?
    3 – if there was a bad bug, we would have known
  • in groups, pick a produt from one of the companies,
    Think of the areas (come up with 10 and explain to the entire group) – this should cover your system,
    Think of the current effort invested in the various areas for the upcoming release
    Think of the coverage goal and the current state
    Do you know of any specific issues in those areas – try to use real data as much as possible
  • Business KPI’s
    Here comes DevOps
  • Because these tests bypass the presentation layer, they are less expensive to write and maintain, and they are less brittle
  • Recorder is only good to discover the GUI layout
  • Exploratory testing is the key word here
  • Not the same organization
    When finished switch
  • If have time…
  • Q4 – we can automate the run, but most likely we need someone to analyze the results
  • Discuss – take the backlog, create a shared understanding using examples (create the g/w/t acceptance criteria)
    Develop – in parallel automate the AC (Fixture Code), develop UT & production (using TDD)
    Deliver – run final manual tests, and deliver the new features (Preferably to a Real client)
  • Lets discuss about testing strategy
    * We skip the unit level – cause that a perliminary condition before everything else
  • Tools
  • Testing Tools
  • Build Servers
  • Management Tools
  • Lets talk about BDD/ATDD

  • Testing over the GUI & Recording
    First lets avoid recording – it doesn’t work!!!!!!
    it goes like this:
    You manually record all your tests (using manual testers which don’t know how to code)
    Then the system changes
    now you need to record them all over again (now isnt that manual testing?)
    Alternatively you give the tests to someone to fix.
    but they are not abstracted in any fashion – so the first time someone does this it usually takes a lot lot longer than just record them all over again
    Lose-Lose
    2) While the gui is probably the most obvious way to tap into the system fuctionality.
    In most system, it’s the the most cumbersome, error prone and unstable. And on the way you couple your test into the GUI structure (which for many modern system is the most dynamic part which changes often

    Buttom line – try to avoid as much as possible.

×