To continue reading for free, register below or login
To read more you must become a member of SearchSoftwareQuality.com
To answer your question, I'll fall back to my transportation analogy (I recently blogged on requirements-based testing and how different automobiles may fit the requirements but still be of different quality -- check out my blog at http://thoughtsonqa.blogspot.com/2007/12/how-can-i-become-better-tester-part-ii.html.) In this case, I'll answer your question with another question. I need to buy a vehicle -- there are lots of choices out there, from sedans to mini cars to vans and trucks. Which vehicle should I buy?
Obviously there's no right answer until you can understand my transportation needs. Do I commute daily to work, as one individual? Do I take five other people with me every day? Do I have to transport a ton of building materials? It's the same for testing: there is no one single right methodology. I think the question you're more likely to get an answer to is "How do I choose the right testing methodology for my project?" That question is more specific, and with some research on your part you'll be able to arrive at a decision with some confidence.
The factors I use in decided which methodology is appropriate for a given project include:
- Is there a project-wide methodology in place? I recently started work on an agile development project. Our approach pretty much has to be agile testing, in order to keep up with the development team. We are light on documentation, only recording the manual cases we must run. The project includes several Web methods rolled up in one Web service, so we are authoring and tracking our test cases of the Web methods in the tool we are using to test -- SoapUI Pro. (A shameless plug for SoapUI Pro -- the company writing and selling this tool is incredibly responsive to questions we have had, and very helpful in directing our implementation. In addition, the tool is built around a test case metaphor, which makes it easier for us to track our cases within the tool and not need to have a second set of cases somewhere else.) We're very light and agile and, although we're still learning about agile testing, we feel we're successful so far.
- Is there a methodology dictated by management or by the customer? It's generally difficult to push back against top-down directive management, unless you can couch it as an experiment to find more effective or efficient solutions.
- Is there an approach which best lends itself to your project? In a test factory, outsourced approach sometimes a waterfall model is the right thing to do. Getting the software in a factory model means, in essence, a development team somewhere else has completed their code and have "thrown it over the wall" for QA. If this is the case, you may have to just go with it.
- Is there an approach your team is most comfortable with (sometimes, going with what works is the right thing -- and sometimes it's important to grow). The benefit (and I admit, there are very few…) of the waterfall methodology is that it lends itself to teams with high turnover or very little experience. It's not the most efficient way to do business, but if you are plagued by these long-term management issues, you may have to stick with waterfall until your company can resolve them.
|
|
 |
Now, if you want my personal philosophy on this, I'm finding that agile testing, while offering a lot of challenges which I'm still grappling with, has a lot of promise. If teams can be truly agile (i.e. an "Agile project" is truly agile and not just a bunch of developers rebelling against documentation and management), I do believe they can get more work done, at a higher quality, in a shorter time. That having been said, I'm not necessarily comfortable with all aspects of agile testing. My personal opinion is that we'll see more of an agile approach introduced to testing, regardless of the methodology in place, but that this will change in its appearance over time.
By the way, as it turns out, my most recent transportation solutions have been 1) fixing up a used 1994 bicycle and riding it to work and 2) picking up a bus pass to use during bad weather. I get a lot of work done on the bus, and I get my workout in on the bike. The right answer for me, therefore, was "none of the above."
|
