Eric Jacobsons recent blog entryWhat Does A Good Tester Resume Look Like has generated some interesting comments, I thought I'd take one part of it and see what responses the STC crowd would give

If you were to write a paragraph on your resume that would answer his point on "My approach to testing is as follows… " what would it say ?

Or would it be a 2 word answer of "it depends..." ?

Views: 2786

Reply to This

Replies to This Discussion

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 2 cents.
"Finding out."

That's what makes my heart sing!

"Attending meetings, churning out the reports and plans for the quality gates".


That's what makes my heart sink! ;-)
I would say "My approach to testing is flexible and pragmatic".

I would then explain the different types of testing I have used at my prior companies, and why they were appropriate for the context.

On a resume (unless you intend to stick to only one testing approach throughout your career) you should be careful not to make it seem that you have a dogmatic approach to testing.
Hi Phil,

Nice question, interesting responses so far!

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.

Thanks,

- Rob

P.S. I shave with Occam's Razor! :D
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.
Hi Phil, here's my two cent's worth:

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.
Kind regards,
Zeger
I would google "My approach to testing" and copy and paste the first result onto my CV. :-D
yeh, someone did message me and said they didn't want to reply as it might get used in other peoples resumes...
That's kind of funny but unfortunately he/she is probably right in that assumption.
I'd love to think my contribution would help someone get a job, but somehow I doubt it! :-)
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.

RSS

Adverts

Ministry of Testing

© 2014   Created by Rosie Sherry.

Badges  |  Report an Issue  |  Terms of Service