Archive for the ‘Quality’ Category

SDMX Web Services

Wednesday, June 9th, 2010 by Don McIntosh

Recently, many of us at STR have been working on implementing open data formats, specifically SDMX 2.1 and DDI 3.1. Both are extremely relevant for statistical processing - DDI assumes the key position for planning, data collection, processing and microdata dissemination.  SDMX is most suited for processing and dissemination of aggregated data. Previous blog posts and news items have provided an overview of SDMX to inform our customers about how how SDMX might help them with their own business processes.  This blog post is all about what we are actually delivering with our  mid year SuperSTAR Release 7.0.  The following SDMX functionality will be included:

  1. SDMX output from SuperWEB
  2. Building SDMX-driven SuperVIEW interactive presentations (with no SXV4 db required)
  3. RESTful SDMX Web Services

This blog focuses on the Web Services which is arguably the most important capability.  And perhaps the other reason I’m excited by it is because it is the first time that SDMX has been introduced directly to microdata.  I’ll explain what I mean by this a bit later.

From the point of view of many data providers, the advantage of the Web Services is that it can provide their customers with just the data they need, no more and no less. This can free up staff devoted to responding to ad hoc queries.

From the customer point of view, it opens up new possibilities for consuming the data and building unique, useful services on top of it. For example, a third party application can convert user responses from a Web app into dynamic SDMX queries and then the results from this can in turn be used to determine how the Web app should behave. Without Web Services, such an app would previously have relied on potentially stale data that was downloaded and loaded into a local database. And thanks to the detailed data model of SDMX, apps can also work out what other data sources might sensibly be combined together to produce richer, more useful results.

The other thing I’ll mention before getting into some specifics about what we’ve done is that our implementation is actually that of a RESTful API, not a “traditional” Web Service. We’re glad to see this becoming so much more popular now.  SDMX orginally only had standard SOAP based Web Services defined, but we’ve based our implementation on the proposed RESTful API for SDMX version 2.1.  As developers, a RESTful API is something we find a lot easier to start using, to explore, and to scale and we we think that our customers will find the same.

What we’ve done

The SDMX API that we are focused on can be broken into three logical chunks:

  1. Metadata Discovery - what data collections are available, and what concepts/classifications are used where
  2. Database Metadata Discovery - What metadata (eg: concepts and code lists) are used within a particular SDMX dataset?
  3. Queries - Defining and pulling back a slice of an SDMX data cube

We’ve implemented parts 2 & 3.  (Part 1 we will consider for a future version, but we are also looking at solving this gap in a different way, such as leveraging existing SDMX registries, which are used to collate and manage contents that are stored in SDMX repositories. The important thing to note here is that we don’t want SuperSTAR to be an island - many of the organisations we work with would want to reuse the same search and discovery mechanism across many different types of data and applications, so we’d like to learn more about how SDMX solutions can be part of such an environment before we proceed with this.)

Our SDMX Restful API supports access to aggregated data that is managed by SuperSTAR. This can be from several different sources:

  1. SuperSTAR data cubes
  2. SuperSTAR tables defined by SuperWEB users
  3. SuperSTAR microdata databases

The last case is worth elaborating on, and links back to the point I mentioned earlier about introducing SDMX to microdata. Up until now, SDMX use has been limited to working with pre-aggregated data. This makes sense, especially when you consider the origins of SDMX, which is a group of organizations that deal almost solely with such aggregated statistical data and only rarely with the underlying microdata from which the statistics were derived.

From our point of view, however, and I believe from the point of view of many of our customers, dealing with microdata is very much part of the production process that they are involved in. What is useful about this is that the users are not constrained to taking slices of pre-defined cubes of data, but rather exploring and dynamically defining queries to run against the microdata. This approach can generate orders of magnitude more possible outputs and therefore relieve the provider from the burden of manually addressing many ad hoc queries that can’t be satisfied by a query against an existing cube. It does occasionally introduce other problems, namely confidentiality and performance, but these are part of our core capabilities, so our solution addresses potential drawbacks in this regard.

