My name is Tim Hall, and I’m a freelance software tester.
I haven’t always been a tester. In previous lives I’ve been a developer and then an analyst, including quite a bit of customer-facing work over the years. This helps give me the ability to see the big picture when dealing with extremely complex systems. I also haven’t forgotten how to code either.
A few of the things I have learned as a tester:
“Exploratory Testing” isn’t some revolutionary new technique, but describes what I’ve actually been doing for years. Ticking boxes on a test script is not only dull work, but you’re far less likely to discover any significant bugs.
If you’re supposed to be testing an interface with a third party product, and the third party product starts returning messages like “Object reference not set to an instance of this object”, then you’re also performing acceptance testing on the third party product regardless of whether that was supposed to have been within the scope of your testing.
Just because the functional specification says it’s a common function does not necessarily mean that it’s been implemented as a common piece of code.
If you have an adversarial relationship between testers and developers, you’re doing it wrong. Once got asked in a job interview “How do you avoid going native?”, and thought that was a rather ridiculous question. The common enemy is the bugs.
Using metrics related to bugs logged to measure performance of developers is just asking for trouble. It only succeeds in politicising the process of logging and classifying bugs and does nothing to improve software quality.
Test automation is an awful lot harder than either management thinks it is, or the tool vendors claim it is. Scripting high-volume repetitive tasks on a small part of the system adds a lot more value than attempting to automate an entire end-to-end process.