Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

No product to test yet? No problem. By Irja Straus @ WebCamp 2019 (Zagreb)

164 views

Published on

Testing begins even before a single line of code is written. This talk will show you why, and how.

Have you ever wondered how testers help developers to deliver a better product? Probably yes. However, have you ever wondered how they can give a helping hand even before a line of code is written? You probably haven't, and you have every right not to when there's no product to test. In this talk, I will eat my own dog food and use my failures as examples to demonstrate why including a tester's critical thinking early on is not such a bad idea in some contexts.

The talk was given at WebCamp 2019 (https://2019.webcampzg.org).
Leave your feedback here: https://joind.in/talk/cb270

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

No product to test yet? No problem. By Irja Straus @ WebCamp 2019 (Zagreb)

  1. 1. NO PRODUCT TO TEST YET? NO PROBLEM. IRJA STRAUS
  2. 2. WHY WOULD YOU LISTEN TO THIS TALK?
  3. 3. BECAUSE... What they meant... ...what I think they meant. Documents can be misunderstood.
  4. 4. ...OF REASONS We want to improve our work. › Designers > cleaner design › UX researchers > intutitive flows › Product owners > clearer requirements
  5. 5. ...OF REASONS We want to improve our work. › Designers > cleaner design › UX researchers > intutitive flows › Product owners > clearer requirements
  6. 6. WHY NOT REVIEW YOURSELF? Let me share my experience first...
  7. 7. WHO AM I? I’m Irja Straus A software tester Experience in: › business analysis › product management › ... and dogfooding nowadays Picture ccourtesy of Andy Glover, Cartoon Tester
  8. 8. Eating your own dog food, also called dogfooding, occurs when an organization uses its own product.
  9. 9. WHAT’S DIFFERENT?
  10. 10. MINDSETS ARE DIFFERENT › Product: What problem to solve? › Designers & Developers: How to solve it? › Testers: How can the product fail?
  11. 11. TODAY WE LEARN ABOUT PRODUCT REVIEW › Why review? › Reasons › Examples › What is it? › How to: › design review › requirements review
  12. 12. TESTING BEGINS EVEN BEFORE A SINGLE LINE OF CODE IS WRITTEN.
  13. 13. BUT WHY?!
  14. 14. A FEW REASONS IN FAVOR › Everybody wants to improve › Nobody likes doing things over › Nobody likes bugs, except testers
  15. 15. A FEW REASONS IN FAVOR › Everybody wants to improve › Nobody likes doing things over › Nobody likes bugs, except testers › But not even testers like them on production
  16. 16. LET’S SEE EXAMPLES
  17. 17. Dogfood 1# Dude, where’s my data?
  18. 18. Idea was awesome...
  19. 19. ...but hidden from users
  20. 20. And when they finally found it...
  21. 21. ...promises were made...
  22. 22. ...but feedback came as a surprise.
  23. 23. I SHOULD HAVE ASKED AT LEAST... › Are there any unnecessary steps? › Is the product giving useful feedback in a timely manner? › Is the experience broken in any way? ...for starters.
  24. 24. LESSONS LEARNED Sometimes the feedback is lagging, and users can get confused or lost. Don’t leave them hanging. Don’t break the experience.
  25. 25. Dogfood 2# They will resolve, you say?
  26. 26. When business requirement...
  27. 27. ...is not clear even to its creator.
  28. 28. ...is not clear even to its creator. Invalid people, you say?
  29. 29. ...is not clear even to its creator. What are duplicates?
  30. 30. ...is not clear even to its creator. What will automatically do?
  31. 31. I SHOULD HAVE ASKED AT LEAST... › Is the feature easy to understand? › Is it easy to make a mistake? › Can users recover easily? ...for starters.
  32. 32. LESSONS LEARNED Sometimes features are not simple to understand and can affect data integrity. Explain critical actions. Don’t allow users to slip away easily. If they still make mistakes, allow them to recover.
  33. 33. What is and how to PRODUCT REVIEW?
  34. 34. PRODUCT REVIEW ISASKING QUESTIONS ABOUT DESIGN AND REQUIREMENTS, WITH THE GOAL OF AVOIDING ASKING THEM AFTER DEVELOPMENT WHEN IT’S EXPENSIVE.
  35. 35. TESTING DURING A PRODUCT REVIEW IS UNCOVERING RISKS WHERE EVERYBODY ELSE SEES NO PROBLEM.
  36. 36. LOOK FROM DIFFERENT ANGLES › Business rules and flows › Requirements clarity › Use cases and data › Consistency › Risks When reviewing requirements
  37. 37. (SOME) QUESTIONS TO ASK › Are there any complicated features? › Are there any unused features? › Are there any unnecessary features? › Are there any missing features? › Are there any foggy features? › Are there any risks?
  38. 38. CONSIDER THESE THINGS › Test on realistic and complex use cases › Layout and elements › User experience › Consistency › Content When reviewing design & UX
  39. 39. (SOME) QUESTIONS TO ASK › Is the product easy to use? › Is the product too easy to use? › Is the product overcomplicated? › Is the product giving useful feedback? › Is the product self-explanatory › Is the product consistent with the quality criteria?
  40. 40. TAKEAWAYS Oh, I member! › Ask questions : Clear the air. › Ask for feedback : Sharing is caring. › Test earlier : Apply critical thinking. Member?
  41. 41. RATE TALKS THANK YOU! MAY THE TESTING FORCE BE WITH YOU ☺ https://joind.in/talk/cb270

×