I have recently been doing interviews and one question that I like to ask interviewees is "Where do you feel testers should sit within the V-Model?"
The V-Model (as pictured below) is a representation of how most "development" tasks have an 
equal "testing" task. I like to think of it as testings equivalent to Newton 3rd law.
This should be a good thing because it shows that there are different aspects of testing that need to be done during the software development lifecycle.
All the interviewee's seemed to give a different answer to the question above. Being the interviewer I was hoping for one of 2 answers.
The first answer would be one that made me rethink my thoughts on the V-Model. To be honest as an interviewer I am always looking forward to someone making me rethink a topic.
The other answer is that testing should encompass the entire V-Model. From the beginning of the Business Requirements stage to the end of the Acceptance Testing stage. The reason why I think this is because Quality Assurance should be in every aspect of the software development lifecycle.
I know that this is something from the Waterfall methodology but its a good way to see what needs to be done in the lifecycle and can easily be transformed into an Agile development.
Monday 9 June 2008
Interpretations of the V-model
Subscribe to:
Post Comments (Atom)
2 comments:
Hi David, I'm a long time reader but first time commenter. This is an interesting post! In the idealistic world where there are testers to spare, yes - QA and testing should be in there at every stage of the game. However, having been in software testing for over 10 years, I'd actually say "Depends". Depends on the software project, depends on the company, depends on the resources etc etc. Given that most software projects are under-resourced and don't always have enough testers anyway, you have to begin to pick and choose which stages to get involved in. I love the idea of developers testing their own code! - Therefore in my team I set it as a requirement for developers to write their own unit tests, which are then approved by the project test lead (me) when I'm happy they cover the code that's been changed. This allows me to be more efficient in doing other testing, and doing metrics, analysis etc.
As an aside, at the moment I'm the lead tester in a Scrum team, and there is no reason at all why the V-Model can not be used, even in a scrum team - just think of it on a smaller scale, and rethink your ideas of the "big project", and you begin to see that many of the V-Model characteristics can still be picked up and used. You still have requirements, you still have a user acceptance at the end, and all the bits in between! The challenge is in persuading the scrum team that you still need those checks and balances in an agile environment!
Hi Nick,
I used to agree with the "depends" but then got to a stage where Product Managers, Business Analysts and developers would create something and "throw it over the wall". Projects started to over run because testers didn't have enough lead team to get things ready.
This slowly but surely meant that the product we were delivering just wasn't right! I then decided to take the "heavy handed" approach and started sitting in requirements meetings (mostly uninvited) and slowly but surely, and after a lot of arguments, got people thinking about quality of the product not just the quality of the code.
I never left the business analysts and developers to get on with things without giving them the tools/skills to make sure that quality assurance became our main aim!
Just remember that you are creating a product that has an application and help text and other little things that all surround it. Not just the application!
Post a Comment