To continue reading for free, register below or login
To read more you must become a member of SearchSoftwareQuality.com
John Overbaugh answered a very similar question to this one here. His advice is quite sound, and I don't want to repeat it in detail. If you haven't read that post, please go do so now.
  |
|
What's important in the selection isn't how closely your practice mirrors what's defined in the methodology, but instead how well it works for you.
|
  |
It's ok, I'll wait…
When I think about the methodology I use with my current team, I recognize that it's a collection of different things all duct-taped together. If I think about the other places where I've implemented the testing methodology for the group, I find that I've often done that. What's important in the selection isn't how closely your practice mirrors what's defined in the methodology, but instead how well it works for you.
When I read your question, my immediate response is to tell you to implement all of them and none of them. I know that doesn't seem very helpful, but in many ways it's the only way you'll figure out what works for you. I suspect no off-the-shelf methodology will solve your problems. That's because your problems are unique to you and your context.
My current team uses session-based test management to manage our exploratory testing. We have to integrate that into Scrum using two-week sprints. We also have to manage large suites of regression tests, which to a great extent require us to work outside of the session-based test management chartering, testing, and debrief process. We also have to track and trace some of our work back to client-facing project plans, which requires some additional overhead and we've started to pull some V-Model elements in to help with managing that.
I also recognize that as my team matures in their testing, and as the development team matures in their development practices, my team's testing methodology will evolve slowly over time. Five years from now, we should be using a different methodology then we are using today. As we grow and change, our methods and tools will need to grow and change with us.
|
