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

1. NO PRODUCT TO TEST YET?
NO PROBLEM.
IRJA STRAUS

2. WHY WOULD YOU LISTEN TO THIS TALK?

3. BECAUSE...
What they meant... ...what I think they meant.
Documents can be misunderstood.

4. ...OF REASONS
We want to improve our work.
› Designers > cleaner design
› UX researchers > intutitive flows
› Product owners > clearer requirements

5. ...OF REASONS
We want to improve our work.
› Designers > cleaner design
› UX researchers > intutitive flows
› Product owners > clearer requirements

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.

9. WHAT’S DIFFERENT?

10. MINDSETS ARE DIFFERENT
› Product: What problem to solve?
› Designers & Developers: How to solve it?
› Testers: How can the product fail?

11. TODAY WE LEARN ABOUT PRODUCT REVIEW
› Why review?
› Reasons
› Examples
› What is it?
› How to:
› design review
› requirements review

12. TESTING BEGINS EVEN BEFORE A
SINGLE LINE OF CODE IS
WRITTEN.

13. BUT WHY?!

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

16. LET’S SEE EXAMPLES

17. Dogfood 1#
Dude, where’s
my data?

18. Idea was awesome...

19. ...but hidden from users

20. And when they finally found it...

21. ...promises were made...

22. ...but feedback came as a surprise.

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.

25. Dogfood 2#
They will
resolve, you
say?

26. When business requirement...

27. ...is not clear even to its creator.

28. ...is not clear even to its creator. Invalid people,
you say?

29. ...is not clear even to its creator. What are
duplicates?

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.

33. What is
and how to
PRODUCT
REVIEW?

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?

41. RATE TALKS
THANK YOU!
MAY THE TESTING FORCE BE WITH YOU ☺
https://joind.in/talk/cb270