XStudio 1.0: A new search tab for tests and testcases

XStudio 1.0 will include a new search feature for tests and testcases. This completes the set of search features already available on tasks, specifications, requirements and defects.

So to clarify a little bit the different search functions available on XStudio:

1) Search by name (textfield/combobox available on the top of each tree): if you know the name of the item you're looking for but you don't don't where it is located or you don't want to manually expand all parents node, that's the right way to go. Just type the beginning of the name of the item, the rest will be auto-completed, you can scroll within the list of suggestions and select the right item. Very fast and effective - if you know what you're looking for.

2) Search by Id (global texfield on the main frame): when you have the unique identifier of the item you're looking for (included in the HTML tesplan, reports etc.) that's the right way to go: just type the ID in the textfield and you'll be redirected directly to the right tab, tree and node.

3) Plain text search: select the parent node from which to search and go to the search tab.

Here are the parent node to select depending on what kind of item you're looking for:

• Requirement: Category node
• Specifications: Category node
• Tasks: Root node
• Tests: Root node
• Integrated defects: Category node

Different options will be available to precise the search. The options anyway always include a textfield to enter a text to look for. Generally, this text is searched in properties like name, description, prerequisites, steps to reproduce, testplan (any textual field - formatted or not) and display results along with anchors so that you can just click on one item to open it.

XStudio 1.0: Generic executable launcher

I've just implemented a small launcher that will allow to run executable files (tests).

It takes 3 parameters as a configuration:

• the test root path. This must indicate where are located all the executable files.
  This is a root path. Each test in XStudio has a "canonical path" that will be appended to
  this path. This path MUST not include a ending slash.
  
• if the executable must be launched synchronously (if the tests returns when they are terminated) or asynchronously (when the test returns immediately but keep on running in background). If the synchronous option is checked, then the launcher will run the executable synchronously (waiting infinitely for the executable to return). If the Synchronous option is not checked, then the launcher will run the executable in background and will regularly check the presence of a file "test_completed.txt". A configurable timeout is granted to the executable to complete. If the executable did not create the "test_completed.txt" file within this timeout, then the launcher considers the test has crashed and skip it.
  
• the timeout value in case the tests are asynchronous. This is the maximum time the system will wait for the test to complete.
  

As usual, the launchers (exe.jar) comes with its configuration file (exe.xml) file. It allows to pre-configure the launcher with some default values. Of course, the user can always overwrite them at run time of the campaign session in XStudio through the GUI..

Requirements:

• Each test in XStudio must have his dedicated .exe file. The name of the executable MUST be equal to the name of the test.
• The .exe file MAY be able to parse some arguments passed during interpretation. In particular testcaseIndex (optional). This allows to execute different routines depending on the testcase index.
  

The test is executed by the launcher using this syntax:
<testRootPath>/<testPath>/<testName>.exe /debug /testcaseIndex=<testcaseIndex>

As usual, the source code, the SDK and the script to build this launcher will be provided. This feature will be made public end of June in the version 1.0 pre-alpha here: http://www.xqual.com/support/download.html

Tools section update

I've added a couple of new software references (commercial) in the Tools section of the website: http://www.xqual.com/qa/tools.html

XStudio 1.0: How to filter closed items

After a few month of usage, people generally get tens (even hundreds) of sprints, tasks (in the project tree) or defects (in the defect tree). Most of the sprints have been completed and are there only for history/archive purposes. The fact to have them in the tree can impact readability of the tree. The same thing applies for closed defects.

For this reason, some predefined filters has been added to the project and defect trees and are available though toggle buttons on the right hand side of the search bar:

Filtering is immediate and very easy to enable/disable through the toggle buttons.
This feature will be made public end of June in the version 1.0 pre-alpha here: http://www.xqual.com/support/download.html

XStudio 1.0: More details about performances improvements

I've now a complete implementation of the new tree retrieval method that will be available in XStudio 1.0.

As expected, the performances are now much better especially for BIG databases (environments with thousands of requirements, specifications, projects, tests, defects etc.).

I hope I will be able to deliver a first alpha 0 of XStudio 1.0 end of June.

This feature will be made public end of June in the version 1.0 pre-alpha here: http://www.xqual.com/support/download.html

Release of XStudio 0.7

The final version 0.7 of XStudio & Xagent is available for download at the usual location: http://www.xqual.com/support/download.html

Only one minor bug has been reported on 0.7b3 and has been fixed (about filtering tests while creating a campaign). The user's guide has also been slightly updated (including results about memory consumption).

I already started working on the version 1.0 and it looks quite promising! Hence, my first tests on optimizing the TREE RETRIEVAL METHOD is showing HUGE progress in terms of performances :) 

At the end it will be visible on:
- time to start the application
- time to refresh the tree after a change has been submitted
- usability over VPN or any slow networks

Even using local Database, time to retrieve/refresh ALL the trees has been reduced by 80% (3.8s to 750ms in my case).

But note that...
- the biggest the trees are (the more branches and leaves they contain, the biggest will be the improvements (in percentage)
- the slower the connection to the database is (i.e. if the database is hosted remotely through a VPN), the biggest will be the improvement (in percentage).

I will do more tests but I presume, improvements could reach more than 95% in some very usual environments.