To make it possible to use an SDMX-based API to run tabulation queries against microdata, we’ve made some necessary innovations to the SDMX standard. Firstly, while you can query for the data structure definition (DSD) of a very large virtual cube (which is actually a SuperSTAR database), we prevent clients from requesting the full dataset for this cube - it’s simply going to be too big. What we do instead is allow for any subset of dimensions in the DSD to be combined in an SDMX query.

In addition, any tables that a user defines in SuperWEB can be accessed as SDMX datasets; both the DSD and the data from such a table can be obtained through queries against the SDMX RESTful API.

If you’ve read this whole post, you must be interested in what we are doing here. We think that the API can be very useful for many of our customers, so please leave a comment here if you have a question or something say. Or if you want to go one step further, let us know and we’ll discuss providing you with a test package that you can use to try the API against your own data.

Embracing Advanced Visualization - apps4NSW Comp entries

Friday, March 26th, 2010 by Jo Deeker

Space-Time Research have developed two entries for the apps4NSW competition (for New South Wales, Australia) using SuperVIEW.  The apps4NSW competition, like the Mashup Australia and Apps For Democracy competitions, invited the public to submit ideas and applications that would benefit the citizens of New South Wales.

I’m excited about our two applications because they are genuinely useful online interactive publications of complex data that everyone will benefit from.  Our Why Australians Travel application presents a dataset from Tourism Research Australia that has not been made available to the public in an interactive way before.  It also includes advanced visualization in the form of a Motion Chart (Gapminder-style) which we’re very excited by! The motion chart can tell a story with data over time that you simply don’t see in static tables or reports.

The How Safe Is Your Suburb 2.0 application provides NSW Crime data in an interactive way, allowing users to analyse relative crime rates ot absolute crime rates by suburb.  This application is supported by one of our newest features - metadata -where explanations about the data are provided to the user to help them understand the meaning of the data.

Go check our applications out and vote for us if you like them!  And if you have any feedback on our entries please don’t hesitate to make a comment on our blog here.

Gov 2.0 for Koalas - Community vs. Government Data

Thursday, December 3rd, 2009 by Don McIntosh

koala3

I heard a debate on the radio on Tuesday about whether koalas should be classified as an endangered species. There’s an article from ABC news from last month that covers the issue quite well. Oddly enough, I was reminded of it when I had a chat with Gartner analyst Andrea Di Maio that same evening when he pointed out what he called the asymmetry of Gov 2.0. What he was referring to was the fact that many communities have data of their own, and that the standards that we are demanding of government are in no way being reciprocated in terms of what is expected of communities. A question for us and for our customers (typically government agencies) is what should government do with data owned and collected by the community?

How many koalas are there? Are they a threatened species, or endangered? What do we need to do to make sure that Australia retains a diverse, healthy population of koalas? This is a hotly debated topic, with the government accused of siding with property developers at the expense of many hectares of koala habitat. As much as I’m worried about predictions of extinction of koalas within 30 yrs, I’m not trying to push either side of the argument in this post. I’ll leave that to those who are better informed about this. What I do want to do is explore what should be done with “unofficial” statistics.

So here’s the problem: we have official statistics produced by government derived from data that is objectively collected, categorized and disseminated in keeping with scientific survey practices. And then on the flip side, we have passionate communities conducting their own research which increasingly seems to involve collecting data and producing statistics. In terms of quality, I imagine that the output varies a lot. But it is data, and potentially useful data. How should government deal with that, especially where they plan or need to have data that clearly overlaps with what already exists? Could government help turn them into official statistics? I would suspect that in many cases the answer would be a rather emphatic no. However, perhaps there would be cases where there may be some benefit to government to be gained from acknowledging and making some use of community-sourced data.

