- Spend time reporting problems that already exist in production, that users have not asked to fix.
- Demand all your bugs get fixed, despite the priorities of others.
- Keep your test results to yourself until you’re finished testing.
- Never consider using test tools.
- Attempt to conduct all testing yourself, without asking non-testers for help.
- Spend increasingly more time on regression tests each sprint.
- Don’t clean up your test environments.
- Keep testing the same way you’ve always tested. Don’t improve your skills.
- If you need more time to test it, ask to have it pulled from the sprint, you can test it during the next sprint.
- Don’t start testing until your programmer tells you “okay, it’s ready for testing”.
4 comments:
Subscribe to:
Post Comments (Atom)
RSS
That's gone straight into my QA forum, I love succinct lists like that, now I'll questions them tomorrow and check what they think ;-)
This is good!
I do not agree entirely with the last one, i see the point on testing before the programmer tells "it's ready for testing" but i also think that the testing process needs to be specific about input criteria, if it is not "ready" you might slow your team's velocity testing something that is not ready. Running tests on something that you know is going to change might be useless in some cases.
Miguel, good point! So we could add #11: "Complain about failed tests for something not expected to pass yet."
TDD and ATDD practitioners would argue there is still value testing unfinished features, right? But complaining about failed tests might never have value. See the difference?