Globus Toolkit Release Testing Overview
The diagram above presents a high-level overview of the quality assurance process for Globus Toolkit® releases. The process begins when the first Release Candidate (RC) is assembled using code from the Globus CVS repository. The RC is then subjected to a standard battery of tests. If the tests reveal a showstopper bug, the problem is fixed and a new RC generated. The process continues until all tests have completed without uncovering any showstoppers.
The standard battery of tests for the Globus Toolkit includes:
Unit Tests: Unit Tests are written by Globus Alliance developers in support of their own development process. The tests are designed to verify method and function-level integrity of the developer’s code. These are “glass box” tests, meaning that they have been written by people with a deep understanding of the implementation.
Component-Level Tests: Component-Level Tests are higher-level in scope than Unit Tests. These tests target the code in a particular Globus Component (i.e., GRAM). Technology Coordinators hold the responsibility for maintaining the suite of Component-Level tests for their Technology. Component-Level tests also fall into the “glass box” category.
Basic User Tests: Basic User Tests are designed to exercise the software in ways that developers may not anticipate. These tests are built using existing user documentation; they are known as “black box” tests. While the focus of the testing is on basic user interactions, a Basic User Test can involve more than one Globus Component (i.e., GRAM + RFT + GridFTP.)
Project-Specific Tests: Project-Specific Tests mimic the way the Globus Toolkit is applied in various application domains (HEP, Earthquake Engineering, etc.).
Calls for Community Testing
A Call for Community Testing is a mechanism to notify our users that new code is available for testing in the field. See this page for the list of current and future testing calls.