At the front end of the statistical business process model published by the UNECE, there is a planning phase where existing data sources are considered for inclusion in official collections. Here’s what the UNECE says in step 1.5:

Check Data Availability: This sub-process checks whether current data sources could meet user requirements, and the conditions under which they would be available, including any restrictions on their use. An assessment of possible alternatives would normally include research into potential administrative data sources and their methodologies, to determine whether they would be suitable for use for statistical purposes. When existing sources have been assessed, a strategy for filling any remaining gaps in the data requirement is prepared…”

I’d take away from that that the authors had absolutely no thought in their minds about community data. So, if I was a community activist, I’d say that means that there is room for it to happen. After all, it doesn’t explicitly preclude a statistician from asking around to see if anyone else is out there counting our cuddly little Aussie icons. Perhaps there would be valid cases where government could collaborate in some way so that either the quality of the output is improved, or at the very least it can be better understood and therefore used appropriately.

There are a couple of issues that spring to mind…

  • Biased and/or poor quality evidence. Communities are typically passionate and biased to a particular point of view. With no standards or checks in place to determine data quality, the government would be right to be highly skeptical of any “facts” presented. The CEO of the Australian Koala Foundation (AKF) noted that over 20 years, 2000 field sites have been looked at and over 80,000 trees. Is that enough? For what? Should the government do more? Well, at the very least, they should do some due diligence, or even better, demand a bit of transparency of the AKF, which I suspect they would be quite willing to provide. It’s right that we demand transparency of the government, but it is equally right that community groups offering evidence to support their claims should be held to a similar standard. Maybe government departments need to band together to demand Community 2.0 ?
  • Inappropriate use of anecdotal evidence. Let’s face it, right now there are no doubt many policies that are based on little more than personal opinions of government executives rather than any solid evidence. People regularly draw conclusions based on direct experiences, or from stories of those they trust. Here’s a simple case in point from a comment on the ABC’s article: “Last year in the Otways I saw koalas where I had never seen them before. Seems to me that their numbers are increasing and a good thing too.” Let’s hope that’s not from environment minister Peter Garrett. This is a great evolutionary attribute that allows us to form opinions on things that might actually affect us but it doesn’t serve us well when we choose to use it to form a model of complex, widespread populations with many different local influences at play. I hardly need to point out what a huge role data can play when it comes to making informed decisions.
  • Real experts in the public ready to make a contribution. There are many informed and passionate members both within the official communities, as well as in the public at large. What if we could give them a little bit more in the way of facts and figures to work with? As it is, there is a fair bit of scientific knowledge introduced by commenters. One knowledgeable commenter had a fascinating insight into the problem: “Koala populations are notoriously difficult to monitor. They are such a specialized animal that a minor change in habitat can lead to local extinctions in one area while they pop up somewhere else where they haven’t been seen in living memory.” Well, it sounds like he knows about it. It would be helpful if there was a way for him to easily reference credible evidence to back that up.

As one commenter noted: “At least it’s a positive step to have some dialogue over koala population density, and clearly there are big differences in estimates.” Yep, that pretty much sums it up. The question is, how do we get to the next step? Personally, I don’t know. I think that Andrea got it right when he said that government should acknowledge the existence of the community data sources. What they do next is an open question. Having surveys with tens of thousands of data points may still be unreliable depending on the use, but it may be better than making conclusions based on what Fred saw on his weekend trip to the Otways. I’d love to hear what other community vs government data debates people have had, and what the outcome was.

Bug Safaris - a different way to find bugs

Thursday, September 17th, 2009 by Jo Deeker

Here is a post from Adrian Mirabelli - a Customer Quality engineer at Space-Time Research. The idea for a bug safari came out of a presentation at the ANZ Test Board Conference in March 2009.

Bug safaris at Space-Time Research

For release 6.5, the STR quality team introduced “bug safaris” as a way to effectively and quickly find software bugs.

