Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Software Testing without Requirements: Survival Guide

How to test software products without specifications or any documented requirements?

  • Soyez le premier à commenter

Software Testing without Requirements: Survival Guide

  1. SOFTWARE TESTING without requirementswithout
  2. NO TIME TO EXPLAIN! TEST! The situation:
  3. NO TIME TO EXPLAIN! TEST! The situation: No documentation No testing process No time to test everything
  4. HAVE YOU BEEN IN THIS SITUATION?
  5. No resources to create docs. Legacy product support. No knowledge to create docs.
  6. You are limited to testing only obvious things.
  7. Obvious things you can test. Things you can only guess.
  8. Techniques.
  9. High risk / No time Low risk / more time Exploratory testing Experience-based testing Error guessing Own experience Documentation No documentation
  10. High risk / No time Low risk / more time Exploratory testing Experience-based testing Error guessing Structure-based testing Use-case based testing Equivalence partitioning Boundary testing State-transition Decision tables Specification Use-cases Code Own experience Documentation No documentation
  11. High risk / No time Low risk / more time Documentation No documentation Exploratory testing Experience-based testing Error guessing Use-case based testing Equivalence partitioning Boundary testing State-transition Decision tables Specification Use-cases Own experience Structure-based testing Code
  12. SO, WHAT’S THE PLAN?
  13. The Plan. Exploratory testing1 Learn the product2 Create documentation3
  14. Exploratory testing Learn the product Create documentation
  15. Find the person responsible for the results of testing.
  16. It can be: Who is interested in testing? The Project Manager? The Customer?
  17. This person will help you to understand what is TRUE about Test Scenarios Pass/Fail Expected Results
  18. Start with risk- based testing. Most critical and high-use features Features you will release soon
  19. Log test scenarios. For regression testing. To learn system behavior. To confirm the tests.
  20. Confirm the test results. Until it is confirmed, this is only your assumption.
  21. Running the same tests over and over again would not show any new defects. Watch out the Pesticide Paradox!
  22. Notice defect clusters. 80% of bugs are caused by 20%of modules.
  23. Exploratory testing Learn the product Create documentation
  24. Learn: Users. Objects. Workflows. Product properties.
  25. Emails Notes Recorded issues Marketing materials What can be used?
  26. The product itself Competitors’ products
  27. Interviews with Stakeholders
  28. The Interview: Focus on Results 1: What should you get? Outputs 2: What will you use? Inputs Process 3: How is it done?
  29. Exploratory testing Learn the product Create documentation
  30. Visualize system requirements To build a “map” of the workflows To fit new tests in a whole picture
  31. Use-case diagrams Flowcharts “Screenflow” charts Tools:
  32. Screenflow chart example
  33. Document on a high level first. Just enough for testing Details will be added “as you go”
  34. Use-cases Checklists Tools:
  35. Add more details while you test. Connect high-level requirements and detailed test scenarios Use both bottom-up and top-down
  36. Exploratory testing Learn the product Create documentation Risk-based testing. Log the scenarios. Confirm the results. Users, Objects, Flows. Use legacy docs. Interview people. Visualize. Start with a high level. Top-down/bottom-up.
  37. Exploratory testing Learn the product Create documentation Exploratory testing Learn the product Create documentation Exploratory testing Learn the product Create documentation Repeat the pattern to obtain more and more knowledge on each step.
  38. HINTS AND HACKS
  39. Always inform people about the risks. You cannot test everything – test by priority. Aware of some developers, saying “it’s not a bug – it’s a feature!” Still the bug can be not the bug – discuss doubtful issues. Always follow up discussion with a written notes.
  40. KEEP CALM AND TEST, TEST AGAIN, THEN TEST SOME MORE
  41. Found it useful? Tweet about it! Oleksandr Lutsaievskyi, Agile Coach

×