Access Continuum allows customers who also have an AMP license to send their testing results to reports within AMP. Doing this allows customers to regularly report on accessibility for an asset over time, by testing at various points in the SDLC. For example, an organization may choose to use Continuum to test their application whenever a new release branch is created, and in this use they may want to test and report those results to the analogous Asset within AMP.
On this page:
- API token key
- AMP instance URL
- AMPReportingService class
- Find organization and other identifiers in AMP
- Why send continuous testing data to AMP?
- Code examples
API token key
Connecting your Access Continuum instance to AMP will require use of an API Token Key to authorize the connection. The API Token Key can be accessed as follows:
- In your AMP instance, select the "Preferences" link in the application header bar.
- Select the "API Token Management" link.
- Select the "Create Token" button and specify a name that indicates where the token will be used (e.g., Acme Mobile App Regression Build).
- Copy the token from the "Token" column.
The API Token should be pasted into the relevant field in the continuum.json/continuum.js.conf file.
AMP instance URL
The "ampInstanceUrl" value should be set to the URL for AMP where you created your API Token. For instance, if the results should be saved to report on https://company1.levelaccess.net - then please update the value for the "ampInstanceUrl" from https://amp.levelaccess.net to https://company1.levelaccess.net in the continuum.json/continuum.js.conf file
In this example "company1" is a placeholder for whatever the URL for your AMP instance is. Also, please be sure to omit any trailing slashes. For example: the URL https://company1.levelaccess.net/ has a trailing slash that will prevent the results from being saved.
AMPReportingService class
Included with Access Continuum, for Java or Javascript, is a public class that encapsulates all functionality related to sending Continuum-found violation instances to AMP -- AMPReportingService. This class is identical between the Java and Javascript versions of Continuum.
To send data to AMP:
- Define the reporting strategy -- either create new reports or edit existing ones -- using AMPReportingService.ReportManagementStrategy.
- Define the strategy for writing to new modules or editing existing ones using AMPReportingService.ModuleManagementStrategy.
- Once the strategies for writing to a report and module are specified, the submitAccessibilityConcernsToAMP(List) method can be invoked.
Find organization and other identifiers in AMP
When writing data to AMP, it is required to know the ID for the Organization and Asset where you plan to save your results. From a Continuum perspective these are referred to as the "activeOrganizationID and the "activeAssetID". To find the active Organization ID, select the organization using the organization selector in the top AMP nav bar. The organization ID will be displayed in the URL in the browser address bar (e.g., "organization_id=12345").
To find the active Asset ID navigate to the Asset in AMP where you plan to save the Continuum results. The Asset ID can be found in the URL in the browser address bar and is called the system_id in the URL. (eg: "system_id=12345")
Why send continuous testing data to AMP?
There are several use cases for sending data from Continuum to your AMP instance. In general, they fall into two categories:
- Reporting in which the compliance of the current build should always be displayed: In this case, the organization may choose to always overwrite all data in the same report, so a single report always represents the current state of accessibility for the asset in development. For this use case, the recommended reporting strategy to use is ReportManagementStrategy.OVERWRITE and ModuleManagementStrategy.OVERWRITE which will allow you to always overwrite the data previously sent to a report in AMP.
- Post-development report, in which the compliance ahead of a release should be displayed: In this case, the organization regularly reports on compliance at a specific point in the SDLC, such as just after a release build is branched to incorporate accessibility testing into the regression testing process. In this case, the organization may choose to write test results from Continuum to a new report every time this testing is done, so they can report on accessibility over time. Doing this allows the organization to identify issues that regularly make their way into release candidates, so they can institute new processes and training to address the problems at the root cause level. For this use case, the recommended reporting strategy to use is ReportManagementStrategy.UNIQUE and ModuleManagementStrategy.APPEND which will allow you to always create a new report and to add new modules to that report, instead of overwriting them.
Code Examples
Continuous Integration Use Case
The code example below demonstrates a sample implementation of the continuous integration use case, described above, in which reporting is done at a regular point in the SDLC and data is always written to a new report. In this example, note that a new report and a new module within that report are created to house the violation instances found in testing.
List<AccessibilityConcern> accessibilityConcerns = continuum.runAllTests();
if (accessibilityConcerns.size() > 0) {
AMPReportingService ampReportingService = continuum.getAMPReportingService();
ampReportingService.setActiveOrganization(1099); // ID of AMP organization to submit test results to
ampReportingService.setActiveAsset(36030); // ID of AMP asset to submit test results to
ampReportingService.setActiveReport("Report from CI");
ampReportingService.setActiveModule("Login Screen", driver.getCurrentUrl());
ampReportingService.setActiveReportManagementStrategy(AMPReportingService.ReportManagementStrategy.UNIQUE);
ampReportingService.setActiveModuleManagementStrategy(AMPReportingService.ModuleManagementStrategy.APPEND);
ampReportingService.submitAccessibilityConcernsToAMP(accessibilityConcerns);
}
Developer workstation use case
The code example below demonstrates a sample continuous testing use case in which developers are running tests regularly as they update code. In this example, the developer would always overwrite results in a single report in AMP, which would always represent the current state of the application.
accessibilityConcerns = continuum.runAllTests();
if (accessibilityConcerns.size() > 0) {
AMPReportingService ampReportingService = continuum.getAMPReportingService();
ampReportingService.setActiveOrganization(1099); // ID of AMP organization to submit test results to
ampReportingService.setActiveAsset(36030); // ID of AMP asset to submit test results to
ampReportingService.setActiveReport("Report from Developer Workstation");
ampReportingService.setActiveModule("Login Screen", driver.getCurrentUrl());
ampReportingService.setActiveReportManagementStrategy(AMPReportingService.ReportManagementStrategy.OVERWRITE);
ampReportingService.setActiveModuleManagementStrategy(AMPReportingService.ModuleManagementStrategy.OVERWRITE);
ampReportingService.submitAccessibilityConcernsToAMP(accessibilityConcerns);
}
Comments
0 comments
Article is closed for comments.