SBR PROGRAM
SELF-CERTIFICATION
TESTING GUIDE
Purpose:
This document provides advice to SBR Agencies and
Software Developers on SBR testing and self-certification of
SBR-enabled software.
SBR Program Director: Paul Madden
Date:
21 October 2009
Contact:
For further information or questions, contact the SBR Program Office at
sbr@treasury.gov.au or call +61 2 6263 3900
Standard Business Reporting Program
SBR Self-Certification Testing Guide
DOCUMENT CHANGE CONTROL
Version
number
Date of issue
Author(s)
Brief description of change
0.2
25
September
2009
SBR Program
Released for comment
1.0
21 October 2009
SBR Program
Final
DOCUMENT APPROVALS
Contact Name
Position
Phone No.
SBR
SBR Program Office
+61 2 6263 3900
Name
Title
Date
Greg Divall
SBR Program Manager
21 October 2009
This document was approved by:
Version: 1.0
Page 2
Standard Business Reporting Program
SBR Self-Certification Testing Guide
COPYRIGHT
© Commonwealth of Australia 2009
This work is copyright. You may download, display, print and reproduce this material in unaltered form
only (retaining this notice) for your personal, non-commercial use or use within your organisation.
Apart from any use as permitted under the Copyright Act 1968, all other rights are reserved. Requests
and inquiries concerning reproduction and rights should be posted at the Commonwealth Copyright
Administration website or addressed to:
Commonwealth Copyright Administration
Attorney-General’s Department
3-5 National Circuit
Barton ACT 2600
Australia
Version: 1.0
Page 3
Standard Business Reporting Program
SBR Self-Certification Testing Guide
TABLE OF CONTENTS
1.
INTRODUCTION ................................................................................................................. 5
1.1.
1.2.
1.3.
1.4.
1.5.
Purpose ..........................................................................................................................................5
Audience ........................................................................................................................................5
Document Context..........................................................................................................................5
Document Scope............................................................................................................................6
Terminology....................................................................................................................................6
2.
CONFORMANCE TESTING FRAMEWORK.............................................................................. 7
2.1.
2.2.
2.3.
2.4.
2.5.
2.6.
2.7.
Self-Certification Model ..................................................................................................................7
Conformance Testing Workflow .....................................................................................................7
Testing Landscape .........................................................................................................................8
Test Service URLs .........................................................................................................................9
Testing Phases...............................................................................................................................9
Entry and Exit Criteria ................................................................................................................. 10
Regression Testing ..................................................................................................................... 10
3.
TEST DATA MANAGEMENT .............................................................................................. 11
3.1.
3.2.
3.3.
3.4.
3.5.
Requirements .............................................................................................................................. 11
Business Profile Types................................................................................................................ 11
Business Profile MetaData — SBR Level ................................................................................... 12
Business Profile MetaData — Agency Level .............................................................................. 12
Test Credentials .......................................................................................................................... 13
4.
WEB SERVICE CONFORMANCE TESTING .......................................................................... 14
TAXONOMY CONFORMANCE TESTING ........................................................................................ 15
4.1.
4.2.
4.3.
Test Case Selection .................................................................................................................... 15
Test Case Execution ................................................................................................................... 16
Test Case Template .................................................................................................................... 16
Version: 1.0
Page 4
Standard Business Reporting Program
1.
SBR Self-Certification Testing Guide
INTRODUCTION
1.1. PURPOSE
The purpose of this document is to provide information that will assist software developers to complete
SBR conformance testing of their products.
1.2. AUDIENCE
The audience for this document is any organisation that will be extending their software to make it
SBR-enabled. Typically, this will be software application developers.
Readers should be familiar with the following:
•
SBR Program – please see www.sbr.gov.au for further information.
•
XBRL – please see www.xbrl.org for further information.
•
Web Services – please see www.ws-i.org for further information.
1.3. DOCUMENT CONTEXT
Figure 1 - SBR Product Map
sbr.gov.au
SBR Solution Overview
Web Service
Implementation Guide
Taxonomy Architecture
Message
Implementation Guide
SBDM.xsd
Definitions
Message
Business
Interactions
Message structure
Implementation
Guide
Validation Rules
Exceptions
WSDL
Reports
(One per report)
SBR XBRL taxonomy
SBR Web Services
Security & Messaging
Test Cases
SBR Test Profiles
SBR Test Credentials
Web Service Conformance
Testing
Version: 1.0
Self-Certification
Testing Guide
Registration & certification
Test landscape
Test data & credentials
Test case template
Test Data
Report Test Data
Report Test Cases
Test Cases
Taxonomy Conformance
Testing
Page 5
Standard Business Reporting Program
SBR Self-Certification Testing Guide
The documents and schema shown in Figure 1 are available from the SBR website. Software
developers should:
•
Use the Web Services Implementation Guide (WIG) and the supporting WSDL to build basic
SBR security and messaging capability. The web service implementation is independent of any
specific report. Conformance with SBR web services can be assessed at this stage.
•
Use the relevant Message Implementation Guide (MIG) and supporting XBRL reporting
Taxonomy to implement each report that will be supported by the software product. Each MIG
has an associated conformance test suite that is used by the software developer for
self-certification.
1.4. DOCUMENT SCOPE
•
Section 2 describes the software developer self-certification framework. The framework includes
the certification process workflow, the testing landscape, support procedures, and change
management (re-certification).
•
Section 3 defines the test data management framework. Test data includes a library of ‘Business
Profiles’ together with test credentials that are available for software developer use and are
supported by SBR Agencies.
•
Section 4 describes the SBR Web Service conformance testing suite. This set of tests needs to
be run only once by any software developer.
•
Section 5 describes the Taxonomy conformance testing framework. There is one conformance
test suite per Agency report (or related set of reports). One test suite will comprise several test
cases. Test cases are versioned to support new versions of the corresponding reporting
Taxonomy.
1.5. TERMINOLOGY
For definition of the terminology and acronyms used within this document, please refer to the glossary
on the SBR website.
Version: 1.0
Page 6
Standard Business Reporting Program
2.
SBR Self-Certification Testing Guide
CONFORMANCE TESTING FRAMEWORK
Both SBR Agencies and software developers seek confidence that SBR enabled products will lodge
valid reports with government. Accordingly, the SBR Program has established a conformance testing
framework for software developers.
2.1. SELF-CERTIFICATION MODEL
The SBR approach to software product certification follows a self-certification model. Each software
developer is required to complete a suite of conformance tests and to maintain records of successful
tests for audit purposes. Products that have declared conformance will be listed on the SBR website.
The SBR certification approach is based on the current ATO process for software developer
certification. It firstly establishes the minimum criteria that the software must meet, and then requires
the software developer to declare that they have achieved the required testing results. The results are
not reviewed by Government or by a third party, so the declaration is a self-certification of compliance,
with no implied approval or endorsement by the SBR Program or any Government Agency. However,
on a risk basis, the SBR Program will undertake a targeted compliance audit of software developer’s
adherence to the agreed processes.
2.2. CONFORMANCE TESTING WORKFLOW
The conformance testing workflow is shown in Figure 2 below.
SBR Program
Software
Developer
Agency
Figure 2: Self-certification Process
The key points are:
•
For each report in scope for SBR, Agencies will load conformance test cases and test data to the
SBR Website.
•
XBRL Taxonomies and other SDK components will be uploaded to the SBR website as part of
the SBR Taxonomy release process.
•
Software developers register with the SBR Program to get test company profiles, to obtain
access to their own secure area, and to download content (including test specifications and
scenarios).
Version: 1.0
Page 7
Standard Business Reporting Program
SBR Self-Certification Testing Guide
•
Support will be available to software developers through the SBR service support model. The
initial contact will be through the SBR channel service desk, which as required refers the matter
to level 2 and 3 resolver groups or level 2 Agency support.
•
A test gateway will be established and maintained for continuous and concurrent use by software
developers. All conformance tests are performed via the SBR test gateway. Software developers
should keep the testing results for audit purposes.
•
Conformance testing at the SBR web service level can be performed independently from any
report specific conformance testing.
•
Conformance testing at the Taxonomy level is performed on a report by report basis. Each report
is supported by a conformance test suite that includes test data and several test cases.
•
Software developers declare successful conformance tests to the SBR Program. SBR maintains
a list of software products and the SBR reports for which the product has successfully completed
conformance testing.
•
New versions of SBR reporting taxonomies require software developers to complete regression
tests. Updated taxonomies, test data and test cases are published with each version update.
•
Software developers should communicate conformance claims to SBR for each version of their
product that is released to market. However, SBR recognises that software products may have
frequent releases and that not every release includes changes to SBR interfaces. Accordingly, it
is the responsibility of the software developer to assess (and be prepared to substantiate)
whether regression testing against SBR conformance test suites is necessary.
2.3. TESTING LANDSCAPE
The physical landscape for conformance testing is shown in Figure 3 below.
Figure 3 - Testing Landscape
Version: 1.0
Page 8
Standard Business Reporting Program
SBR Self-Certification Testing Guide
The key points are:
•
Each SBR report (or related set of reports) is supported by a MIG. Each MIG will be supported by
one ‘Conformance Test Suite’ document.
•
Each conformance test suite will reference multiple test cases.
•
A test case will use one or more test business profiles.
•
Each test business profile includes one or more test security credentials.
•
Test messages are authenticated via the test Vanguard STS (Secure Token Server).
•
Test messages are sent to Agency test systems via the SBR Core Services test gateway.
•
Agencies define the conformance criteria for each test case and provide suitable test interfaces.
•
Agency test interfaces are generally ‘idempotent’ (calling the same interface twice with the same
data delivers the same result). This allows multiple independent software developers to execute
the same test cases at the same time. However, some test interfaces will not be idempotent and
SWD should refer to the relevant conformance test suite documentation for instructions on how
to avoid clashes:
–
In some cases, software developers may be required to call a rollback transaction prior to
testing the ‘lodge’ service. In such cases, the test case will specify how to call the rollback.
–
In other cases, Agencies may offer a daily refresh of test data and so SWD will need to
either use dedicated ABNs or request a reserved timeslot for testing.
•
2.4. TEST SERVICE URLS
The SBR software developer test web service URLs are:
Service
URL
List
https://test.sbr.gov.au/services/list.02.service
PreFill
https://test.sbr.gov.au/services/prefill.02.service
PreLodge
https://test.sbr.gov.au/services/prelodge.02.service
Lodge
https://test.sbr.gov.au/services/lodge.02.service
SBR web services should be invoked in accordance with the specifications defined in the Web Service
Implementation Guide (WIG).
2.5. TESTING PHASES
Certification testing can be divided into two phases.
•
Web-service conformance testing confirms that:
–
Client software conforms to SBR security and messaging protocols as defined in the Web
Service Implementation Guide. This includes both the WS-Trust request to the STS and the
WS-Security request to SBR Core Services;
–
Client software has correctly implemented support for the standard message header that
drives the routing of messages to the appropriate Agency service ;
–
Client software correctly handles SOAP Faults that may be generated by SBR Core
Services or Agency systems.
Version: 1.0
Page 9
Standard Business Reporting Program
•
SBR Self-Certification Testing Guide
Taxonomy conformance testing confirms that:
–
Client software can create valid XBRL business messages that meet validation rules in the
XBRL Taxonomy and any Schematron rules.
–
Client software correctly implements business rules defined in the corresponding MIG
(Message Implementation Guide);
–
Agency response data is correctly handled in accordance with the MIG.
–
Business exceptions returned in the standard <Message.Event> header are correctly
handled by client software.
2.6. ENTRY AND EXIT CRITERIA
Entry Criteria for web service conformance testing:
•
Software developer has registered with SBR for conformance testing.
Entry criteria for Taxonomy conformance testing:
•
Web service conformance testing has been successfully completed.
•
Software developers have mapped their products.
Exit criteria for Taxonomy conformance testing:
•
All test cases in the selected conformance test suite have been successfully completed. If
performing a regression test after release of a new MIG then only changed test cases need be
re-run.
•
Test results have been stored for possible audit by SBR.
•
Conformance claims have been communicated to SBR.
2.7. REGRESSION TESTING
Taxonomy Version Changes
When a new version of a reporting Taxonomy is released, there may be a requirement for regression
testing by software developers. Depending on the scope of the change, not all test cases in a test
suite may be impacted. Each test case has a unique identifier of the form:
CONF-[Agency]-[SuiteName]-[TestCaseNumber]-[Version] — for example: CONF-ATO-AS-001.01
In order to claim conformance against the latest release of any reporting Taxonomy, software vendors
should complete conformance testing using the test cases listed in the relevant conformance test
suite.
Software Product Version Changes
SBR maintains software developer conformance claims by major version of each software developer
product. For each major version release of software developer product, regression testing should be
completed and results kept for audit purposes. Software developers should present conformance
claims to SBR for each major product version. For each minor version, software developers need to
confirm that the release does not affect the SBR interfaces.
Version: 1.0
Page 10
Standard Business Reporting Program
3.
SBR Self-Certification Testing Guide
TEST DATA MANAGEMENT
3.1. REQUIREMENTS
The SBR Program provides test ‘Business Profiles’ that can be used by software developers for
conformance testing with SBR Agencies. Each business profile is represented by an ABN. The
following requirements apply to the test profiles:
1.
The ABN’s should not represent real businesses that exist in production systems — to eliminate
the risk of a ‘test’ being sent to a production system and being recorded as a real lodgement.
2.
The ABN’s should still be valid ABNs issued by the Australian Business Register.
3.
A software developer should be able to use the same profile for testing with multiple SBR
Agencies and reports. Therefore the issuing and management of test ABNs is managed at SBR
Program level.
4.
Each ABN will include a valid ‘admin’ credential and optionally several ‘user’ and ‘device’
credentials.
5.
Agencies will configure their systems in readiness to receive test transactions from these test
ABNs. In essence, each Agency will complete a registration process for each test ABN that they
will support.
6.
In addition to the ABN, each profile includes key registration data such as registered name,
trading name, entity type, and registered address.
7.
Agencies may specify additional Agency specific registration data for a specific profile ABN (for
example, an ACN or State Revenue Office customer ID). In such cases, the Agency
conformance test suite will define any supplementary profile data.
8.
Every conformance test case must use one or more of the centrally managed test Business
profiles.
9.
The available test profiles will reflect real world variations in business type — from sole traders
to large enterprises. Agencies will need to know which ABNs to support in their test systems (for
example, sole trader types without employees will not need State Revenue Office systems to be
setup for payroll tax).
10.
The test data framework should be easy to use by software developers.
3.2. BUSINESS PROFILE TYPES
There are five broad business profile types:
Type
Description
SOLE
Sole Trader
SME
Small Business with a few employees
PTYLTD
Proprietary Limited Company
ENT
Large Enterprise / Public Listed Company
INTER
Intermediary
Version: 1.0
Page 11
Standard Business Reporting Program
SBR Self-Certification Testing Guide
In order to support more fine grained differences between test business profiles (for example, grouped
verses non-grouped) there will be many instances of each profile type and each profile is uniquely
identified with an ID of the form:
[Type]-[Number] for example: PTYLTD-01
The list of test profiles with supporting registration data and credentials is maintained on the SBR
website.
3.3. BUSINESS PROFILE METADATA — SBR LEVEL
Each test business profile will include a set of common data elements defined by the SBR Program.
The data includes:
•
Business Reference Data: Key registration data that will be setup consistently in all Agency
systems that will support the profile.
•
Authorised Roles: Key individuals and their related credential references that will match Agency
authorisation configuration.
An example test business profile is provided below. The complete list of profiles is available from the
SBR website. Additional profiles may be created as required to support Agency test cases.
Profile ID
PTYLTD-01
Description
ACME is a privately held construction company specialising in prefabricated
buildings. ACME has 500 employees across all states and territories. Annual
revenue is $250 Million and approximately $70 Million in total annual payroll.
ACME has two subsidiary companies, one that manufactures the prefabricated
structures and one that is a spare parts distribution company
Business Reference Data
Data Element
Taxonomy Reference(s)
Value
Australian Private
Company
Entity Type
ABN
pyid: Identifiers.AustralianBusinessNumber.Identifier
34123456789
ACN
pyid: Identifiers.AustralianCompanyNumber.Identifier
123456789
Registered
Name
pyde:OrganisationNameDetails.OrganisationalName.Text
ACME Construction
Pty Ltd
Trading Name
pyde:OrganisationNameDetails.OrganisationalName.Text
ACME Construction
Registered
Address
pyde.AddressDetails
10 George Street,
Paramatta, Sydney,
NSW 2150
Authorised Roles
Name
Role
Credential Ref
John Smith
CFO
PTYLTD-01-A
Sally Brown
Payroll Admin
PTYLTD-01-B
Steven Black
Accountant, Slick Accounts Pty Ltd
INTER-01-A
3.4. BUSINESS PROFILE METADATA — AGENCY LEVEL
In addition to common data elements and roles, Agencies may attach further data to any profile as
necessary for Agency test cases. This additional Agency specific data is defined at the level of the
relevant conformance test suite (and will apply for all test cases within the test suite).
Version: 1.0
Page 12
Standard Business Reporting Program
SBR Self-Certification Testing Guide
3.5. TEST CREDENTIALS
Each profile will have at least one associated security credential. In some cases, multiple security
credentials may be associated with one profile (reflecting the various delegated authorities within the
business). Some profiles will also have device credentials for use by SaaS (Software as a Service) or
client / server software system testing.
Each SBR credential carries a set of related meta-data that is maintained in the Security Token Server
and is returned in the encrypted SAML Token that is forwarded to Agencies (see the SBR Web
Services Implementation Guide for further details on the security implementation).
An example credential data set is provided in the table below. The full set of SBR test credentials are
available from the SBR website.
Table 1:
Table 1: Sample of credential data
Test Credential ID
PTYLTD-01-A
CLAIM URI
Value
http://vanguard.ebusiness.gov.au/2008/06/identity/claims/abn
34123456789
http://vanguard.ebusiness.gov.au/2008/06/identity/claims/commonname
John Smith
http://vanguard.ebusiness.gov.au/2008/06/identity/claims/credentialtype
ABR_User
http://vanguard.ebusiness.gov.au/2008/06/identity/claims/samlsubjectid
SBR34123456789.0000
01
http://vanguard.ebusiness.gov.au/2008/06/identity/claims/sbr_personid
000001
http://vanguard.ebusiness.gov.au/2008/06/identity/claims/givennames
John
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname
Smith
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
John.smith@acme.com.
au
http://vanguard.ebusiness.gov.au/2008/06/identity/claims/credentialadmini
strator
1
Credentials are provided in pre-loaded SBR keystores. The keystore passwords will be provided and
SWDs will be expected to use the keystore API to extract and use relevant credentials. The SBR
program provides a ‘reference client’ to assist with keystore interactions.
Version: 1.0
Page 13
Standard Business Reporting Program
4.
SBR Self-Certification Testing Guide
WEB SERVICE CONFORMANCE TESTING
SBR Web Service conformance tests are independent of any Agency specific report. The goal of web
service testing is to support software developers through the correct implementation of SBR security
and SOAP messaging standards. The table below provides a summary list of the SBR web service
conformance test cases. The reference specification for Web Service conformance testing is the SBR
Web Service Implementation Guide (WIG).
There is one positive conformance test case which performs a simple message exchange with all four
SBR web services using the <Message.Ping> services defined in the Web Services Implementation
Guide.
The remaining test cases exercise various error conditions that will generate SOAP faults. These test
cases are designed to confirm correct handling of each error condition.
Table 2:
Table 2: SBR Web Service Conformance Test Cases
Test Case ID
CONF-SBR-WS-00
Type
POS
CONF-SBR-WS-01
NEG
CONF-SBRWS-02
NEG
CONF-SBRWS-03
NEG
CONF-SBRWS-04
NEG
CONF-SBRWS-05
NEG
CONF-SBRWS-06
NEG
CONF-SBRWS-07
NEG
CONF-SBRWS-08
NEG
To confirm correct behaviour in the event of various Agency
transport problems:
1- No connection to Agency
2- Http error from Agency
3- Agency timeout
4- Agency system unavailable
CONF-SBRWS-09
NEG
To confirm correct behaviour in the event of various Agency system
errors:
1 - Malformed XML returned from Agency
2 - Invalid (against SBDM Schema) response returned by Agency
3 - General fault from Agency
4 - Invalid signature on Agency response
Version: 1.0
Test Objective
To confirm conformance with SBR Security & messaging
specifications.
To confirm correct fault handling of Invalid XML error from Core
Service Platform.
To confirm correct fault handling when too many XBRL documents
or binary attachments are sent in one message.
To confirm correct fault handling when document (xbrl or binary)
exceeds size limit.
To confirm correct fault handling when Agency or service requested
is unknown.
To confirm correct fault handling when no security token is included
in the request.
To confirm correct fault handling when a signature fails validation or
the security token fails decryption.
To confirm correct fault handling when an invalid security token is
included in the request. Invalid means:
1- token not for SBR
2- token expired
3- missing mandatory claims
4- certs for token and SBDM don’t match
Page 14
Standard Business Reporting Program
Test Case ID
CONF-SBRWS-10
Type
NEG
SBR Self-Certification Testing Guide
Test Objective
To confirm correct behaviour in the event of various core service
internal errors:
1 - Malformed XML encountered within core (as distinct from
Malformed XML received from business)
2 - A general unhandled error occurred in Core
3 - A configuration error in core
4 - Core could not retrieve a unique ID for the request
The Web Service conformance test suite document describes the Web Service conformance testing
environment and provides links to each detailed test case.
Once software developers have completed the test cases, a conformance claim can be provided to
SBR and the relevant software product will be listed on the SBR website.
TAXONOMY CONFORMANCE TESTING
Taxonomy conformance tests are Agency and report specific. Similar reports (for example, different
types of ATO Activity Statement or PAYG summaries) will typically be grouped together into one
conformance test suite.
The goal of Taxonomy conformance testing is to minimise the risk that a business user submits an
invalid report to SBR. Accordingly, SBR Agencies will select a set of conformance test cases that
adequately exercise the validation business rules in place within Agency systems.
To claim conformance for a particular report (for example, Activity Statement), software developers
must successfully complete all conformance test cases within the relevant conformance test suite.
4.1. TEST CASE SELECTION
The SBR website maintains a matrix (spreadsheet) that lists all available conformance test cases,
grouped by test suite. The matrix shows which test business profiles are used by each test case. This
spreadsheet allows software developers to gain a quick overview of:
•
Which report test suites are available and the number of test cases for each.
•
The business profiles that the software developer needs to implement in order to support the
selected test suites.
The spreadsheet is the entry point for software developers to assess which test suites to complete and
to locate the relevant test cases and test profiles. The table below shows a conceptual sample of the
test case matrix.
Version: 1.0
Page 15
Standard Business Reporting Program
SBR Self-Certification Testing Guide
Table 3:
Conformance Suite
INTER-02
INTER-01
ENT-02
ENT-01
PTYLTD-03
PTYLTD-02
PTYLTD-01
x
SME-04
x
SME-03
FR
x
SME-02
ASIC
x
SME-01
AS-01.01
AS-01.02
AS-02.01
AS-03.01
AS-04.01
AS-05.01
etc…
FR-01.01
FR-01.02
FR-01.03
FR-01.04
FR-01.05
FR-01.06
SOLE-03
Test Case
AS
SOLE-02
Report
ATO
Business Profiles
SOLE-01
Agency
Table 3: Test Case Matrix
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
4.2. TEST CASE EXECUTION
SBR Agencies will normally publish conformance test suites shortly after release of the corresponding
XBRL reporting Taxonomy and MIG (Message Implementation Guide).
It is important to emphasise that the published conformance test suites represent the minimum set of
tests that provide adequate confidence in the ability of the software product to produce valid
lodgements. In consultation with SBR, software developers may wish to derive further test cases from
the MIG as necessary to meet their own quality standards.
Every software product is different and SBR makes no assumptions about the behaviour of the
product user interface. Accordingly, SBR conformance test cases are written to exercise the
observable behaviour of the SBR interface and do not contain any reference to user actions via the
software product user interface.
Each test case defines the required test data, the test execution steps, and the conformance criteria.
Software developers must complete all steps in the test case and maintain records as evidence that
the specified conformance criteria have been met.
All conformance test cases together with test data are available from the SBR website.
4.3. TEST CASE TEMPLATE
A sample test case is provided in the table below.
Version: 1.0
Page 16
Standard Business Reporting Program
SBR Self-Certification Testing Guide
Table 4:
Table 4: Test Case Sample
Test Case ID
CONF-ATO-AS-001.01
Conformance Suite ID
ATO-AS
Purpose
To confirm that Activity Statement PAYG-Withholding obligation
data is correctly populated when required by the business profile.
Message Implementation Guide(s)
http://www.sbr.gov.au/content/downloads/software_developers/A
ctivity_Statement_MIG.pdf
Business Profile(s) Required
PTYLTD-01
Credential(s) Required
PTYLTD-01-A
Test Case Parameters
ContextID
Context Values (Entity, Segment, Period, Dimensions)
C001
Entity = (PTYLTD-01 profile ABN)
Period = 2008-07-01 to 2009-06-30
ReportPartyTypeDimension = ‘ReportingParty’
Data Element
Context ID
Value
pyde.02.02:OrganisationDetails.OrganisationBranc
h.Code
C001
01
pyin.02.02:BusinessDocument.GovernmentGenerat
edIdentifier.Text
C001
<DIN>
Etc..
Test Case Execution
Step
Description
Conformance Criteria
1
Call prefill service URL with valid
as.001.prefill.request structure
containing the DIN provided.
as.001.prefill.response received
containing PAYG-W elements. This XBRL
instance is a template for a valid
lodgement.
2
Populate the data elements in the
prelodge response in accordance with
the activity statement MIG.
N/A
3
Call prelodge service URL with valid
as.001.prelodge.request structure
Successful (criteria?)
as.001.prelodge.response received.
4
Save all request response envelopes
together with this completed test case
for audit purposes.
Result
OK
OK
OK
Reporting Taxonomy Versions and Test Instance Data
Prefill
request
http://sbr.gov.au/sbr_au_reports/ato/as/as_0001/as.
0001.prefill.request.02.00.report.xsd
http://sbr.gov.au/conformance/ato/as/ato
-as-001/prefill.request.02.00.xml
Prefill
response
http://sbr.gov.au/sbr_au_reports/ato/as/as_0001/as.
0001.prefill.response.02.00.report.xsd
<sample>
Prelodge
request
http://sbr.gov.au/sbr_au_reports/ato/as/as_0001/as.
0001.prelodge.request.02.00.report.xsd
<sample>
Prelodge
response
http://sbr.gov.au/sbr_au_reports/ato/as/as_0001/as.
0001.prelodge.response.02.00.report.xsd
<sample>
Version: 1.0
Page 17
Standard Business Reporting Program
SBR Self-Certification Testing Guide
The key points are:
•
The test case ID carries a version number. Software developers should refer to the conformance
test suite document to determine which test case versions should be performed.
•
Each test case identifies the test suite of which it is a part. Testers should download the test suite
document and ensure that any instructions or profile data defined at test suite level are
understood and implemented.
•
Each test case has a specific purpose.
•
Each test case lists the identifiers of the business profiles and test credentials that are required.
Some test cases may use multiple profiles or credentials.
•
Each test case specifies the required values for any specific parameters. The parameters will
normally be specific values for XBRL Taxonomy elements. Accordingly the fully qualified XBRL
data element names are used in order to avoid ambiguity.
•
Parameters include XBRL context information.
•
Test case execution steps and conformance criteria are written from the perspective of the data
interface (‘provide these values in the request and you should expect to get this response’..).
•
Every test case lists the specific URLs for the XBRL Taxonomy entry point schema that describe
each message involved in the test case.
•
Every test case provides reference XBRL instance data sets for each request/response
interaction in the test case. It is not expected that the software developer will use these directly
because the normal scenario is that the request envelopes are generated from data in the
software application. However, the reference envelopes can be used to help software developers
during testing because they contain test case specific data that would generate a successful test
result. The test case reference envelopes are published to the SBR website at:
http://sbr.gov.au/conformance/[agency]/[suite]/[testcase]/[envelopename].xml
for exmple: http://sbr.gov.au/conformance/ato/as/ato-as-001/prefill.request.02.00.xml
Version: 1.0
Page 18