Home > Archive > Extreme Programming > April 2004 > Help with Customer Test
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Help with Customer Test
|
|
| Shane Mingins 2004-03-30, 8:34 pm |
| XPerts ...
I have very little experience with testing software. Past employers have
generally had no guidelines to testing. My current employer uses pretty
much a waterfall approach to existing development where the software is
finally tested by users when completed. Test plans are devised on
spreadsheets and the users manually interact with the software. Partly this
is due to that development environment, for example I am not aware of nUnit
for RPG. Anyhow, background aside I am working alone in Java and trying to
learn/adopt TDD and some of the other XP practices.
Acceptance testing is the area that I am currently banging my head on.
Below is the senario that I have been struggling with and so I would
appreciate any helpful insight, comments, strategies, thoughts.
I have the following story that I would like to write and implement a
customer test:
Import Bank Statement Transactions
- Allow the user to import the transactions from a statement file to the
selected CMA Account.
- The transactions will be displayed in a table with the following
headings:
Date, Details, Tx Type, Sub Type, Type, Debit, Credit
Q. Possibly break story into two? Import Bank Statement Transactions &
Display Bank Statement Transactions
If I did break stories then testing the Import would be checking the table
model against a table of test data.
And testing the Display would be loading a table model with test data and
testing that display had data displayed as expected.
Q. Does splitting the story sound a good idea? Does it sound like it may
be easier to test? I am thinking perhaps so at this stage.
From the customer's perspective this is what they would like to be able to
do:
Testing Import & Display Statement Transactions
----------------------------------------------------------------------------
Step| Command | Action | test data | Expected Result
----------------------------------------------------------------------------
1 | ? |Start Application |location of |Applications starts
| | |application |showing menu tree
| | | |with root nodes
| | | |
2 |select tree |Open CMA Accounts |name of root|CMA Accounts are
|node |root |node | displayed
| | | |
3 |select tree |Select a CMA Account |name of cma |CMA account is
|node | |account node|selected with an
| | | |empty table of
| | | |transactions
| | | |displayed
| | | |
4 |select |Right click selected |starting |Statement File
|popupmenu |CMA Account and |directory ? |Selector displayed
|item |select Import | |
| |Statement menu item | |
| | | |
| | | |
5 |accept file |Statement File |statement |Statement
|selected |selected |file |transactions are
| | | |displayed in table
| | | |
| | | |
----------------------------------------------------------------------------
Where I get stuck is how to provide a way for them to provide test results
that will be verified against the actual results.
IOW ... they wish to provide a statement file like:
3,,"03-1234-9999999-00",-60.00,,000,"DE","ABC","","","BOB","01/03/2004",03
123
3,,"03-1234-9999999-00",150.00,,050,"DE","ABC","","","JOE","01/03/2004",03
123
and expected results for the table:
Date | Details | Tx Type | Sub Type | Type | Debit | Credit
--------------------------------------------------------------------
01/03/2004 | BOB ABC | WTH | 000 | DE | | 60
01/03/2004 | JOE ABC | DEP | 050 | DE | 150 |
The test should verify that the table data matches.
They wish to rerun the test for various CMA Accounts/Statement combinations.
So I have an outline of an idea of what I want to do. But not quite sure
how to do it.
Thanks
Shane
--
shanemingins@yahoo.com.clothes
remove clothes before replying
--
"Have no fear" - The Cat In The Hat (Dr Seuss)
| |
| John Roth 2004-03-30, 10:31 pm |
| "Shane Mingins" <shanemingins@yahoo.com.clothes> wrote in message
news:406a1827@news.iconz.co.nz...
> XPerts ...
>
> I have very little experience with testing software. Past employers have
> generally had no guidelines to testing. My current employer uses pretty
> much a waterfall approach to existing development where the software is
> finally tested by users when completed. Test plans are devised on
> spreadsheets and the users manually interact with the software. Partly
this
> is due to that development environment, for example I am not aware of
nUnit
> for RPG. Anyhow, background aside I am working alone in Java and trying
to
> learn/adopt TDD and some of the other XP practices.
>
> Acceptance testing is the area that I am currently banging my head on.
> Below is the senario that I have been struggling with and so I would
> appreciate any helpful insight, comments, strategies, thoughts.
>
> I have the following story that I would like to write and implement a
> customer test:
>
> Import Bank Statement Transactions
> - Allow the user to import the transactions from a statement file to the
> selected CMA Account.
> - The transactions will be displayed in a table with the following
> headings:
> Date, Details, Tx Type, Sub Type, Type, Debit, Credit
>
> Q. Possibly break story into two? Import Bank Statement Transactions &
> Display Bank Statement Transactions
>
> If I did break stories then testing the Import would be checking the table
> model against a table of test data.
>
> And testing the Display would be loading a table model with test data and
> testing that display had data displayed as expected.
>
> Q. Does splitting the story sound a good idea? Does it sound like it may
> be easier to test? I am thinking perhaps so at this stage.
>
> From the customer's perspective this is what they would like to be able to
> do:
>
>
> Testing Import & Display Statement Transactions
> --------------------------------------------------------------------------
--
> Step| Command | Action | test data | Expected Result
> --------------------------------------------------------------------------
--
> 1 | ? |Start Application |location of |Applications starts
> | | |application |showing menu tree
> | | | |with root nodes
> | | | |
> 2 |select tree |Open CMA Accounts |name of root|CMA Accounts are
> |node |root |node | displayed
> | | | |
> 3 |select tree |Select a CMA Account |name of cma |CMA account is
> |node | |account node|selected with an
> | | | |empty table of
> | | | |transactions
> | | | |displayed
> | | | |
> 4 |select |Right click selected |starting |Statement File
> |popupmenu |CMA Account and |directory ? |Selector displayed
> |item |select Import | |
> | |Statement menu item | |
> | | | |
> | | | |
> 5 |accept file |Statement File |statement |Statement
> |selected |selected |file |transactions are
> | | | |displayed in table
> | | | |
> | | | |
> --------------------------------------------------------------------------
--
>
> Where I get stuck is how to provide a way for them to provide test results
> that will be verified against the actual results.
>
> IOW ... they wish to provide a statement file like:
>
> 3,,"03-1234-9999999-00",-60.00,,000,"DE","ABC","","","BOB","01/03/2004",03
> 123
> 3,,"03-1234-9999999-00",150.00,,050,"DE","ABC","","","JOE","01/03/2004",03
> 123
>
> and expected results for the table:
>
> Date | Details | Tx Type | Sub Type | Type | Debit | Credit
> --------------------------------------------------------------------
> 01/03/2004 | BOB ABC | WTH | 000 | DE | | 60
> 01/03/2004 | JOE ABC | DEP | 050 | DE | 150 |
>
> The test should verify that the table data matches.
>
> They wish to rerun the test for various CMA Accounts/Statement
combinations.
>
>
> So I have an outline of an idea of what I want to do. But not quite sure
> how to do it.
You're pretty darn close. You could almost cut and paste
the tables you've created into either of these two:
Check into FIT (fit.c2.com) and FitNesse (www.fitnesse.org)
John Roth
>
> Thanks
> Shane
>
> --
> shanemingins@yahoo.com.clothes
>
> remove clothes before replying
>
>
> --
> "Have no fear" - The Cat In The Hat (Dr Seuss)
>
>
| |
| Robert C. Martin 2004-03-31, 2:32 am |
| On Wed, 31 Mar 2004 13:09:32 +1200, "Shane Mingins"
<shanemingins@yahoo.com.clothes> wrote:
>XPerts ...
>
>I have very little experience with testing software. Past employers have
>generally had no guidelines to testing. My current employer uses pretty
>much a waterfall approach to existing development where the software is
>finally tested by users when completed. Test plans are devised on
>spreadsheets and the users manually interact with the software. Partly this
>is due to that development environment, for example I am not aware of nUnit
>for RPG. Anyhow, background aside I am working alone in Java and trying to
>learn/adopt TDD and some of the other XP practices.
>
>Acceptance testing is the area that I am currently banging my head on.
>Below is the senario that I have been struggling with and so I would
>appreciate any helpful insight, comments, strategies, thoughts.
>
>I have the following story that I would like to write and implement a
>customer test:
>
>Import Bank Statement Transactions
> - Allow the user to import the transactions from a statement file to the
>selected CMA Account.
> - The transactions will be displayed in a table with the following
>headings:
> Date, Details, Tx Type, Sub Type, Type, Debit, Credit
>
>Q. Possibly break story into two? Import Bank Statement Transactions &
>Display Bank Statement Transactions
>
>If I did break stories then testing the Import would be checking the table
>model against a table of test data.
>
>And testing the Display would be loading a table model with test data and
>testing that display had data displayed as expected.
>
>Q. Does splitting the story sound a good idea? Does it sound like it may
>be easier to test? I am thinking perhaps so at this stage.
>
>From the customer's perspective this is what they would like to be able to
>do:
>
>
>Testing Import & Display Statement Transactions
>----------------------------------------------------------------------------
>Step| Command | Action | test data | Expected Result
>----------------------------------------------------------------------------
>1 | ? |Start Application |location of |Applications starts
> | | |application |showing menu tree
> | | | |with root nodes
> | | | |
>2 |select tree |Open CMA Accounts |name of root|CMA Accounts are
> |node |root |node | displayed
> | | | |
>3 |select tree |Select a CMA Account |name of cma |CMA account is
> |node | |account node|selected with an
> | | | |empty table of
> | | | |transactions
> | | | |displayed
> | | | |
> 4 |select |Right click selected |starting |Statement File
> |popupmenu |CMA Account and |directory ? |Selector displayed
> |item |select Import | |
> | |Statement menu item | |
> | | | |
> | | | |
>5 |accept file |Statement File |statement |Statement
> |selected |selected |file |transactions are
> | | | |displayed in table
> | | | |
> | | | |
>----------------------------------------------------------------------------
>
>Where I get stuck is how to provide a way for them to provide test results
>that will be verified against the actual results.
>
>IOW ... they wish to provide a statement file like:
>
>3,,"03-1234-9999999-00",-60.00,,000,"DE","ABC","","","BOB","01/03/2004",03
>123
>3,,"03-1234-9999999-00",150.00,,050,"DE","ABC","","","JOE","01/03/2004",03
>123
>
>and expected results for the table:
>
>Date | Details | Tx Type | Sub Type | Type | Debit | Credit
>--------------------------------------------------------------------
>01/03/2004 | BOB ABC | WTH | 000 | DE | | 60
>01/03/2004 | JOE ABC | DEP | 050 | DE | 150 |
>
>The test should verify that the table data matches.
>
>They wish to rerun the test for various CMA Accounts/Statement combinations.
>
>
>So I have an outline of an idea of what I want to do. But not quite sure
>how to do it.
>
>Thanks
>Shane
>
>--
>shanemingins@yahoo.com.clothes
>
>remove clothes before replying
Using FitNesse it would be pretty simple to create the following test:
(BTW this *is* the syntax you would use)
|CreateStatementFile|MyTestFile.txt|
|Date |Details |txType |subType |Type |Debit |Credit|
|01/03/2004 | BOB ABC | WTH | 000 | DE | | 60 |
|01/03/2004 | JOE ABC | DEP | 050 | DE | 150 | |
|fit.ActionFixture|
|start|ImportTransactionFileInteractor|
|click|nodeTree|
|check|cmaAccountsRootOpen|true|
|check|nodeContents|MyTestFile.txt|
|click|node|
|click|import|
|ExamineImportedTransactions|
|Date |Details |txType |subType |Type |Debit |Credit|
|01/03/2004 | BOB ABC | WTH | 000 | DE | | 60 |
|01/03/2004 | JOE ABC | DEP | 050 | DE | 150 | |
In FitNesse this would display as three HTML tables on a webpage.
There is a 'test' button on the page. When you click that button, the
cells in the tables turn red or greed depending on whether they match
the expected behavior or not.
See http://fitnesse.org/files/PayrollTe...OneResults.html
to get an idea of what this looks like.
Also just see http://fitnesse.org.
-----
Robert C. Martin (Uncle Bob)
Object Mentor Inc.
unclebob @ objectmentor . com
800-338-6716
"Distinguishing between the author
and the writing is the essence of civilized debate."
-- Daniel Parker
| |
| Shane Mingins 2004-03-31, 7:36 pm |
| <snipped some of my stuff and inserted questions below>
"Robert C. Martin" <unclebob@objectmentor.com> wrote in message
news:uklk60pbfk05lb1e1a8untp2cbapa8qtel@
4ax.com...
> On Wed, 31 Mar 2004 13:09:32 +1200, "Shane Mingins"
> <shanemingins@yahoo.com.clothes> wrote:
>
>
>---------------------------------------------------------------------------
-
Result[color=darkred]
>
>---------------------------------------------------------------------------
-
starts[color=darkred]
>
>---------------------------------------------------------------------------
-
results[color=darkred]
>
>3,,"03-1234-9999999-00",-60.00,,000,"DE","ABC","","","BOB","01/03/2004",03
>
>3,,"03-1234-9999999-00",150.00,,050,"DE","ABC","","","JOE","01/03/2004",03
combinations.[color=darkred]
>
> Using FitNesse it would be pretty simple to create the following test:
> (BTW this *is* the syntax you would use)
>
I am a little unclear as to what the following tests are doing ....
>
> |CreateStatementFile|MyTestFile.txt|
> |Date |Details |txType |subType |Type |Debit |Credit|
> |01/03/2004 | BOB ABC | WTH | 000 | DE | | 60 |
> |01/03/2004 | JOE ABC | DEP | 050 | DE | 150 | |
Is this reading MyTestFile.txt and verifying results against the data in the
table? Or is it reading the data in the table and creating MyTestFile.txt?
I am a bit about this step.
My customers have statement files in a CSV type format (as shown above) the
|click|import| action (below) should use a file of this type as provided by
the customer.
I was actually thinking that the test should allow them to provide *any*
statement file .... so they could sit there and think ... I'll use
TRN27FEB.D00 .... it passes ... now let's try TRN03MAR.D00 ... oh it fails
.... but that (now thinking about it some more) sounds like a bad idea. They
should provide a file or files with specific variations of things that they
need to work.
BTW, how does CreateStatementFile access the MyTestFile.txt parameter? Is
that a parameter? Or is actually just a heading to show the user the
statement file being read?
Or is this it? The CreateStatementFile is what is creating and setting up
the in-memory model?
>
> |fit.ActionFixture|
> |start|ImportTransactionFileInteractor|
> |click|nodeTree|
> |check|cmaAccountsRootOpen|true|
> |check|nodeContents|MyTestFile.txt|
> |click|node|
> |click|import|
>
Knowing that you avoid testing through the GUI I am assuming that this
ActionFixture will be testing an in-memory model, is that correct?
> |ExamineImportedTransactions|
> |Date |Details |txType |subType |Type |Debit |Credit|
> |01/03/2004 | BOB ABC | WTH | 000 | DE | | 60 |
> |01/03/2004 | JOE ABC | DEP | 050 | DE | 150 | |
>
And this is verifying the results of the in-memory model table vs the table
data entered here?
Thanks
Shane
| |
| Robert C. Martin 2004-03-31, 9:31 pm |
| On Thu, 1 Apr 2004 11:20:17 +1200, "Shane Mingins"
<shanemingins@yahoo.com.clothes> wrote:
>I am a little unclear as to what the following tests are doing ....
>
>
>Is this reading MyTestFile.txt and verifying results against the data in the
>table? Or is it reading the data in the table and creating MyTestFile.txt?
>I am a bit about this step.
The latter. It creates a file named MyTestFile.txt and loads it with
the specified data in the proper syntax.
>
>My customers have statement files in a CSV type format (as shown above) the
>|click|import| action (below) should use a file of this type as provided by
>the customer.
So the above fixture would create a file of that kind.
>I was actually thinking that the test should allow them to provide *any*
>statement file .... so they could sit there and think ... I'll use
>TRN27FEB.D00 .... it passes ... now let's try TRN03MAR.D00 ... oh it fails
>... but that (now thinking about it some more) sounds like a bad idea. They
>should provide a file or files with specific variations of things that they
>need to work.
You want to write automated tests, not manual tests that have an
automated component. Thus each new test you write will try a
different data suite.
No manual tests.
>BTW, how does CreateStatementFile access the MyTestFile.txt parameter? Is
>that a parameter? Or is actually just a heading to show the user the
>statement file being read?
The code to access that parameter is a little baroque at this point.
I'm going to improve it in the next release of FitNesse. Right now
you'd have to override doTable in your Fixture as follows:
class MyFixture extends RowEntryFixture {
private File statementFile;
public void doTable(Parse table) {
this.table = table;
statementFile = new File(table.more.parts.parts.text());
super.doTable(table);
statementFile.close();
}
or something like that.
>Or is this it? The CreateStatementFile is what is creating and setting up
>the in-memory model?
Since you are testing file importing, it's probably not appropriate to
use an in-memory model for this test.
>
>
>Knowing that you avoid testing through the GUI I am assuming that this
>ActionFixture will be testing an in-memory model, is that correct?
It is testing a logical subsystem that the GUI also uses. The GUI
sends the same commands to this subsystem that the test sends.
>
>
>And this is verifying the results of the in-memory model table vs the table
>data entered here?
Yes, it's verifying that the data imported from the file was imported
correctly. I'm presuming that even in the normal application this
would be held in memory. If not, then you *could* use an in-memory
model for this part of the test, since the test is more about
importing from files than representing statements in the database.
-----
Robert C. Martin (Uncle Bob)
Object Mentor Inc.
unclebob @ objectmentor . com
800-338-6716
"Distinguishing between the author
and the writing is the essence of civilized debate."
-- Daniel Parker
| |
| Jeff Grigg 2004-04-01, 8:39 am |
| > "Shane Mingins" <shanemingins@yahoo.com.clothes> wrote:
|Credit|[color=darkred]
|[color=darkred]
|[color=darkred]
Robert C. Martin <unclebob@objectmentor.com> wrote...[color=darkred]
> The latter. It creates a file named MyTestFile.txt and loads it
> with the specified data in the proper syntax.
Of course if you or your customers consider the ability to produce or
parse a comma-delimited file to be a difficult and/or risky operation,
one that is prone to failure, then you could use a more direct and
"physical" representation; maybe something like this:
|CreateTextFile|
|MyTestFile.txt|
|3,,"03-1234-9999999-00",-60.00,,000,"DE","ABC","","","BOB","01/03/2004",03123|
|3,,"03-1234-9999999-00",150.00,,050,"DE","ABC","","","JOE","01/03/2004",03123|
| |
| Shane Mingins 2004-04-02, 12:30 am |
| "Jeff Grigg" <jgrigg@mo.net> wrote in message
news:c794c0fd.0404010513.5dba1ce5@posting.google.com...
> Of course if you or your customers consider the ability to produce or
> parse a comma-delimited file to be a difficult and/or risky operation,
> one that is prone to failure, then you could use a more direct and
> "physical" representation; maybe something like this:
>
> |CreateTextFile|
> |MyTestFile.txt|
>
|3,,"03-1234-9999999-00",-60.00,,000,"DE","ABC","","","BOB","01/03/2004",031
23|
>
|3,,"03-1234-9999999-00",150.00,,050,"DE","ABC","","","JOE","01/03/2004",031
23|
Actually I have just done that. Because that data comes from exporting from
some online banking software it is already available in the format needed.
And they can find copies (printed) of statements with the cases they wish to
test, export a file for that date, copy the required lines. That seems
easy.
And then using RowEntryFixture I do not have to cater for either blank or
null values, I can read the data and create the file.
At the moment I think FitNess is looking very !
I just had a read of http://fit.c2.com/wiki.cgi?ParsingTables which is a
good starting read.
Thanks
Shane
| |
| Shane Mingins 2004-04-05, 9:30 pm |
| "Robert C. Martin" <unclebob@objectmentor.com> wrote in message
> It is testing a logical subsystem that the GUI also uses. The GUI
> sends the same commands to this subsystem that the test sends.
Something that just had not clicked for me it this separation of GUI/Logical
layer and I think maybe it is the Java use of "models" that maybe confusing
me ... or I could be just "plain" .
Knowing that you use Java a lot could you tell me where I am not getting it?
Using the example above in this thread as a reference, the GUI will have a
Swing JTree and JTable.
Now JTree and JTable have "models" ....
With JTree you can add TreeNodes and set a TreeSelectionModel.
With JTable you can extend AbstractTableModel and set the JTable to use this
model.
[BTW ... if anyone reading has found a very good Java and/or Java Swing
book, speak now cos I think I need to add one or two to my library and I
have been holding off .... ]
Now where does the separation of the logical layer exist? These Swing
specific models belong in the GUI, yes? But these Swing models "do alot"
and need testing. Do you aim both the customer tests and appropriate
programmer tests at these Swing models?
One way I think of it is to remove Swing .... so if I think of a text GUI
implementation then I need a non-Swing model representing my tree and table
..... but then when I come to implement a Swing GUI does that mean that the
TableModel for the JTable will just be a lite model over top of my "more
generic" model.
Am I making sense explaining myself?
Thanks
Shane
" We should turn our attention back to pleasing our customer. That's what
keeps the paychecks rolling in." -- Ron Jeffries
| |
| Robert C. Martin 2004-04-07, 4:32 am |
| On Tue, 6 Apr 2004 12:43:02 +1200, "Shane Mingins"
<shanemingins@yahoo.com.clothes> wrote:
>"Robert C. Martin" <unclebob@objectmentor.com> wrote in message
>
>
>Something that just had not clicked for me it this separation of GUI/Logical
>layer and I think maybe it is the Java use of "models" that maybe confusing
>me ... or I could be just "plain" .
>
>Knowing that you use Java a lot could you tell me where I am not getting it?
>
>Using the example above in this thread as a reference, the GUI will have a
>Swing JTree and JTable.
>
>Now JTree and JTable have "models" ....
>
>With JTree you can add TreeNodes and set a TreeSelectionModel.
>With JTable you can extend AbstractTableModel and set the JTable to use this
>model.
>
>[BTW ... if anyone reading has found a very good Java and/or Java Swing
>book, speak now cos I think I need to add one or two to my library and I
>have been holding off .... ]
>
>Now where does the separation of the logical layer exist? These Swing
>specific models belong in the GUI, yes?
No, they could be in the subsystem that uses the GUI. The fact that
they are in the swing package is a nuisance, but not much of a
problem. Some of the models might acquire too much coupling to the
GUI. In that case you'd want to split the model in two, and keep the
abstract portion in the subsystem, and move the GUI stuff into the
GUI.
>But these Swing models "do alot"
>and need testing. Do you aim both the customer tests and appropriate
>programmer tests at these Swing models?
Yes, it's pretty simple to write a unit test against an
AbstractTableModel, or ListModel.
>
>One way I think of it is to remove Swing .... so if I think of a text GUI
>implementation then I need a non-Swing model representing my tree and table
>.... but then when I come to implement a Swing GUI does that mean that the
>TableModel for the JTable will just be a lite model over top of my "more
>generic" model.
Oh, I think you could continue to use the Model classes in your Text
UI. It wouldn't' be to hard to create a TextList class that draw a
list on an ASCII screen using a ListModel.
I wish the Java folks had separated the models into a different
package. But since they didn't, we can live with the fact that most
of the model classes are decoupled from their corresponding GUI
components. (i.e. ListModel doesn't know about JList IIRC.).
-----
Robert C. Martin (Uncle Bob)
Object Mentor Inc.
unclebob @ objectmentor . com
800-338-6716
"Distinguishing between the author
and the writing is the essence of civilized debate."
-- Daniel Parker
| |
| Shane Mingins 2004-04-10, 7:31 pm |
| "Robert C. Martin" <unclebob@objectmentor.com> wrote in message
news:eqg4709le8i9nebvgctna1hcf9n6dgkqf3@
4ax.com...
<snipped reply>
> I wish the Java folks had separated the models into a different
> package. But since they didn't, we can live with the fact that most
> of the model classes are decoupled from their corresponding GUI
> components. (i.e. ListModel doesn't know about JList IIRC.).
>
Thanks for that!
Shane
|
|
|
|
|