First alpha release of LReport is out

[2006-04-26]
Release 0.14 of LReport is availiable. This is the first release, which I consider usable. Have a look at lreport.sourceforge.net.

Revision 1.0 of Win32::GuiTest documentation is available

[2005-05-06]
There is still much space for improvements but at least all exported functions are documented.

Revision 0.2 of Win32::GuiTest documentation is available

[2005-04-27]
Revision 0.2 of Win32::GuiTest documentation is available. It is still far from being complete but more and more functions get documented

New design of my website is in place

[2005-04-13]
The site design has changed. I believe that navigation is now simpler. It may happen that some links don't work. If you find such a link please let me know

Tools > LReport > What is LReport

What is LReport

The purpose

There are different methodologies describing how to create test cases, how to manage them. But regardless of the methodology, execution of most of test cases looks like this: Check the interesting database tables, run test scenario, check interesting tables again and document your observations.
The purpose of LReport is to help you with the checking and documenting phase.

The problem

In all projects I was in, documenting database contents was always a problem. When you think about it, there are 2 extrema. One extremum is that you put in your report only data, which you consider important. That means that you report only important tables and only important columns of these tables.
On the other side, you can report all tables, which may be affected by executed actions and if you report any table, you report all columns.
Whatever the approach, reports are created by copying and pasting selects' results from tools like OraTool, Rapid SQL, SqlPlus, isql etc. This way of doing things works fine for many projects, but I believe there is some space for significant improvement here.
The common approach I was describing above has the following problems:

  • Copying and pasting is a tedious and boring task (hence, error prone), especially if you require to report contents of many tables.
  • It is very easy to miss differences between before and after test state of the data.
  • There is a contradiction between readability and completness of the report
I think that the first and the second point needs no further explanation. However, the third does.
If you place only selected columns from selected tables, nicely formated - then your report is readable. But there are 2 problems with going this way.
  1. It is time consuming. Instead of "select *" you have to type "select column1, column2, ...etc". No big deal if you do it once for one table. It becames a problem if you have to explicitly specify columns for several tables. Also nice formating is time consuming. It is not going to take much time to convert copied and pasted stuff into tables and apply some shading and coloring once. But if you are executing several test cases, this time becomes significant.
  2. There is a risk that you miss some data, which were actually important. Later on when you analyze the test case, you will realize that some tables or columns contained really important data. But it will be to late. The data will be gone


Pasting all columns from many tables has the advantage of completness. But this kind of reports are hardly readable, especially when you report many tables and some of them contains 80 or more columns.

So the design goals for LReport was to:
1. Automaticaly create nicely formated reports from selected tables.
2. Automate finding differences between results of the group of selects
3. Find a solution to readability vs completeness contradiction
4. Ease of use

The solution

In short, this is how I have done it:

  1. There is a tool chain allowing to generate csv files from selects' results and to compare those csv files.
  2. Both csv files and difference report can be converted to XML files
  3. You can then format the report using XSL. Currently conversion to RTF is supported.
  4. Ease of use... Well, it's relative. It uses XML. If you are not familiar with XML it will take you some time to get used to it. But keep in touch. I am thinking of creation of a simple GUI for defining table reports layouts.


Fine, it does make sense, but were is the software?

I have created an open source project on Source Forge.
*