Apologies for the title.
Which are you (as a tester) most proud of? I'm going to make you choose.
Is it your domain knowledge, being the go to guy about this and that
piece of functionality? Wow, your changing that are you? That caused
problems last time. Oh and this is linked to that so if we change it, we'll need to be careful.
Is it your toolkit? Point me at anything and I can test it as I have the ability to craft a sensible context driven approach with the right tools for the situation.
As I've asked the question its only right I put my neck on the block first.
In my context, I'm most proud of my toolkit as in my line of work, domain knowledge is completely transient. I can be the king of the domain (and modest with it) one day, and pauper the next as I switch between industries.
But this is about much more than a set of tools and techniques, its about questioning fundamentals. Every new domain (to me) is the equivalent of a tour guide for an alien, with change blindness and functional fixedness barriers lessened allowing the appropriate approach and tools for the testing in hand emerge.
Build your toolkit. When the chips are down and you are in fix, they will serve you well. Encyclopedic knowledge of financial services when testing in an e-gaming context, not so much.
Monday, 9 September 2013
I've heard this statement a few times.
"There are no functional changes to the system, just a bunch of non functional updates to hardware and software."
What I really hear is:
"We are changing broad areas of the system, but we're not adding any buttons/fields/pages/widgets so we're going to classify this as a non functional project."
This sort of assumption needs to be challenged. If you are changing the foundation of a system, there cannot not be any functional changes! The reaction and interaction of a systems users dictates function. For clarity a user can be a human or another system in this context.
Do the following count as 'change?'
- System changes speed: If the system responds slower or faster, those using it will respond to that. Improving your performance can have negative impacts on the consumers of your system, if the user expects a certain speed of response.
- Systems inherent fragility changes: If the system has more or less availability this will change interaction. Expectations will rise (or fall), so might volume!
Remember, if you convert your teapot to be made from chocolate, its function is the same but it's behaviour is pretty different!