2011/1/28 Ian Walls <[email protected]>: > Paul, > > > I hear you. There are lots of really great features that are in limbo, > waiting to be tested. The unfortunate situation of life is that we're all > incredibly busy, and it's hard to find time to test things. This is > compounded when testing certain features requires coding or systems > experience, since that limits the pool of potential testers. As a result, > lots of good stuff sits, waits, and diverges. > > So what can be done? I don't think that changing the signoff procedure will > have the desired effect. That'll just let more unreviewed code slip in, > potentially introducing bugs we won't find for weeks/months/years. > > I think a better solution is make it easier to test and signoff on work.
I agree whole heartedly > There are several components to this: l> > Testing plans for larger developments/bugfixes > A robust testing data set made readily available > Teaching people how to test and signoff on code > > By including testing plans with developments or complex bugfixes, the > developer is communicating to everyone how they can prove their code works. > It lays out the intention of the development (it should do x, y and z), and > a series of tests to show how to get x, y and z without losing a, b and c. > > Combine this testing plan (written in language librarians can understand, > not coder jargon) with the necessary data set to do the testing (an SQL dump > you just load into a DB), and you've lowered the barrier for testing so that > anyone who can afford a little time to run through a series of listed > procedures can answer the question "does this work?". > > The third step to this is to lay out the procedure for running through the > test plan in a clear, simple manner, and distribute that information far and > wide. Make it something that librarians can do by following a list of > steps. Lowering the threshold of experience required to test things will > allow us to harness the Long Tail. > > To this end, I'm throwing my hat in the ring for Quality Assurance Manager > for Koha 3.6. My proposal can be found on the wiki > (http://wiki.koha-community.org/wiki/QA_Manager_for_3.6_Proposal), and much > of it is explained above. In addition to this, I would also serve as a > coordinator for testing work submitted, and provide regular reports to the > community on the status of these developments. Branches that are not > receiving active testing feedback would receive attention towards creating a > simpler, easier to follow testing plan. > That sounds like a great idea to me. I think that this is indeed missing, a champion of testing if you will, someone to pester people :) > I would very much like to discuss this at the next IRC meeting. It'll be > pretty early for me (5am, I believe), but I'll caffeinate heavily beforehand > :) > I think Ian has covered the sentiment of what I wanted to say, the problem isn't that stuff needs to be tested, I think we all agree things should be tested and signed off before going in master. But that testing is hard. Testing is made much harder by not following the one feature per branch rule. I just wanted to touch on one point Paul mentioned about the T::T work. We have been working to create a script to automatically convert H::T::P templates to T::T. Just so that we don't get into the scenario Paul mentions of having people having to rewrite their changes. Hundreds of hours of work have gone into making it so that the burden won't fall on the people submitting the code. Eventually we will stop accepting patches in H::T::P but it wont be write away, and certainly anything already submitted we wont be trying to make the authors rewrite. Chris _______________________________________________ Koha-devel mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
