Nice question Phil, and by nice I mean to say that it got me thinking...
I was about to say It depends... but that would be taking the easy way out and it wouldn't be 100% true.
I guess that after all these years if I have learned something that has defined my testing approach is to start by understanding the Business Needs of my Testing Task, and by this I mean not only to understand the users and the business of the company but also to be clear about the reason why the company needs this specific testing task and focusing my efforts on this task primarily.
I have found that many times we just run fast and hard forward without really understanding how our job fits with the business at hand.
My approach to testing is based on the Scientific Method. In essence: gather information; form a hypothesis (it works under a set of conditions), form the null hypothesis (it doesn't work); test into the null hypothesis using the principles of parsimony and falsification to attempt to disprove it.
In theory, it's not possible to ever truly complete testing so I would aim for a certain confidence level that my original hypothesis is true by virtue that the null is almost certainly false. Hence, the software is unlikely to fail for the customer.
It's a pretty generic method that's been around for over a thousand years and seems to work.
I recently was writing a resume, and someone asked me "but was differentiates you from other testers?" so I added the following sentence: I am a strong advocate for testing being more than writing test scripts and ticking check boxes. I firmly believe testing is not a clerical procedure, but an active investigative process which provides project teams with invaluable information about the state of their product.
My first reaction is to say "my approach depends...my style is following: ...". Not sure if style is the best word here, but there is something that I do different - I try to look for big bugs first. That may sound simple but it is not, it means:
1. I have to learn what Joel calls the reason for testing. I can't guess which bugs are big ones otherwise.
2. I don't test through: I test wide before testing deep, I guess critical tests to be done first, it means I'm jumping around the features a lot. I know about drawback of this style of testing and I force myself to use different style when appropriate, but then I loose all the fun of testing and soon get tired.
3. Sometimes I choose to ignore faults I encounter: if I can't repeat them and I don't have an evidence that they may lead a a big bug yet. I know that there is a very good chance that if this is a big bug I'll encounter more evidences (thanks to my style described in 2).
P.S. Context: I've been a test lead for last 10 years and I know that I could assign person with a different style when I know my style doesn't fit, so I've been developing my own style.
My approach to testing is: question -> investigate -> explore -> learn -> inform -> add business value.
Try to add business value to the stakeholders involved. What information do they want, what are the problems they are trying to solve?
All this is of course dependent on the kind of development project I find myself in. In a more agile environment there might be some additional focus on helping the team reach their goals.
My Approach to Testing:
- learning the application through whatever means;
- understanding the business from those who matter in so far as the application deals with it;
- balancing the conflicting priorities to try achieve more in less;
- try to make best choices even in the midst of a storm;
- marching and egging the people forward towards flag-posts in good times and more so in not-so-good times;
- fearlessly expose through testing what the world wants to hear and what they rather would not;
- continuing to be passionate and contaminate others;
- spreading the good word about testing learnt from masters after basking in it;
- being curious, wide-eyed, thinking, pragmatic, tough-as-nails, flexible and human.