Proposals about gnucash-gnome2

[Andrew Sackville-West]

I'll be honest that I don't have time to do direct side-by-side 
comparisons or use a canonical set of test data (I've got too much real 
book-keeping to do...). But I'm more than happy to check out a new 
version every couple of weeks, and use it and report back. Obviously, 
there are parts of the program that I don't use, or rarely use, but I do 
  regularly use a/r and a/p, many different reports, and .qif imports 
and maintain three different data files with transaction counts from 30 
or so a month to upto say 250 a month. So my question is, what version 
would you like some testing on, and when should I start? Can you make an 
announcement on -user that such-and-such version is ready for pre-alpha 
testing, buyer beware ;), and then some of us can jump in?

I think, and hope you realise, that you guys have a fantastic program 
and the users are very loyal and more than willing to help out to the 
extent they can and I suspect you'd have plenty of testers.

As far as backups go, its as simple as a script to copy or rdiff the 
datafiles to another directory before opening gnucash --nofile. At least 
that's what I'd do so I would never lose more than one session's work 
(not that hard to duplicate) in event of catastrophic failure.

A

Josh Sled wrote:
> On Wed, 2005-10-05 at 17:21 -0700, Andrew Sackville-West wrote:
> 
>>Been lurking lately and wonder what is involved in testing and how can I 
>>help? I'm a daily user running three businesses with gnucash and have 
>>some very ancient programming experience. If I can help out by testing 
>>and (hopefully) giving useful feedback, I'd be happy to do it.
> 
> 
> - side-by-side comparisons of 1.8 and G2 looking for bugs, differences 
>   and regressions.  This can happen at any point... including now so we 
>   have a good handle on how much work is left.  Anything noted should 
>   go into GNOME2_STATUS (rather than bugzilla).
> 
> - a canonical set of test data files would be invaluable as people come 
>   on board and want to test or report issues.  While we also want to 
>   encourage people to use their own, real, data to expose the code to 
>   variety, it's nice to have a known set of data to share, reproduce, 
>   converse-about and synchronize against.
> 
>   My ideal version of these files would include the minimum number of 
>   cases to test every feature, account-type, default- and 
>   secondary-commodity, reconciliation scenario, and situation.  
>   Obviously this is impractical, but we can at least hit the major ones 
>   pretty easily.
> 
>   We'd also want a set of fairly regular data to test reporting, 
>   balance-computation, &c.  One could probably script-generate some QIF 
>   transactions to import (or maybe an XML datafile directly) or get 
>   creative with their system clock and the scheduled transactions, to 
>   create a year's worth of data with computable properties (all 
>   expenses should sum to $20,000; the Expenses:Rent should have 12 txns 
>   of $1000 ea., &c.)
> 
> - test instructions or scripts for other/new people to execute against 
>   in different environments... including us. :)  Especially with all 
>   the UI work done, we're going to need to test actually stepping 
>   through a set of interactions with the UI to make sure things work as 
>   expected.  The other side is that if people are stepping through the 
>   same set of instructions, you're only testing that one path through 
>   the UI and missing other cases... but I still think there's value 
>   here.
> 
> ...jsled