tag:blogger.com,1999:blog-4585201738600758310.post8529124413088183801..comments2008-06-10T11:13:25.861+01:00David Burnshttp://www.blogger.com/profile/11233457684822187675noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-4585201738600758310.post-51239689393656482552008-06-10T11:13:00.000+01:002008-06-10T11:13:00.000+01:00Hi Nick,<BR/><BR/>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.<BR/><BR/>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.<BR/><BR/>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!<BR/><BR/>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!David Burnshttp://www.blogger.com/profile/11233457684822187675noreply@blogger.comtag:blogger.com,1999:blog-4585201738600758310.post-43277570443372677482008-06-10T10:17:00.000+01:002008-06-10T10:17:00.000+01:00Hi 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.<BR/><BR/>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!Nick Youngwww.nn-y.co.uknoreply@blogger.com