Mindset of a Ninja Tester - Vaido Vähk - QA Lead @Mooncascade
Download as PPTX, PDF1 like1,991 views
The document discusses the mindset of a tester, illustrated through the perspective of a research scientist focused on product development. It emphasizes the importance of identifying potential problems and understanding user behavior, highlighting the difference between testing and demonstration. Additionally, it outlines various heuristics and considerations for effective testing, as well as providing references for further exploration of the subject.
Mindset of a Ninja Tester - Vaido Vähk - QA Lead @Mooncascade
- 1. Mindset of a (Ninja) Tester Vaido Vähk
- 2. Who is a tester
- 4. And the Developers be like ...
- 5. If we break anything it's ...
- 10. I’m a research scientist. • My field of study is a product that’s in development. • I research the product and everything around it to discover things that no one else has noticed so far. • An important focus of my research is potential problems that threaten the value of the product. • Other people—builders and managers—may know an immense amount about the product, but the majority of their attention is necessarily directed towards trying to make things work, and satisfaction about things that appear to work already. • As a scientist, I’m attempting to falsify the theory that everything is okay with the product. • So I study the technologies on which the product is built. • I model the tasks and the problem space that the product is intended to address. • I analyze each feature in the product, looking for problems in the way it was designed. • I experiment with each part of the product, trying to disprove the theory that it will behave reasonably no matter what people throw at it. • I recognize the difference between an experiment (investigating whether something works) and a demonstration (showing that something can work). By Michael Bolton
- 14. A good tester tries to walk in end-user's shoes... … all of them
- 15. Why a user MIGHT do that.. • The user was distracted by something, and happened to omit an important step from a normal process. • The user was poorly trained in how to use the product. • The user was curious, and was trying to learn about the system. • The user was in another country, where they use commas instead of periods, dashes instead of slashes, kilometres instead of miles… Or where dates aren’t rendered the way we render them here • The user was a hacker, and wanted to find specific vulnerabilities in the system. Etc. ...the toilet story...
- 18. There is no best practices, however...
- 20. I Sliced Up Fun • I – Input. • S – Store. • L – Location. • I – Interactions/Interruptions. • C – Communication. • E – Ergonomics. • D – Data. • U – Usability. • P – Platform. • F – Function. • U – User scenarios. • N – Network.
- 21. More on subject: • http://www.developsense.com/ - Michael Bolton • http://www.satisfice.com/ - James Bach • "Lessons Learned in Software Testing" - Cem Kaner … panel discussion ideas and questions!
Editor's Notes
- #6: I don’t just break stuff; I don’t break stuff at all. The stuff that I’ve given to test is what it is; if it’s broken, it was broken when I got it. If I break anything, I break dreams; I break the illusion that the software is doing what people want.
- #8: What if I try it with 60, or 300 ? What does this system do? What if it's a medical device that will kill a person if it fails?
- #11: I’m a research scientist. My field of study is a product that’s in development. I research the product and everything around it to discover things that no one else has noticed so far. An important focus of my research is potential problems that threaten the value of the product. Other people—builders and managers—may know an immense amount about the product, but the majority of their attention is necessarily directed towards trying to make things work, and satisfaction about things that appear to work already. As a scientist , I’m attempting to falsify the theory that everything is okay with the product. So I study the technologies on which the product is built. I model the tasks and the problem space that the product is intended to address. I analyze each feature in the product, looking for problems in the way it was designed. I experiment with each part of the product, trying to disprove the theory that it will behave reasonably no matter what people throw at it. I recognize the difference between an experiment (investigating whether something works) and a demonstration (showing that something can work).
- #16: The user was distracted by something, and happened to omit an important step from a normal process. The user was poorly trained in how to use the product. The user was curious, and was trying to learn about the system. The user was in another country, where they use commas instead of periods, dashes instead of slashes, kilometres instead of miles… Or where dates aren’t rendered the way we render them here The user was a hacker, and wanted to find specific vulnerabilities in the system. Etc