Testing begins even before a single line of code is written. This talk will show you how I learned that fact through product management experience, which helped me to contribute now as a tester by utilizing critical thinking at the right time during the product definition. In this talk, I will eat my own dog food and use my mistakes to demonstrate why including a tester’s critical feedback helps assess and address risks when it’s not (so) expensive yet. I will explain some of the heuristics I use as “conversation starters” to perform risk-based product requirements and design reviews. The talk applies to practitioners on all levels. Still, managers and leaders are also welcomed to see what good can happen if testers are part of the conversation (early enough). https://testmastersacademyonline.org/ https://contest2021.sched.com/speaker/irja.straus

1. Developing Product Review
Practices (That Work)
Irja Straus
February 17th – 18th, 2021
@irjastraus

2. @irjastraus
„If requirements are written correctly...”

3. @irjastraus
Documents can be misunderstood
What they mean... ...what I think they mean.

4. @irjastraus
Feedback as motivation
We continuously improve with feedbacks.
› Developers < sustainable code
› Designers < functional design
› UX researchers < intutitive flows
› Product managers < highest revenue

5. @irjastraus
Why not (only) review yourself?

6. @irjastraus
QUESTIONS WE ASK ARE DIFFERENT
› Product: What problem to solve?
› Designers & Developers: How to solve it?
› Testers: How can the product fail?

7. @irjastraus
Eating your own dog food, also called dogfooding, is
when an organization uses its own product.

8. @irjastraus
Dogfood 1#
„Dude, where’s
my data?”

9. @irjastraus
Idea was awesome...

10. @irjastraus
...but hidden from users

11. @irjastraus
And when they finally found it...

12. @irjastraus
...promises were made...

13. @irjastraus
...and feedback came as a surprise.

14. @irjastraus
Dogfood 2#
Wait, human,
they will...
resolve?!

15. @irjastraus
When business requirement...

16. @irjastraus
...is not clear even to its creator. What will
automagically
do?

17. @irjastraus
Invalid people,
you say?

18. @irjastraus
What are
duplicates?

19. @irjastraus
TESTING BEGINS EVEN BEFORE A
SINGLE LINE OF CODE IS WRITTEN.

20. @irjastraus
PRODUCT
REVIEW

21. @irjastraus
PRODUCT REVIEW
IS ASKING QUESTIONS
ABOUT THE IDEA
TO AVOID ASKING THEM LATER
AFTER DEVELOPMENT WHEN IT'S
(TOO) EXPENSIVE.

22. @irjastraus
TESTING DURING A PRODUCT REVIEW
IS UNCOVERING RISKS
WHERE EVERYBODY ELSE SEES
NO PROBLEM.

23. @irjastraus
Learning what works (for my company)
Listen first
Learn about the people and their goals
› Build relationships internally
› Learn clients and user personas
Align on the quality characteristics
Then talk
Speak in their own language
› Colaborate and give relevant feedback

24. @irjastraus
When reviewing discussing requirements
1. Business rules and flows

25. @irjastraus
When reviewing discussing requirements
1. Business rules and flows
2. Requirement's clarity

26. @irjastraus
When reviewing discussing requirements
1. Business rules and flows
2. Requirement's clarity
3. Data and use cases

27. @irjastraus
When reviewing discussing requirements
1. Business rules and flows
2. Requirement's clarity
3. Data and use cases
4. Consistency*

28. @irjastraus
Inconsistencies can happen if we deliberately
innovate, and there is a reasoning behind it,
but to recognize that, I needed to know the
consistencies to ask the question.

29. @irjastraus
When reviewing discussing requirements
1. Business rules and flows
2. Requirement's clarity
3. Data and use cases
4. Consistency*
5. Project and product risk assessment

30. @irjastraus
(SOME) CONVERSATION STARTERS
„Show me the data”.
› Are there any unused features?
› Are there any unnecessary features?

31. @irjastraus
(SOME) CONVERSATION STARTERS
„Show me the data”.
› Are there any unused features?
› Are there any unnecessary features?
„If users might fail to recover, we might have a missing feature”.
› Are there any missing features?
› Are there any complicated features?

32. @irjastraus
(SOME) CONVERSATION STARTERS
„Show me the data”.
› Are there any unused features?
› Are there any unnecessary features?
„If users might fail to recover, we might have a missing feature”.
› Are there any missing features?
› Are there any complicated features?
„If the team doesn’t understand the idea when explained the first time, it’s worth
challenging the idea.”
› Are there any foggy features?
› Where are the risks?

33. @irjastraus
When reviewing discussing design & UX
1. Test with realistic and complex client use cases

34. @irjastraus
When reviewing discussing design & UX
1. Test with realistic and complex client use cases
2. Layout and elements

35. @irjastraus
When reviewing discussing design & UX
1. Test with realistic and complex client use cases
2. Layout and elements
3. User experience

36. @irjastraus
When reviewing discussing design & UX
1. Test with realistic and complex client use cases
2. Layout and elements
3. User experience
4. Patterns consistency

37. @irjastraus
When reviewing discussing design & UX
1. Test with realistic and complex client use cases
2. Layout and elements
3. User experience
4. Patterns consistency
5. Content and wording

38. @irjastraus
(SOME) CONVERSATION STARTERS
„User experience is like a joke – if you need to explain it, means it’s not that good”
› Is the product self-explanatory
› Is the product easy to use?
› Is the product consistent with the quality criteria, itself, real world?

39. @irjastraus
(SOME) CONVERSATION STARTERS
„User experience is like a joke – if you need to explain it, means it’s bad”
› Is the product self-explanatory
› Is the product easy to use?
› Is the product consistent with the quality criteria, itself, real world?
„If it’s easy to slip away, there should be an emergency exit”
› Is the product too easy to use?
› Is the product overcomplicated?

40. @irjastraus
(SOME) CONVERSATION STARTERS
„User experience is like a joke – if you need to explain it, means it’s bad”
› Is the product self-explanatory
› Is the product easy to use?
› Is the product consistent with the quality criteria, itself, real world?
„If it’s easy to slip away, is there an emergency exit?”
› Is the product too easy to use?
› Is the product overcomplicated?
„When action is expensive, the system should provide a clear status visibility.”
› Is the product giving useful feedback?

41. @irjastraus
Takeaway(s)
Oh, I
member!
Adapting my mistakes and different learnings into something that
actually works is a challenging but rewarding one.
Helps testing better, too.
Member?

42. @irjastraus
Credits
Pictures and icons made by different authors from:
www.flaticon.com
https://pixabay.com
https://unsplash.com
@irjastraus
Thank you!