GnuCash Testplan First Draft

[Josh Sled]

ahmad sayed <ahmadsayed83 at yahoo.com> writes:

> This is Just a base for the gnucash testplan it will be developed over time, things may be removed and added. but it just beginning, The test cases not going to follow this order in creation, also there still TBD (to be done) issues, it is open for suggestions.

This looks like a good start.  Some notes...


> * GnuCash run and close properly.
[...]
> 	6 - Open an existing Project.
 
We don't use the terminology "Project" anywhere; it's just a "data file".

> 	7 - Gnucash Open the last recent project when it is opened
[...]
> 	A - for all these cases the default state gnucash is running test for the following dialogs
> 		 - File Menu dialogs
> 		- Edit Menu Dialogs
> 		- View Menu
> 		- Business Menu

The "Since Last Run..." dialog and the "Mortgage/Loan Druid" in the
{Actions > Scheduled Transactions} menu are testable in the same way, here.

> 	B - for all these cases  the default state gnucash opened and we have an acount Page, check that the following dailogs appear properly the testcase will be only open and dismiss it.
> 		- File
> 			1 - New Account Page
> 			2 - New Account Heirarch durid.Pre

"Pre"...?
 
> * Check  the tabs added and Close correctly correctly.
> 	- File 
> 		1 - new Account tab.
> 		2 - new Budget tab.

The "Scheduled Transaction List" in the {Actions > Scheduled Transactions} menu
can be validated in the same way.

> * All wizard give the expected set of dialogs.
> 	1 - New Account Hierarcy wizards.
> 	2 - Frist Time wizards.
 
Are these tests simply that the dialog opens up and can be dismissed, or
something more interesting?  For the New Account Hierarchy wizard, for
instance, there's a whole set of test cases that immeidately spring to mind.

The second item implies that the test framework should be able to modify
gconf keys before starting gnucash (in this case, to remove the "have seen
the first-time dialog" key).  Which makes perfect sense, but I don't recall
that this has been called out before.

 
> * Each Control in the dialog does its effect on the other controls in the same dialogs correctly, generate expected result 
 
Verifying the effect of (most of) the options in {Edit > Preferences} would
be very useful, too.

> 	- Find Dialog		
> 		1 - Add new Search Criteria.
> 		2 - Remove Search Criteria.
> 		3 - Using a data driven testcases apply various data and show if it returns expected result.
 
This suggests that you might want a set of crafted or generated known-state
data files... Like, a (set of) canonical "test-find-dialog-0.gnucash"
data file(s) that has the specific properties to be tested here.

> 	- Select HTML Style sheet.
 
I'd prioritize HTML/report style sheets case *after* almost everything else.

> 	- Find Customer.
> 		1 - Using a data driven test cases apply various search critiria insure it will returns the correct result.
> 		2 - Edit A customer data from This.
> 		3 - Invoke Find Job Dialog.
> 		4 - Invoke Find Ivoice Dialog.
> 	- New Customer.
> 		1 - Add New Customer and Search for it.
> 	 - Find Invoice.
> 		1 - Same as Find Customer.
> 		2 - Same as Find Customer
> 	 - New Invoice.
> 		1 - Add new Invoice.		

You might want to ensure these are in the correct order so that you're always
creating the entity that's required for a subsequent stage.  For instance,
you may need an Employee before you can start a Job.  I'm not quite sure what
that ordering is.

> * more testing to be considered Reports
> 	 - Reports < TBD >
 
Hmm.  I'm not sure if either GtkHTML or our report options dialogs are
a11y-friendly. :/

> * Performing Transactions
> 	 - TBD
 
It might be really hard to test the existing register, as I'm pretty sure
it's has both poor i18n and a11y support. :/ I think you should look into it
some more, of course, especially because it's "most" of the app.

> * follow a complete user happy path, e.g. following the tutorials in the GnuCash doc and 
>    automate all of them and confirm that you got the expected result at each step.
> 	 - Here I'm going to follow the tutorials

This is a really good idea, but it's going to be a function of our ability to
test the register, I fear. :/


(In the future, please make sure that you specify the mime type on
attachments; that one was attached as 'application/octet-stream' (an unknown
stream of bytes) rather than 'text/plain', which would have been a bit more
useful.)

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo ${a}@${b}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20070612/303405b4/attachment.bin