Hello World!

Alex Henderson here, Lead Developer for the Enterprise Tester platform. This is my first post on our recently launched Catch blogs.

Going forward my posts will be of a technical nature (no marketing / sales here) – so I would love to encourage open discussion on my posts. We love our customers and value any feedback good or bad you may have, so please leave comments / requests for future posts etc.

Version 4.0

As I write this, Enterprise Tester 4.0 is being packaged up and getting ready to the hit the “virtual shelves” for our eager customers.

There’s a lot of new features in 4.0 and the rest of the team is going to be covering them in detail, so I thought instead I would pick my 5 favourite features of 4.0 (in no particular order) and talk a little about them from a technical perspective. These are not necessarily the “best” or most amazing features (so, for example, I’m not going to mention the new graphs even though they are awesome), but just some new features I really like

Feature #1 – Incident Screen Improvements

For a long time now the incident management screen and it’s associated grids have been the “odd ones out” – it looked different, it didn’t resize nicely, and it required a full page load to display.

In Enterprise Tester v4.0 incidents are no longer second-class citizens from a user interface perspective, and use the same editor and grid framework as the rest of Enterprise Tester. Tthey have also received a number of little enhancements including:

• Project name being displayed in the title bar of the edit screen.
• Support for saving (rather then just Save & Close).
• Better use of horizontal screen space, requiring less scrolling.
• Support for bulk export, bulk assigning and printing directly from the grid.
• Sorting by the Issue ID (i.e. JIRA Issue Key) now sorts like you would expect i.e. TST-100 will come after TST-99.

Feature #2 – TQL Aggregation Support

Expect to be hearing these three letters a lot in the next few months from the team here at Catch:

T . Q . L

TQL, or Testing Query Language, is a query language written expressly for querying information within Enterprise Tester, which allows you to write queries to filter your data your way – many of the grid usability improvements included in Enterprise Tester 4.0 are powered by this new query language.

TQL borrows unashamedly from other query languages such as SQL and JQL (JIRA Query Language), but with a little additional “ET” flavour thrown in for good measure. One of the more interesting features of TQL (and fun to work on as a developer) are what we call aggregation queries.

So for instance if we have a query to return all the scripts that have been run in our project:

EntityType = ScriptAssignment AND Project = 'Project X' AND Status != NotRun

We can then start slicing and dicing the results of the query to get all sorts of useful and unusual summary information, from the very mundane such as a Total Count …

Count WHERE EntityType = ScriptAssignment AND Project = 'Project X' AND Status = Failed

YAWN!

To the quite complex:

COUNT,
Min(LastUpdatedAt) AS "Start At",
Max(LastUpdatedAt) AS "Finished At",
GROUP BY Status {
  GROUP By Type {
    Count
  }
} AS "Statuses",
GROUP BY Path {
  SUM(EstimatedDuration) AS "Total Estimated",
  SUM(ActualDuration) AS "Total Actual",
  AVG(EstimatedLessActualDuration) AS "Average Remaining Time (Per Script)"
} AS "Packages",
FACETED OrArgs(Equal(Status,Failed), Equal(Status,Blocked)) AS "Failed OR Blocked" {
  Entities
} AS "Flagged"
WHERE EntityType = ScriptAssignment
  AND Project = 'Project X'
  AND Status != NotRun

[And yes, you can click on the two failed scripts displayed at the bottom of the screenshot above to view their associated execution screen, run the script again, pass it, save, and close. And the search screen will automatically refresh to reflect the new statistics].

We have also made sure that all these new TQL features are going to be extension points you can develop for next year when our first SDK is released – so you can add support for new types of calculated fields, functions or even entirely new indexes.

To see just how modular our query implementation is, you can take a look at the “Modules” screen in Version 4.0 (in the Admin tab, under the “Extensions” node) – TQL’s implementation is made up of literally hundreds of components.

Feature #3 – Custom Fields are good… again!

Custom fields – our long term customers will no doubt remember just how happy we were to ship them, and they to get them…

I hope we all remember the bling snail?

Well, a month or so after releasing that feature the inevitable questions came from anyone using custom fields in anger:

• What about displaying custom fields in the grid?
• What about being able to sort by custom fields?
• What about being able to search by custom field values?
• What about being able to report off custom field values?

And, like an albatross around our collective necks (or perhaps a snail stuck to our backs, that we can’t quite reach?) we have internally as a team, discussed, delayed, discussed again, delayed again… well you get the point – but the features never quite managed to fit into any of our releases.

Well despair no more – custom fields now support all the above functionality! They can be displayed in grids, searched, sorted, exported to CSV (for all entity types) – in all respects custom fields and in-built fields work the same now, from a users perspective.

