Radio Explorer
Version 2.7.7 radio explorer
screenshots
… in 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
contact
acknowledgments
legal
copyright & trademarks
license
various
background info
Last updated:
page content on February 6, 2012.
Quality
This page describes how quality is achieved for Radio Explorer.
On this page:
- Attitude to quality
- Infrastructure for quality assurance
- Static analysis
- Tests in action
- Web site and built‑in help
- Release
- Java software and operating systems
- Schedule files
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.
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.