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.

Mindset of a Ninja Tester - Vaido Vähk - QA Lead @Mooncascade


Published on

Presented on Monday, 12 September 2016 at MobileMonday Estonia: "Back to Basics - Testing"

Published in: Software
  • Be the first to comment

  • Be the first to like this

Mindset of a Ninja Tester - Vaido Vähk - QA Lead @Mooncascade

  1. 1. Mindset of a (Ninja) Tester Vaido Vähk
  2. 2. Who is a tester
  3. 3. Testers break stuff
  4. 4. And the Developers be like ...
  5. 5. If we break anything it's ...
  6. 6. 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
  7. 7. A good tester tries to walk in end-user's shoes... … all of them
  8. 8. 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...
  9. 9. There is no best practices, however...
  10. 10. ...heuristics !!!
  11. 11. 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.
  12. 12. More on subject: • - Michael Bolton • - James Bach • "Lessons Learned in Software Testing" - Cem Kaner … panel discussion ideas and questions!