If you are an administrator in Enterprise Tester you can even seen them displayed in the list of supported fields by going to the Admin tab -> Search -> Indexing, and then clicking on the “Fields” tab.

One interesting side effect of this is that custom fields and in-built fields exist within the same “name space” – this means you can’t have a custom field with the same name as an in-built field.  When upgrading to version 4.0 if you have any custom fields which are named using one of these reserved words, then the name will automatically be prefixed with the word “custom” to ensure it is unique.

This does not affect the label – so the change will be largely transparent, but it does have impacts when you go to use those fields in TQL.  After upgrading to version 4.0 we suggest reviewing all your custom field names, and maybe giving some thought to how those names might look in your TQL queries.

Feature #4 – The “Accumulated Actual Duration” Field

Version 4.0 is just the beginning of TQL support in Enterprise Tester and over time we will be introducing new calculated fields, additional indexes and other great features to make all the information collected within Enterprise Tester available at your finger tips.

To give you just a taste of what’s possible – here’s some information you have never had access to before which can now be queried within Enterprise Tester 4.0 – Accumulated Actual Duration (we also call it Accumulated Actual Time Spent in some places, but it’s the same thing).

What’s that, you ask?

Well, every time you execute a script in Enterprise Tester, you can record the amount of time it took you to run.

You can then see this time information presented on screen i.e. a comparison of the estimated duration for the script vs. the actual duration, and the amount of time remaining – did you take more or less time to execute the script than you had estimated?

But, if you ran the same script five times, and the first four times it fails (perhaps as the developer attempts to resolve the issue but doesn’t quite get it right)  then on the 5th re-run the developer has fixed the issue and it passes.

In this case the actual times recorded for the four previous runs were in effect “ignored”.

Thus, depending on your testing practices our estimated vs. actual numbers could provide a very skewed view of just how long testing is taking.  This is where the new calculated “Accumulated Actual Duration” field comes in, allowing you to see just how much time is being spent overall in running a script – for example, here is some TQL to give (per user) the total amount of time they have spent testing scripts in each package.

GROUP BY Path {
  GROUP BY RunBy {
    SUM(AccumulatedActualDuration) AS "Time Spent"
  } AS "User"
} AS "Package"
WHERE EntityType = ScriptAssignment
  AND Project = 'Project X'
  AND RunBy IS NOT EMPTY

Feature #5 – Automagic TQL Fragments – Dragging, Dropping & Inserting

For better or worse Enterprise Tester very early on settled on using globally unique identifiers “GUIDS” as the ID’s for records – those long strings of numbers and letters i.e. “cd147e63-824f-4bc3-92e5-9f8e00fea5d9”.  This (like most technical decisions) has been both a blessing and a curse – the ID’s are unique across all entities which is blessing, their length and lack of human readability being the curse – and we certainly have plans to rectify some of the usability issues they cause.

One such pain point actually came about in testing some of the features of the TQL language, such as the ability to query by an ID.  It can very tedious opening a record, copying the ID from the url toolbar, closing it, pasting the value into the search, etc.  There had to be a better way!

Thus, drag and drop support for TQL was born.  Here’s how it works:

• Find something in the tree you want to filter on.
• Drag it over the TQL window, drop it, a menu appears (if the entity is supported).
• Select the TQL fragment that comes closest to what you need.
• Edit as you see fit (It is smart enough to automatically prefix additional fragments with the word “AND” in most cases).

Here’s an example of dragging a project onto the the TQL editor:

And the resulting fragment that was added to our query:

It’s not just limited to drag and drop either,  for example you can right click on a saved query and select a fragment to insert into your current query:

In this case your current query will then reference the saved query, allowing you to further build on the criteria in the saved query. This feature is really handy when you want to setup an overall query for your current sprint, which points to the correct project and packages – which you might save as “Project X – Current Sprint”.

You can then write queries like:

Query = 'Project X - Current Sprint' AND AssignedTo = Me()

Which would return all scripts assigned to you in the current sprint.

At this point all that is required when transitioning from one sprint to the next is to update the ‘Project X – Current Sprint’ saved query and all down-stream queries which reference the saved query will be updated too.

This is also handy when configuring the “Gauge” chart, which expects two series, one representing “100%” and the other representing the progress towards a 100% complete (which can just be an additional set of filtering applied to the 100% saved query).

Wrapping it Up

I hope this has proven interesting to old and new Enterprise Tester users alike, and maybe highlighted some features of Enterprise Tester 4.0 you might not otherwise know about.

Next week I will be starting a series of posts examining the finer details of writing TQL queries, so tune back then for more TQL fun.  And even though you can’t upgrade to Enterprise Tester 4.0 yet – it’s out on the 7th of November – why not try out some TQL queries on one of our demo servers?

Happy Testing!