Skip to main content

Home Page

Radio Explorer

Version 2.7.7
Listen to the World Around You

Home

Download | Register  |  One-click installation — Java Web Start

radio explorer
screenshots
English français Deutsch italiano português русский español Türkçein your language
quality
history, news, plans
documentation
requirements
installation
quick start
input data: stations, frequencies, schedules
support
customer care center
tech questions
known issues
about

acknowledgments
legal
copyright & trademarks
license
various
background info

DXZone listed
DXZone listed
DXZone listed

Last updated:
page content on February 6, 2012,
page source code on February 6, 2012.

Quality

This page describes how quality is achieved for Radio Explorer.

On this page:

Attitude to quality

High quality is one of the main priorities in Radio Explorer.

Infrastructure for quality assurance

The infrastructure was built during the summer of the year 2009, using the best practices of software development, and with modern tools, some of which appeared only in the recent years and had not been available when the Radio Explorer project started.

Before the infrastructure was built, quality assurance had been manual, and therefore time‐consuming and prone to human error.

The goal of the infrastructure is to automate the quality assurance activities, when possible, so that they could be performed faster and more reliably.

The infrastructure provides a safety net, allowing to release new versions of Radio Explorer with the reassurance that once some problem is detected and eliminated, the future versions will not have it. In effect, the infrastructure makes Radio Explorer possible as an application with a consistent level of quality in the changing environment, in which Radio Explorer performs.

Static analysis

Static analysis tools check the code of the program, and detect parts in it that could potentially lead to problems.

Static analysis is like an external audit performed by experts in Java programming language and Java programming platform.

Source code

Static analysis of source code is done both on‑the‑fly, while a source code file is being edited, and as a batch check of the entire source codebase.

Used only for on‑the‑fly analysis is the NetBeans IDE (Integrated Development Environment). Used both for on‑the‑fly analysis and in batch mode are the PMD and Checkstyle tools.

Compiled executable code

Executable code, compiled from source code, is also checked by static analysis tools. The tools used for this purpose are FindBugs and Jlint.

Static analysis of compiled executable code is done in batch mode, checking the entire compiled codebase. The tools find dependencies between different objects, and detect problems that could not be detected on the source code level, where tools usually run in the scope of a single file.

Tests in action

After a feature is implemented in source code, it is tested in action.

Tests are small programs, which verify that a particular source code file, or several files, work correctly.

Tests are especially useful in verifying functionality that is not clearly obvious, like verifying that the program reads data from schedule files correctly and interprets it correctly. In such cases, special tools can check that every related line of source code is tested. A line of code may need to be tested multiple times, because the program may go through this line via several different logical paths.

As new features are added and the existing features are modified, more tests are added.

Web site and built‑in help

Software must work according to its documentation. This in turn means that the documentation itself should be well‐organized and comprehensive.

It is possible to automatically verify, to some extent, that the documentation is well‐organized. This concerns both the built‑in help in Radio Explorer and this Web site. Validator tools are used to check that the contents comply with standards for structure, presentation, and accessibility of documents.

For example, you can validate this page and the newsfeed on this Web site by using the image links below.

Valid XHTML + RDFa Valid CSS Valid RSS

Cynthia Tested

Like with Static analysis of Source code, validation of the contents is done both on‑the‑fly, while a file that is part of this Web site or of the built‑in help is being edited, and in batch checks that verify the integrity of the entire Web site and the entire help system (for example, ensuring that there are no hanging links).

Release

To qualify for release, the program must pass Tests in action.

Since August 2009, the set of files that are produced during release includes a special version of Radio Explorer with self‐diagnostic facilities. These facilities correspond to Tests in action, and provide a way to perform low‐level testing of the program’s features not only in the compiled executable code form, but also in the assembled release form.

The release process also includes tests of the installation, upgrade, and uninstallation procedures, both using the downloaded distribution zip archive file and via Java Web Start technology.

Java software and operating systems

Platform software, on which Radio Explorer depends, is continuously updated. This includes operating systems that Radio Explorer runs on, and Java software, which is necessary for running Radio Explorer.

So the process of quality assurance does not end at the release point. It is necessary to continue testing the released version with updates of platform software.

Testing is done on Windows XP and on the latest version of Ubuntu Linux Desktop Edition. On these operating systems, testing is done with the latest version of Java software available for each operating system.

Regular updates

After a regular operating system update or a regular update of Java software is released, the special version of Radio Explorer with self‐diagnostic facilities, described in the Release section, is used.

The special version performs low‐level testing of the program’s features. This ensures that the current version of Radio Explorer still passes Tests in action on up‑to‑date operating system and on up‑to‑date Java software.

Major new versions

When a major new version of an operating system or a major new version of Java software is released, two sets of activities take place.

As the first step, the same activities are performed as for the Regular updates of operating systems and Java software.

As the second step, the same tests of the installation, upgrade, and uninstallation procedures as described in the Release section, are performed.

Major new versions may bring changes in the user interface, or in the integration between Java software and operating systems. These changes may call for corresponding changes to the documentation, described in the section Web site and built‑in help.

Schedule files

When a new schedule file appears on the Web, data in the file is checked for compliance with the supported file format. Both manual inspection and automatic verification are performed.

If the format of the schedule file has changed, a new version of Radio Explorer is released in response to the change. Backward compatibility is maintained—the new version will support both the previous format and the new format.

Dates of update of schedule files on the Input Data page indicate with which schedule files Radio Explorer has already been verified to work.