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
6. WHY NOT REVIEW YOURSELF?
Let me share my experience first...
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. Eating your own dog food, also called dogfooding, occurs
when an organization uses its own product.
14. A FEW REASONS IN FAVOR
› Everybody wants to improve
› Nobody likes doing things over
› Nobody likes bugs, except testers
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
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. LESSONS LEARNED
Sometimes the feedback is lagging, and users can get confused or lost.
Don’t leave them hanging.
Don’t break the experience.
30. ...is not clear even to its creator. What will
automatically
do?
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. 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.
34. PRODUCT REVIEW ISASKING QUESTIONS
ABOUT DESIGN AND REQUIREMENTS,
WITH THE GOAL OF
AVOIDING ASKING THEM AFTER DEVELOPMENT
WHEN IT’S EXPENSIVE.
35. TESTING DURING A PRODUCT REVIEW
IS UNCOVERING RISKS
WHERE EVERYBODY ELSE SEES
NO PROBLEM.
36. LOOK FROM DIFFERENT ANGLES
› Business rules and flows
› Requirements clarity
› Use cases and data
› Consistency
› Risks
When reviewing requirements
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. CONSIDER THESE THINGS
› Test on realistic and complex use cases
› Layout and elements
› User experience
› Consistency
› Content
When reviewing design & UX
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. TAKEAWAYS
Oh, I
member!
› Ask questions : Clear the air.
› Ask for feedback : Sharing is caring.
› Test earlier : Apply critical thinking.
Member?