Hi all and sorry for late answer :) ... > > it is not enough to solve problem of release stability. This tester will > > find a lot of bugs after new code will be added to the trunk and then we > > will need to fix them on RC stage. It is bad > > practic to add new features on RC stage. > > I think that we should follow the scrum methodology, in which each > sprints delivers a piece of software / enhancement that's ready to > ship and adds value to the product. With this in mind this is how it > will work: > > - Sprint starts > - Developers think how to solve the problem > - Tester thinks how to test the developers solution > - Developers create code > - Tester creates tests > - Developer commits code to the trunk (or a branch if the change is too big) > - Tester gets the code from the trunk and runs scans against his test pages > - Tester gets the code from the trunk and runs regression scans > - Developer fixes regressions and bugs > - Sprint ends [2 weeks after starting] > > > New code especially when it touches the core or simply has a lot of lines > > in most > > cases will bring bugs. It is the bad truth of development. > > I think that if we really stick to the above procedure, we shouldn't > have any issues :) Hmm, ok. Let it will be SCRUM :) It will be interesting to see how it will work with open source project.
-- Taras http://oxdef.info ---- "Software is like sex: it's better when it's free." - Linus Torvalds ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ W3af-develop mailing list W3af-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/w3af-develop
