Re: We Want Quality

> From php-dev-return-22844-rodgers=nlm.nih.gov@lists.php.net Thu Jun 29 14:01:39 2000 [...] > > Looking into possibly creating a QA team would definitely be a good > idea. > > -Andrei I think this is a critical point. As a motivated enthusiast of PHP, if there is one weakness in the current development cycle that is *very striking* to me looking in from outside the development team, it is the lack of a clearly organized QA process. What follows is *not* criticism -- I'm deeply impressed by the entire PHP effort, deeply grateful for the efforts of everyone involved, and intend to continue to use PHP and encourage others to use PHP. But in trying to improve QA, you might ponder some of these suggestions: 1) Pick the n (~6) most "important" target platforms, and delegate a contact person for this platform. Announce these contacts clearly on the PHP site and/or by periodic notes to the mail list(s). 2) The contact person should be committed to fully installing the new release on her/his platform. Equally important, she/he should find a user of the same platform who is *new* to the installation (or relatively so, after all we want everyone to be using it 8^). You learn *important* things from a pair of fresh eyes. The newbie should also be committed to installing and testing, collaborating with the primary contact as required, who can shuttle information back to the development team. 3) Accumulate a library of test applications to exercise PHP as thoroughly as possible. I'm no expert in regression testing, perhaps there is some clever way that test modules can be developed in parallel in with new features? What we need is something akin to javadoc in which the two activities are intrinsically related. 4) Discuss strategies to improve response to trouble reports on the list(s). The current method of "pick what interests you" seems pretty haphazard. Perhaps organizing the incoming stuff by platform/ OS and dividing them up chronologically? The primary platform contacts might serve as the first line of response, or have one or more colleagues handling that. Perhaps you could get additional folks to vet issues coming in for the "minor" platforms? Again, grist for the discussion mill, constructive suggestions, not criticisms. Cheerio, Rick Rodgers