Hi All, Like Mart - I'd better declare an interest and some knowledge in this area.
My company is Gerrard Consulting (www.gerrardconsulting.com) I'm very active in the UK and European testing community and have written a couple of books, done lots of conference work, host the UK Test Management Forum (uktmf.com) etc. etc. I am using Web2py to create a test management tool that we will use to support our testing services. (It's mainly for test design and record keeping in large software projects, rather than test execution). So I am very interested in a rock-solid Web2py as my company will depend on it :O) Right now, I'm full-on writing code and testing as we launch in mid- September. But I will be creating a performance/stress test for our app as we'll be making a free subset of the functionality available on our servers.Obviously scalability is a concenr for us. I'll probably use The Grinder (http://grinder.sourceforge.net/) to stage these tests, but that won't be for 5-7 weeks I think. I'd be very interested in collaborating to create some form of test automation regime for the Web2py infrastructure and applications using either available tools or maybe writing our own framework. (I'm looking to build an interface from my tool to things like Fit/Fitnesse (or replace them) and Selenium as I focus very much on acceptance testing). This might be the subject of another thread, perhaps. Sorry for the length of this, but I thought I should declare my hand and support for a 'stabilisation period'. Paul. On Aug 22, 2:25 pm, mdipierro <mdipie...@cs.depaul.edu> wrote: > Dear Mart, > Your help is very much appreciated. In particular because I am not > very knowledgeable about this aspect. > I am old fashion and for me the less I use mercurial the better. For > example I keep one single branch of web2py. I simply apply patches, > test them, and either revert or commit. This model has worked well > for me and I would not like to change it. > > I too am uneasy with the idea of freezing but not with the idea of a > testing period. How do you suggest we proceed? > > Massimo > > On Aug 22, 4:30 am, mart <msenecal...@gmail.com> wrote: > > > > > Good evening all, > > > I hope no one takes offense by me jumping in, but I couldn't help > > myself as the thread's subject got my attention (release management is > > what I do). If you'll allow me, I'm just curious as to the narure of > > your current branching strategy wrt the subject of the thread? In my > > experience, freezing a code line is rarely beneficial, least of all to > > the release going forward. So, was wondering if finding the correct > > branching strategy (as well as defining an appropriately well matching > > high level root folder structure in your source CSM) would help in > > sorting out such things as separating out and accommodating the need > > for stability, moving forward and any iterative requirements in your > > release cycles? (I heard someone last year year - obviously someone of > > the newer generation - call this "the need for speed" ;) ) But > > regardless, if at all interested I'd be happy to do my part and help > > out in any way I can if such plans are being considered. BTW - I was > > hired to revamp and restructure release management processes last > > spring for US based company, and web2py (with some Flex pieces in it > > for demo purposes) was what I used to to showcase and spread the word > > about the proposed changes :) > > > On another note: > > I saw that some PDF libs were on there way for web2py???? Awesome! I > > am looking forward to that! :) I made a web2py app a few weeks ago > > (mixing the ReportLab's tool kit and Flex/iFrames) so that the kids in > > my daughter's violin class (yeah ok, this may be a little weird, > > but...) could generate fingerboard position markers (which are then > > convert to printable PDF templates) so that the kids could create the > > exact position markers for their instrument (I think she hates things > > that are pitchy). Anyways, did not want to use LiveCycle data services > > (with flex) for this (although it does do some good things), and even > > though the results I got with what I used were a little ok (or most > > probably, the problematic parts had something to do with the guy > > writing the code :) ), generating PDF with good tooling will be great! > > I'm already a fan! :) > > > Thanks, > > Mart :) > > > On Aug 22, 1:02 am, Jason Brower <encomp...@gmail.com> wrote: > > > > Again I think we have more pressure for testing tools. Which I agree > > > on. > > > BR, > > > Jason > > > > On Sun, 2010-08-22 at 00:32 -0400, Andrew Thompson wrote: > > > > On 8/20/2010 4:54 PM, Phyo Arkar wrote: > > > > > -bug-squishing-contest , > > > > > -Stress test, Test everything , try to crash web2py etc. > > > > > Could we build an app to act as a test harness? > > > > > Or a script to build an app per a test case, evaluate it, then destroy > > > > that app, loop etc. > > > > > Turning bug reports into test cases causes regressions to be noticed > > > > quicker I would think.- Hide quoted text - > > - Show quoted text -