A bug safari involves the majority of the organisation including development, design, and management to locate bugs. Test cases or scripts are not necessarily provided but guidance should be given. Certain areas are targeted and the amount of interruptions is minimised to increase the effectiveness. Note the bug safari can be held multiple times over a release.

Planning is the key!

At the beginning of a bug safari, the quality manager invites the participants to a planning session or “kickoff”. The purpose of the kickoff is to define:

  • The objectives of the session – including to communicate what is being done; all participants should be very clear about this by the conclusion of the session
  • Areas to test and who will do it – this is important to ensure coverage and no wasteful duplication
  • Configuration required and who will do it
  • Test cases or documentation required and who will do it – the structure of these products should be agreed, for example, is it a checklist or a matrix that is filled out on-the-fly?
  • Some ideas of how to test – do something unusual or non-typical, test boundary values, do something unusual
  • Duration of session
  • Method for reporting issues and bugs

Typically the system configuration and documentation will be done by the testing team with the help of technical resources if required. Login information is distributed in advance. The quality manager needs to decide how to report results including submission of bug reports, and therefore plays a crucial role in this testing.

At the agreed date or time, the testing itself is performed, typically no longer than two hours but longer than 45 minutes. This session is generally intense in nature as the mission is to find problems. The system testers are usually assigned to a product and work with the participants to help identify issues and troubleshoot problems. They can also be actively testing the system depending on what is agreed at the kickoff session.

At the conclusion of the session, results are tabulated and any bugs found are raised in the incident tracking system.

Within the next couple of days at the absolute latest, a debriefing is held with the participants including the system testers. The quality manager reports on bugs found, and discussion is held regarding:

  • The perceived level of success of the bug safari
  • What can be improved for next time
  • What worked well this time
  • General feelings and sentiments
  • Required actions and action owners.

Why not just use structured tests?

Procedural test cases, which follow a step-by-step test script, are excellent for communicating to the wider audience how you are testing and to obtain buy-in and feedback from stakeholders. In my experience, however, you can find bugs by looking around the software, not just looking at the expected results of the test case. Further, bugs are found when testing certain sequences of data, mouse clicks, configuration, operating systems and more, and it is expensive to write test cases for all these combinations.

Why involve people outside the testing team?

You and I are testing software every day. Just by using software you are testing whether it satisfies your need and your purpose. Everyone interacts with software differently, and is likely to try things out in various and different ways, some typical and some strange, so it is good to have such testing sessions to really verify the software is “fit-for-purpose”. It also gives the opportunity for fresh eyes to look and question the software, and test out other important elements such as usability and compatibility. It also increases the participants’ knowledge of the software, whilst testing the accuracy of the configuration and documentation, including the quality of test harnesses and pre-defined scripts.

What are the benefits?

Bug safaris are defined as “exploratory testing” with more tangible results. The results can easily be reported on charts or whiteboards and transferred to the test management and tracking system.

We allow the participants to exercise freedom of thought in executing tests. In this way we can find new bugs as possible new combinations of tests are being exercised. Quality therefore improves as we can address and fix such bugs based on their priority. The participant is encouraged to investigate and should investigate any strange behaviour they find, perform further tests, and ask questions.

By everyone being involved in testing, and not just the test team, it improves the visibility of the test organisation and the importance of testing, whilst sharing the ownership of “quality” to all people involved in the development of the software from concept to implementation.

By performing such tests, we can report and therefore utilise many metrics to find out, for example:

  1. Number of bugs or issues found per session
  2. Number of sessions run
  3. Areas covered in the session with combinations
  4. Time required to configure
  5. Time required to test
  6. Time required to investigate issues

The key is that people work together and discuss openly the software and what it does.

What are the challenges?

This method of testing is still relatively new, and is therefore not a perfect method, nor a substitute for traditional testing methods. The key is to balance out the proportion of how much testing is structured versus unstructured, whilst ensuring that the testing results are captured sufficiently. Such examples of test tracking may require the participant to complete a spreadsheet, matrix or running sheet.

