Talk: On software Into the mind of a tester
Author: Kasper B. Graversen
[Introduction] [All categories] [All articles] [Edit article 
]
Testing
Talks
To grow as a developer one must look broader than only improving coding skills. In any serious software shop, developers work in close collaboration with testers or a QA department. In this extremely entertaining talk, you will be taking into the mind of a good tester and understand how testers think and test. Ultimately this talk will help you improve how you communicate with testers when you need them to test your stuff.
Please show your support by sharing and voting:
Table of Content
1. James Bach
James Bach is a controversial figure in the testing community. Mostly because he if of the opinion that all you've learned in testing classes is pure garbage. In this talk he goes through a number of examples to prove that point.
Allow the speaker around the 5 minute mark to really warm of. From that point on its just pure hilarious jokes mixed with ranting but at the same time really educative. I hope you enjoy it as much as I have (and I've watched it couple of times already).
Some of the main take-aways
- Academic testing curriculum is pure garbage.
- UML diagrams are not the system that is under test - tests are made on the real world, and any diagram will be misleading or too simplistic. Don't trust any picture a developer show you!
- You cannot properly test if you do not understand the context. Think outside the box and understand the context of the code to test, so you can hone in on the relevant test scenarios.
- Sometimes it makes sense to test outside the specified boundaries of the specification.
2. The video: On software testing
You'll find many similar talks to this one, but I think this one is the best. Mostly due to the fact that James seem much more relaxed and more fun.
Happy laughs
Please show your support by sharing and voting:
Congratulations! You've come all the way to the bottom of the article! Please help me make this site better for everyone by commenting below. Or how about making editorial changes? Feel free to fix spelling mistakes, weird sentences, or correct what is plain wrong. All the material is on GitHub so don't be shy. Just go to Github, press the edit button and fire away.
Read the Introduction or browse the rest of the site