Good Rules for Bad Testing

There are so many blog posts and articles about how to create the best QA team and what QA processes work the best and what you need to do to be a great tester, but there’s nothing that explains what not to do. No one talks about the dark side - the things that you need to stop doing to be a successful tester and run a great QA team. The reason I want to talk about this is that if we acknowledge these things, we can learn how to avoid common mistakes.

Transcript

1. GOOD RULES FOR BAD TESTING Talia Nassi
4. SIT AS FAR AWAY FROM YOUR DEV TEAM AS POSSIBLE, THE FARTHER THE BETTER 01
5. Avoid any requirements discussions or any sprint planning meetings 02
6. NEVER TALK TO YOUR PRODUCT PERSON. EVER. 03
7. Ask your developers how their features work, not the product person 04
8. Write all the tests yourself 05
9. Test in as many staging environments as possible, the more the merrier 06
10. Use a waterfall process. Agile = bad 07
11. Don’t update your tests with each feature, wait for your tests to break, and then fix them 08
12. Test your application on every browser and every version 09
13. Focus on documentation 10
14. Seriously.
15. 1. Sit with your dev team 2. Go to ALL planning meetings 3. Be BFFs with your product person 4. Don’t ask devs how features work 5. EVERYONE WRITES TESTS! 6. Test your code in production 7. Deploy to prod as often as possible 8. Update your tests with every feature 9. Test your application with only the most-used browsers and versions 10. Stop writing so many documents. You don’t need them
16. TALIA NASSI @talia_nassi talia.nassi@split.io Developer Advocate @ Split.io