What is being done in future?

Space-Time Research will run bug safaris in future releases. Bug safaris have been shown to find bugs, and important bugs, and are continuing to win flavour in the testing industry as its true benefits are being realised. Introducing bug safaris have the advantage of not requiring major cultural or system changes, or expensive start-up costs.

Our Quality Vision (and Addressing Our Quality Past)

Monday, August 24th, 2009 by Jo Deeker

Like all software companies, we at Space-Time Research have juggled customer demands, complex software, very different uses of our software, and ever changing requirements. This has sometimes resulted in us delivering release software to our customers that is not of a sufficient quality, and later than we planned.

In the past, and as recently as our 6.3 release of our software, our testing group has passed a release and the software has been delivered to a customer and then a critical issue has been found. One of the main reasons this happens is that every customer has a slightly different environment. We currently support Solaris, Red Hat Linux, Windows 64 bit, Windows 32 bit, Windows XP and Vista for our client applications, browsers including IE6, IE7, IE8, Chrome, Firefox, Safari. We read data from any relational database that has a jdbc driver including Oracle, SQL Server, DB2 and others, plus different types of text files. We provide mapping with ESRI ArcIMS, ArcGIS Server, Google Maps and soon Bing Maps. We test all these environments and on our servers, our testing can pass.

Then we get out to the customer environment and encounter different environments & constraints. Not everyone can host a Tomcat application and we might have to hook to IIS. Firewalls might be an issue. Ports might be an issue. The client might operate in a remote way. Even if we don’t officially support a configuration, our clients will implement that way anyway and it’s up to us to sort it out.

Once we have the software successfully installed and configured at a client site, they then build some databases and work out how they are going to analyse or visualise their information. Every client has different types of databases, structures and uses of their information. Our testing doesn’t cover every different type of database - we try to, but of course we don’t cover everything. So sometimes we miss things - heirarchical summation options being a recent example.

Finally, our customers use the software with their own workflow. We follow a standard workflow with our automated tests, and then we conduct exploratory testing that mimics what a customer would do, but as we are not the customer, we don’t always get that exactly right either.

So, how do we improve it? What have we done and what are we doing next?

Firstly, for our 6.5 General Availability Release, Space-Time Research defined the following quality vision:

  • Timely, relevant, functioning software that works!
  • Performance, stability and resiliency focus.
  • Deliver releases of SuperSTAR that are perceived within STR and by our partners and customers as better than the previous release.

All decisions about testing, and then which bugs we fix, and when we release our software, are related back to the quality vision.

We implemented a partnership approach with some selected customers to enable them to test pre-release versions of our software. We conducted fortnightly builds, ran a couple of days of testing and then made the builds available to the customer. Builds were provided via FTP site, and customers were able to download the software and install in their own test environments. The customers were able to choose whether they would take a build or not. STR also hosted versions of our web applications so customers could do user interface testing without having to run their own installation and configuration.

The customers reported bugs, severity and their own priority via our normal support channel (via email to support@spacetimeresearch.com). We regularly triaged the bugs reported, and communicated via conference call with each customer to advise what we intended to do, or discuss concerns.

The benefits of this approach were clear for each customer involved:

  • Integration and configuration issues were ironed out during the pre-release phase.
  • Customer-focused testing found issues we would never have found.
  • The end delivery held no surprises.
  • We delivered on time to those customers and met their deadlines.

6.5 General Availability release is almost complete on all platforms. I’ll do another blog and announcement about that separately.

For our next release, we are implementing a fully agile development process. Another blog on that is coming too! But for our customers, please know that we want to:

  • Involve more customers in pre-release testing.
  • Collect more sample databases from customers.
  • Collect reference data sets from customers so we can validate our statistical routines.
  • Use client test beds for complex or unusual environments.
  • Open up our change management and support processes so customers can track issues they are interested in.

Cheerio

Jo