Al-Borj - Integration QA Test Plan v0.04

Quality Assurance (QA) Test Plan
Al-Borj
Integrations
Version 0.04
September 25, 2014

Al-Borj - Integration QA Test Plan v0.04.doc
Document Revision History
Version # Author/Editor Date Notes/Changes
0.01 Chris Pittman
/Tracy Jefferson
11/6/14 First Draft for Review.
0.02 Chris Pittman
/Tracy Jefferson
15/6/14 Additional content.
0.03 Chris Pittman /
Tracy Jefferson /
Omar Al Salahi
17/6/14 Additional content.
0.04 Chris Pittman 30/6/14 Added additional test to Maximo
Note: Version numbers less than 1.0 denote drafts while version numbers of 1.0 and higher denote final
documents and subsequent revisions to them.

TABLE OF CONTENTS
1 Introduction .................................................................................1
1.1 Purpose ...............................................................................................................1
1.2 Audience .............................................................................................................1
1.3 Additional References/Resources................................................................................1
2 Overview .....................................................................................2
2.1 Project................................................................................................................2
2.2 Integrations Testing Overview ...................................................................................2
2.3 Roles and Responsibilities.........................................................................................3
2.3.1 IT Manager.................................................................................................3
2.3.2 Business Analyst (BA)....................................................................................3
2.3.3 Technical Leads (TL) ....................................................................................3
2.3.4 eSolutions Lead...........................................................................................3
2.3.5 ISS Lead ....................................................................................................3
3 Testing Definitions .........................................................................4
3.1 Phases of Testing ...................................................................................................4
3.1.1 Unit Testing ...............................................................................................4
3.1.2 Quality Assurance Testing (System Testing) ........................................................4
3.1.3 User Acceptance Testing ...............................................................................4
3.1.4 Deployment Testing (Smoke Testing) ................................................................4
3.2 Types of Testing ....................................................................................................5
3.2.1 End to End Process (Scenario) Testing ...............................................................5
3.2.2 Functional/Graphical Testing ..........................................................................5
3.2.3 Security & License Testing .............................................................................5
3.2.4 Integrations Testing .....................................................................................5
3.2.5 Performance Testing ....................................................................................5
3.2.6 Reliability Testing........................................................................................5
3.3 Testing Documentation ............................................................................................6
3.3.1 Test Plan...................................................................................................6
3.3.2 Traceability Matrix.......................................................................................6
3.3.3 Test Scripts................................................................................................6
3.3.4 Testing Tools..............................................................................................6
4 Defect Reporting............................................................................7
5 Testing Entrance and Exit Criteria ......................................................8
6 Reviews and Reporting .................................................................. 10
7 Scope of Testing .......................................................................... 11
7.1 In Scope............................................................................................................. 11
7.2 Out Scope .......................................................................................................... 11
8 Test Scenarios............................................................................. 12
8.1 TRIRIGA/AX Integration .......................................................................................... 12
8.1.1 New Tenants in TRIRIGA to AX....................................................................... 12
8.1.2 New Tenants in AX to TRIRIGA....................................................................... 12
8.1.3 Changes made to TRIRIGA tenant record and sent to AX ....................................... 12
8.1.4 Changes made to AX tenant record and sent to TRIRIGA ....................................... 12
8.1.5 RE Invoices created in TRIRIGA and sent to AX................................................... 12
8.1.6 RE Invoices modified in TRIRIGA and updates sent to AX....................................... 12
8.1.7 RE Invoices cancelled in TRIRIGA.................................................................... 12
8.1.8 Changes made to Sales Line Items in Ax and sent to TRIRIGA ................................. 12
8.1.9 Payment applied in AX and sent to TRIRIGA ...................................................... 12
8.2 TRIRIGA/Maximo Integration .................................................................................... 12
8.2.1 New work orders created in TRIRIGA............................................................... 12
8.2.2 Maximo PM work orders sent to TRIRIGA .......................................................... 12
8.2.3 Priority changes in TRIRIGA and sent to Maximo ................................................. 12
8.2.4 Work order completed in TRIRIGA .................................................................. 12
8.2.5 Work order completed in Maximo................................................................... 12
8.2.6 Work order closed in TRIRIGA ....................................................................... 13
8.2.7 Work orders manually closed in Maximo........................................................... 13
8.2.8 Work orders auto closed in Maximo ................................................................ 13
8.2.9 Work orders cancelled in TRIRIGA .................................................................. 13
8.2.10 Work orders cancelled in Maximo................................................................... 13
8.2.11 Corrective maintenance work order created in Maximo ....................................... 13
8.2.12 Other status change occurs in Maximo............................................................. 13

9 Traceability Matrix ....................................................................... 14
10 Test Scripts ................................................................................ 16
10.1 TRIRIGA / AX Integration......................................................................................... 16
10.1.1 New Tenants in TRIRIGA to AX....................................................................... 17
10.1.2 New Tenants in AX to TRIRIGA....................................................................... 19
10.1.3 Changes made to TRIRIGA tenant record and updated in AX .................................. 21
10.1.4 Changes made to AX tenant record and updated in TRIRIGA .................................. 23
10.1.5 RE Invoices created in TRIRIGA and sent to AX................................................... 25
10.1.6 RE Invoices modified in TRIRIGA and updates sent to AX....................................... 27
10.1.7 RE Invoices voided in TRIRIGA ....................................................................... 29
10.1.8 Changes made to Sales Line items in AX and sent to TRIRIGA ................................. 31
10.1.9 Payment applied in AX and sent to TRIRIGA ...................................................... 33
10.2 TRIRIGA / Maximo Integration .................................................................................. 36
10.2.1 New work orders created in TRIRIGA............................................................... 36
10.2.2 Maximo PM work orders sent to TRIRIGA .......................................................... 38
10.2.3 Priority changes in TRIRIGA and sent to Maximo ................................................. 40
10.2.4 Work order completed in TRIRIGA .................................................................. 42
10.2.5 Work order completed in Maximo................................................................... 44
10.2.6 Work order closed in TRIRIGA ....................................................................... 46
10.2.7 Work orders manually closed in Maximo........................................................... 48
10.2.8 Work orders auto closed in Maximo ................................................................ 50
10.2.9 Work orders cancelled in TRIRIGA .................................................................. 52
10.2.10 Work orders cancelled in Maximo................................................................... 54
10.2.11 Corrective maintenance work order created in Maximo ....................................... 56
10.2.12 Other status change occurs in Maximo............................................................. 58
10.2.13 Reopen action occurs in TRIRIGA.................................................................... 59

Introduction
Al-Borj - Integration QA Test Plan v0.04.doc 1
1 INTRODUCTION
1.1 Purpose
This document outlines the objectives and activities for the project Quality Assurance (QA) testing process. The
purpose of this plan is to define the testing activities required to plan, prepare, and conduct testing of the project
for a client. It is intended for use by TRIRIGA implementation team in understanding and carrying out test
activities, evaluating the quality of test activities, and managing these activities through successful completion.
The plan is typically created once the Functional Design Document has been approved and the Development
Phase has commenced.
1.2 Audience
The intended audience for the QA Test Plan is comprised of Project Managers, Business Analysts, Technical
Leads, and client stakeholders involved in the testing and deployment of the application. It will also be used
by members of the project team who will be responsible for creating additional testing documentation for the
project.
1.3 Additional References/Resources
This Document references the following other documents:
Date Document Name
(Filename)
Definition

Overview
2 OVERVIEW
2.1 Project
Al-Borj has implement TRIRIGA’s solution to support Portfolio, Real Estate, and Operations and Maintenance.
Al-Borj is currently not using any other TRIRIGA modules.
2.2 Integrations Testing Overview

2.3 Roles and Responsibilities
This section describes the roles and responsibilities of the persons associated with this project.
2.3.1 IT Manager
The IT Manager has overall responsibility for the integrations. He has design approval authority, and will
participate in User Acceptance Testing.
2.3.2 Business Analyst (BA)
The Business Analyst prepares the test plan and test scripts, plus owns the traceability matrix. He will be an
active participant in the testing process.
2.3.3 Technical Leads (TL)
The Technical Leads are responsible for reviewing reported defects identified during testing and taking
corrective action themselves. They will also be active participants in the testing process.
2.3.4 eSolutions Lead
The eSolutions Lead is responsible for providing the Maximo portion of the solution as well as actively working
in the TRIRIGA side.
2.3.5 ISS Lead
The ISS Lead is responsible for providing Microsoft Axtapa portion of the solution.

3 TESTING DEFINITIONS
This section describes the specific phases and types of testing.
3.1 Phases of Testing
3.1.1 Unit Testing
Unit testing is used to validate the discrete functional modifications made by the various configuration
resources. Unit testing is conducted in an informal manner without the requirement for documentation.
Testing is conducted by developers and not end-users. A variety of tools can be used to support this process,
such as mock objects, reports or other specifically designed tools for the implementation.
3.1.2 Quality Assurance Testing (System Testing)
The System Test Phase is used to ensure that the functionality that was constructed meet the agreed upon
functional requirements. A test matrix is used to ensure full coverage of the requirements are tested during
this phase. Test Scripts provide the steps and user actions that must be performed by a tester in order to
complete system tasks and successfully complete application processes. Tests run during this cycle include
customer specific functionality as well as regression testing to existing areas affected by the configurations.
Each test script is given a score of ‘Pass’ if the system responds as expected, or ‘Fail’ if a defect is detected or
an unexpected system response occurs. The Functional Test Cycle is the most vital as it validates the system
as a whole to include the successful integration of interrelated functional areas and system modules.
Functional areas that have not been affected by project configurations/customizations are not tested during
this phase. Completion of this phase is a dependency to delivery of the best system for User Acceptance
Testing.
3.1.3 User Acceptance Testing
User Acceptance Testing (UAT) is the phase in which Al-Borj performs a series of tests to ensure that the
modifications meet the agreed upon functional requirements. UAT is the final stage of acceptance by the
client before deployment of the software implementation. User Acceptance can be conducted in various
forms using end users, Subject Matter Experts (SME), Test labs and automated systems, etc. The preference is
that the UAT test scripts are not constructed from System Test Phase test scripts in order to ensure an
independent review of the system. The goal of UAT is to test the system emulating real-world usage of the
system.
3.1.4 Deployment Testing (Smoke Testing)
This is the series of tests that are performed after the Production deployment activities have been completed
and before the system is certified for Production usage. The intent of this testing is to perform a
concentrated functional test ensuring that all functionality was properly deployed to the Production
environment. Also referred to as a “Smoke Test” the system is mildly stressed to ensure that the deployment
activities have not caused any defects and that the system is ready for use.

3.2 Types of Testing
Below is a definition of the various types of testing to be conducted to validate that the TRIRIGA system has
been configured to the agreed upon requirements in the Integration Design Document. These types of testing
can be done independently from each other or combined into common test scripts. The traceability matrix
ensures that all requirements have been validated through a combination of test scripts.
3.2.1 End to End Process (Scenario) Testing
This form of testing is geared to ensuring the end to end processes are working as designed and required by
the client. This test focuses more on the accuracy and flow of data rather than the graphical representation
of it. This may include testing of the defined process, state transition (actions), form validation, approval,
notifications and integrations as defined in the Functional Design Document.
3.2.2 Functional/Graphical Testing
This testing is focused on ensuring all screen modification, form validation, list/classification modifications,
contact roles have all been configured properly.
3.2.3 Security & License Testing
This testing is conducted to ensure that all security roles, license and Org/Geo security requirements are being
met.
3.2.4 Integrations Testing
This testing is conducted to ensure that the interface feeds, both inbound and outbound, are working
properly.
3.2.5 Performance Testing
This testing is to ensure that the configured solution meets any specific performance requirements identified
in the Functional Design Document.
3.2.6 Reliability Testing
Tests how well the software handles failures, data integrity, safety, and environment security.

3.3 Testing Documentation
3.3.1 Test Plan
This document outlines the objectives and activities for the project Quality Assurance (QA) testing process.
The purpose of this plan is to define the testing activities required to plan, prepare, and conduct testing of the
project for a client. It is intended for use by IT team in understanding and carrying out test activities,
evaluating the quality of test activities, and managing these activities through successful completion. The
plan is typically created once the Functional Design Document has been approved and the Development Phase
has commenced.
3.3.2 Traceability Matrix
This document is intended to map the detailed requirements from the Functional Design Document (FDD) into
a test matrix to ensure that all requirements are tracked and are being tested in a test script. At the
conclusion of testing the Traceability Matrix should be completed to ensure all functional areas have been
tested properly. This document is in a one page excel format.
3.3.3 Test Scripts
Test Scripts are intended to provide a detailed walk through of specific system use cases that cover one or
many requirements. The Traceability Matrix tracks the specific requirements from the FDD that are included
in a Test Script. Each Test Script steps through specific process and each step is tracked as a Pass/Fail. Any
step that fails is escalated through the QA process for evaluation and resolution.
3.3.4 Testing Tools
No automated testing or tracking tools will be used.

4 DEFECT REPORTING
All discrepancies, deficiencies, or other anomalies observed during testing are documented, tracked, and
resolved in accordance with IT teams defect-reporting procedures. Defects are situations in testing when the
expected result does not equal the actual result of the test.
Defects are defined as the inability to meet the specifications defined by the requirements documented in the
approved Functional Design Document. The Business Analyst records the defects in the defect log. The
Technical Leads are responsible for analyzing and correcting the defect. Each defect is assigned a priority
that is used by the Technical Leads to determine the repair order of the open defects.
The established severity levels for this project for defect reporting are as follows:
1 = Critical
Testing cannot continue and the execution of the current test cannot proceed unless this
incident is corrected. No effective workaround exists, and if not corrected the incident
would have a significant impact to the testing schedule.
2 = High
Incidents that do not prevent the current test from continuing, but must be resolved before
the next pass. The current pass can be implemented with a workaround in place, but to
enable the goals of testing to be met, the incident must be corrected.
3 = Medium
Incidents that require fixing prior to regression test. These incidents identify changes that
would provide a benefit, but due to risk or time constraints, must be made at a later date.
4 = Low
Incidents that do not have any negative impact on the goals of testing or on production.
 Enhancements are defined as a requirement that is not included in the approved Functional
Design Document.
 Platform are defined as issues in the core platform and must be addressed by IBM.

Testing Entrance and Exit Criteria
5 TESTING ENTRANCE AND EXIT CRITERIA
Entrance criteria are a minimum set of items that must be in place before a particular project testing phase can be considered ready to start. Exit criteria are a minimum
set of items that must be in place before a particular project testing phase can be considered finished.
Testing Phase Entrance Criteria Exit Criteria Next Testing Phase
Unit Testing  Development Test environment is ready
 Unit Tests have been created
 Code is testable
 All scheduled unit and assembly tests have been executed to
completion.
 Analysis of unit test results indicates that the configured
software meets the functional requirements.
 There are no open defects with a 1 or 2 level of severity.
 The Business Analyst and Technical Leads have reviewed all
outstanding defect reports and agree that none are serious
enough to delay the start of the next phase of testing.
Functional Testing
Quality Assurance
(System)Testing
 The test environment is complete.
 The test system configuration (hardware,
software, etc.) is available for testing.
 Test User IDs and Passwords have been set-
up.
 The test plan has been published, reviewed
and finalized.
 The scripts, procedures and test data
required to execute the tests defined in the
test plan are complete and have been
reviewed.
 The test team is familiar with the materials
needed to execute tests and is available to
begin testing.
 Resources have been identified and
confirmed.
 Test execution and analysis activities are complete.
 All scripts have been executed to completion.
 Analysis of test results indicates that the system meets the
requirements set forth in the Functional Design Document.
 There are no open defects with a 1, 2 or 3 level of severity.
 The Business Analyst and Technical Leads have reviewed all
outstanding defect reports and agree that none are serious
enough to delay the delivery of software to the client.
User Acceptance
Testing
User Acceptance
Testing
 UAT environment is ready
 QA Testing has met their exit criteria
 100% of all ‘must run’ and business impacted ‘should run’
test cases have been executed
 No Priority 1, 2 or 3 defects
 All priority 4 defects will be reviewed by the management
team to determine what would or would not be allowed into
production
 The final release will require that 100% of Priority 1,2 and 3
defects are resolved unless the business agrees to accept
what defects remain.
Production

UAT Integrations
Testing
 UAT environment is ready
 QA Integrations Testing has met their exit
criteria
 100% of all ‘must run’ and business impacted ‘should run’
test cases have been executed
 No Priority 1, 2 or 3 defects
 All priority 4 defects will be reviewed by the management
team to determine what would or would not be allowed into
production
 The final release will require that 100% of Priority 1,2 and 3
defects are resolved unless the business agrees to accept
what defects remain.
Production

Reviews and Reporting
6 REVIEWS AND REPORTING
The status and progress of the Project test activities are evaluated by conducting formal and informal reviews
and by reporting progress and statuses against major and intermediate milestones within the project plan.
Reviews
Test documents and other test materials are reviewed during preparation and updated to correct deficiencies.
All test materials are validated for completeness and accuracy prior to use for testing.
Reporting
Progress and statuses of test activities are reported to the IT Manager throughout the critical stages of testing.

7 SCOPE OF TESTING
7.1 In Scope
 TRIRIGA to Microsoft AX
 TRIRIGA to Maximo
7.2 Out Scope
 All functionality not related to the in scope items.

8 TEST SCENARIOS
This section defines the high level use cases required to test the majority of functionality. The intent is to
define a series of scenarios that touch on all functional areas and ensure end to end testing with a
combination of Test Scripts.
8.1 TRIRIGA/AX Integration
8.1.1 New Tenants in TRIRIGA to AX
A new tenant record is going to be created in TRIRIGA, and the integration should pick it up and send to AX.
8.1.2 New Tenants in AX to TRIRIGA
A new tenant record is going to be created in AX, and the integration should pick it up and send to TRIRIGA.
8.1.3 Changes made to TRIRIGA tenant record and sent to AX
Changes are made to the tenant information (e.g. Address) in TRIRIGA and are sent to AX.
8.1.4 Changes made to AX tenant record and sent to TRIRIGA
Changes are made to the tenant information (e.g. Address) in AX and are sent to TRIRIGA.
8.1.5 RE Invoices created in TRIRIGA and sent to AX
The invoice process is run, and PLI’s should go to AX as sales line items.
8.1.6 RE Invoices modified in TRIRIGA and updates sent to AX
Changes made to an RE Invoice record are sent to AX.
8.1.7 RE Invoices cancelled in TRIRIGA
An RE Invoice is cancelled in TRIRIGA and reflected in AX.
8.1.8 Changes made to Sales Line Items in Ax and sent to TRIRIGA
This is to test for what is not supposed to ever happen: changes are made to the sales invoice in AX that could
impact TRIRIGA.
8.1.9 Payment applied in AX and sent to TRIRIGA
A payment processed in AX should be reflected against the PLI’s in TRIRIGA.
8.2 TRIRIGA/Maximo Integration
8.2.1 New work orders created in TRIRIGA
A work request is created in TRIRIGA which results in a new work order being created, and that goes to
Maximo.
8.2.2 Maximo PM work orders sent to TRIRIGA
When the PM work orders are generated in Maximo weekly, they should be sent to TRIRIGA.
8.2.3 Priority changes in TRIRIGA and sent to Maximo
If the priority on a work order is changed in TRIRIGA, the SLA information changes and must go to Maximo.
8.2.4 Work order completed in TRIRIGA
A work order is completed in TRIRIGA which must be reflected in Maximo.
8.2.5 Work order completed in Maximo

A work order is completed in Maximo and must be accurately reflected in TRIRIGA.
8.2.6 Work order closed in TRIRIGA
A work order is closed in TRIRIGA and the Maximo status must change as well.
8.2.7 Work orders manually closed in Maximo
A work order is manually closed in Maximo (which by process shouldn’t happen) and is reflected in TRIRIGA
8.2.8 Work orders auto closed in Maximo
Work orders that have been completed in Maximo but not closed within 2 days are auto closed. TRIRIGA
should reflect the auto closure.
8.2.9 Work orders cancelled in TRIRIGA
A work order is cancelled in TRIRIGA and should be cancelled in Maximo as well.
8.2.10 Work orders cancelled in Maximo
A work order is cancelled in Maximo (not supposed to happen) and must be reflected in TRIRIGA.
8.2.11 Corrective maintenance work order created in Maximo
A new corrective maintenance work order is entered in Maximo and should also be in TRIRIGA.
8.2.12 Other status change occurs in Maximo

Traceability Matrix
9 TRACEABILITY MATRIX
ID Test Script
(P)ass /
(F)ail
Last Test
Date
8.1 TRIRIGA / AX Integration
8.1.1 New tenants in TRIRIGA to AX P 25/6/14
8.1.2 New tenants in AX to TRIRIGA P 25/6/14
8.1.3
Changes made to TRIRIGA tenant record and
updated in AX F 25/6/14
8.1.4
Changes made to AX tenant record and updated in
TRIRIGA P 25/6/14
8.1.5 RE Invoices created in TRIRIGA and sent to AX F 23/6/14
8.1.6
RE Invoices modified in TRIRIGA and updates sent
to AX
8.1.7 RE Invoices cancelled in TRIRIGA
8.1.8
Changes made to Sales Line Items in AX and sent
to TRIRIGA
8.2 TRIRIGA / Maximo Integration
8.2.6 Work Order closed In TRIRIGA

8.2.8 Word orders auto closed in Maximo
8.2.11
Corrective maintenance work order created in
Maximo

Test Scripts
10 TEST SCRIPTS
10.1TRIRIGA / AX Integration

10.1.1 New Tenants in TRIRIGA to AX
Test Record ID: 8.1.1
Test Script Name: New Tenants in TRIRIGA to AX
Test Script Objective/Scenario: Create a new tenant in the organization hierarchy and have it appear in AX.
Tested Requirements/Verifications: Verify the tenant record appears as a customer in AX once the integration runs.
Additional Information: This script has positive and negative scenarios. The negative scenario is meant to force a
failure to happen.
Test Author: Tracy Jefferson
Test Script Setup
Actors Finance, Integration
Pre-State (1) Integration between TRIRIGA and AX is actively monitoring for new records.
Post-State A new customer record exists in AX.
Possible Exceptions Conflict in account number could cause a failure.
Step(s) Data Entry/ Notes Expected Result Actual
Result
(Pass/Fail)
1 Login to TRIRIGA as someone from Finance or
an Administrator.
Portal appears. Pass
2 Select Portfolio, and then Organization
Hierarchy.
Org hierarchy is visible. Pass
3 Locate the branch called “Tenants”, click on
it, then select “New” followed by
“Tenants.”
Empty Tenant form appears. Pass
4 Fill in the required fields plus address
information. When complete, select the
“Activate” action.
It is important that all fields expected
to appear in Microsoft AX be filled in to
fully validate the integration.
An active record exists in
TRIRIGA that is ready for
transmission to AX.
Pass

5 Once the integration has run, login to
Microsoft AX.
Portal appears. Pass
6 Navigate to the customer records, and
search for the record that was created first
in TRIRGA.
Confirm all fields from TRIRIGA now
exist in AX.
All data should correctly appear. Pass
ALTERNATIVE 1: Negative Test
1 Login to AX. Portal appears. Pass
2 Navigate to the customer records, and add a
new record using minimal information.
Note the account number assigned. Customer form.
3 Login to TRIRIGA as someone from Finance or
an Administrator.
Portal appears.
4 Select Portfolio, and then Organization
Hierarchy.
Org hierarchy is visible.
5 Locate the branch called “Tenants”, click on
it, then select “New” followed by
“Tenants.”
Empty Tenant form appears.
6 Fill in the required fields plus address
information. When complete, select the
“Activate” action. Force the TRIRIGA
account number to be the same as was
already created in AX but use different
address information.
An active record exists in
TRIRIGA that is ready for
transmission to AX.
7 Once the integration has run, login to
Microsoft AX. Confirm the record was not
created as a duplicate.
8 Confirm an error resulted from the TRIRIGA
integration.
Test Script Conducted By: Overall Test Result
Pass
Test Script Executed Date:
Test Script Comments:

10.1.2 New Tenants in AX to TRIRIGA
Test Script Name: New Tenants in AX to TRIRIGA
Test Script Objective/Scenario: Create a new Tenant in AX and have it appear in the TRIRIGA organizational hierarchy.
Tested Requirements/Verifications: Verify the tenant record appears as a customer in TRIRIGA once the integration runs.
Additional Information:
Test Author: Chris Pittman/Omar Al Salahi
Test Script Setup
Pre-State (1) Integration between AX and TRIRIGA is actively monitoring for new records.
Post-State A new customer record exists in TRIRIGA.
Possible Exceptions Conflict in account number could cause a failure.
Result
(Pass/Fail)
1 Finance logs into AX Pass
2 Finance selects accounts receivable Pass
3 Finance selects “All Customers” Pass
4 Finance selects Create New Customer Pass
Fill in Name and Customer Group Pass

Integration runs Pass
Finance logs into TRIRIGA Pass
Finance locates new tenants Validates that all data appears
and is correct
Pass
Pass

10.1.3 Changes made to TRIRIGA tenant record and updated in AX
Test Script Name: Changes made to TRIRIGA tenant record and updated in AX
Test Script Objective/Scenario: Make a change in TRIRIGA to a tenant record and have it updated in AX.
Tested Requirements/Verifications: Verify that the update to a tenant record in TRIRIGA is updated in the AX system.
Test Script Setup
Post-State The record should be updated with the new information.
Possible Exceptions
Result
(Pass/Fail)
1 Finance logs into TRIRIGA Portal appears Pass
2 Finance locates tenant records to be
updated
Pass
3 Integration runs
4 Finance logs into AX

5 Finance locates updated tenant records Validates that updated
information matches
Pending

10.1.4 Changes made to AX tenant record and updated in TRIRIGA
Test Script Name: Changes made to AX tenant record and updated in TRIRIGA
Test Script Objective/Scenario: Create a change to a tenant record in AX and have it update to TRIRIGA.
Tested Requirements/Verifications: Verify that a change to a tenant record in AX and check to see if it updates into the TRIRIGA
system.
Test Script Setup
Post-State Changes made to the record should be updated in TRIRIGA.
Possible Exceptions
Result
(Pass/Fail)
1 Finance logs into AX Pass
2 Finance selects Accounts Receivable Pass
3 Finance will select needed customer and
select Edit action
Pass
4 Integration runs Pass

Finance logs into TRIRIGA Portal opens
Finance locates updated tenant records Validates that all updated areas
are correct
Pass

10.1.5 RE Invoices created in TRIRIGA and sent to AX
Test Script Name: RE Invoices created in TRIRIGA and sent to AX
Test Script Objective/Scenario: Created RE Invoices in TRIRIGA should be sent to AX.
Tested Requirements/Verifications: Verify that RE Invoices are being seen in AX
Test Script Setup
Post-State
Possible Exceptions
Result
(Pass/Fail)
1 Finance logs into TRIRIGA Home portal appears
2 Select the Contracts portal Contract portal appears
3 Select the Receivables tab Receivables options appear
4 Select the Generate Lease Invoices option

5 Create new invoice process using the Add
action
6 Fill in required information in the general
tab.
7 Find the leases to associate to the invoice
process.
8 Select the Run Process action.
9 Activate the lease invoice records to be
passed to AX for billing
10 Issue the record.
11 Integration runs
12 Finance logs into AX and selects Accounts
Receivable then select All Sales Orders
13 Verifies sales orders were created from
TRIRIGA RE Invoices.
For every TRIRIGA RE Invoice
there should be an AX Sales
Order, and for every TRIRIGA to
be processed line item there
should be a sales order line
item.
Fail

10.1.6 RE Invoices modified in TRIRIGA and updates sent to AX
Test Script Name: RE Invoices modified in TRIRIGA and updates sent to AX
Test Script Objective/Scenario: RE Invoices will be modified in TRIRIGA and updated in AX
Tested Requirements/Verifications: Verify after RE Invoices are modified in TRIRIGA to check AX and see if it updated.
Test Script Setup
Post-State
Possible Exceptions
Result
(Pass/Fail)

5 Opens existing invoice process record that
contains the invoice needing modification
6 Activate the lease invoice records to be
passed to AX for billing
7 Issue the record.
8 Integration runs
10 Verifies sales orders were created from
TRIRIGA RE Invoices.
For every TRIRIGA RE Invoice
there should be an AX Sales
Order, and for every TRIRIGA to
be processed line item there
should be a sales order line
item.
Pending

10.1.7 RE Invoices voided in TRIRIGA
Test Script Name: RE Invoices voided in TRIRIGA
Test Script Objective/Scenario: RE Invoice that has been voided in TRIRIGA is handled properly in AX as well.
Tested Requirements/Verifications: Validate that the cancelation in TRIRIGA is updated to AX.
Test Script Setup
Post-State
Possible Exceptions
Result
(Pass/Fail)

contains the invoice needing to be voided
6 Void the record
7 Integration runs
9 Verifies sales orders were voided.
Pending

10.1.8 Changes made to Sales Line items in AX and sent to TRIRIGA
Test Script Name: Changes made to Sales Line items in AX and sent to TRIRIGA
Test Script Objective/Scenario:
Tested Requirements/Verifications:
Test Script Setup
Post-State
Possible Exceptions
Result
(Pass/Fail)
1 Log into AX
2 Locate sales order
3 Make changes to sales lines They are not allowed to
Pending

Test Script Name: Payment applied in AX and sent to TRIRIGA
Test Script Objective/Scenario: Payment received by AX and updated in TRIRIGA.
Tested Requirements/Verifications: Verify that the payment has moved to Payment – Processed in TRIRIGA
Test Script Setup
Post-State
Possible Exceptions
Result
(Pass/Fail)
Receivable
2 Select Payment Journal
3 Select New action

4 Enter Customer Payment
5 Fill in all information plus amount
6 Select the Customer
7 Select all needed invoices to settle and
then select Save in Journal
8 Select Post action
9 Integration runs
contains the invoice needing to be checked
15 Checks that the payment has moved from
Contract Payments – To Process down to
Payment - Processed
Pending

10.2TRIRIGA / Maximo Integration
Test Script Name: New work orders created in TRIRIGA
Test Script Objective/Scenario: Create a new work order in TRIRIGA and uploaded in Maximo
Tested Requirements/Verifications: Verify after the new work order is created that it is visible in Maximo.
Test Author: Chris Pittman
Test Script Setup
Actors Requestor, Integrations, SSCL, Service Manager
Pre-State (1) Integration between Maximo and TRIRIGA is actively monitoring for new records.
Post-State Work orders should be showing up in the Maximo system.
Possible Exceptions
Result
(Pass/Fail)
1 In Request Central select type of request for
the testing.
Request form will open.
2 In the Service Request section select
appropriate problem.
3 In the Describe Your Request section type in
“This is a test!”.

4 Select the Submit action. Will submit the request for
integration to process.
5 TRIRIGA creates and activates work order.
6 Service Manager assigns work order to SSCL
7 Integrations runs
8 Maximo user locates work order Maximo user sees work order in
system and validates it matches
with TRIRIGA
Pending

Test Script Name: Maximo PM work orders sent to TRIRIGA
Test Script Objective/Scenario: Maximo PM work orders are sent to the TRIRIGA system.
Tested Requirements/Verifications: Verify Maximo PM work orders are sent to the TRIRIGA system through integrations.
Test Script Setup
Post-State
Possible Exceptions
Result
(Pass/Fail)
1 SSCL user creates PM work orders
2 Integrations runs
3 TRIRIGA Service Manager confirms that PM
work orders are created
Service Manager confirms that
uploaded PM work orders match
with Maximo system

Pending

Test Script Name: Priority changes in TRIRIGA and sent to Maximo
Test Script Objective/Scenario: Create a priority change with a work order
Tested Requirements/Verifications: Verify that the priority change show up on the work order in Maximo
Test Script Setup
Post-State
Possible Exceptions
Result
(Pass/Fail)
1 Service Manager logs into TRIRIGA.
2 Service Manager creates test work order in
TRIRIGA
3 Integrations runs

4 Service manager confirms the work order
was created in Maximo.
5 Service Manager changes work order
priority in TRIRIGA
6 Integrations runs
7 SSCL checks work order priority and SLA SSCL confirms that priority and
SLA changed in Maximo
Pending

Test Script Name: Work order completed in TRIRIGA
Test Script Objective/Scenario: Complete work order in TRIRIGA and have it update work order in Maximo
Tested Requirements/Verifications: Validate that the status of the work order in Maximo changes when the TRIRIGA work order
is completed
Test Script Setup
Post-State Work order status should change to completed in Maximo
Possible Exceptions
Result
(Pass/Fail)
1 Service Manager logs into TRIRIGA
2 Service Manager opens active work order
3 Service Manager selects the Completed
action
4 Integrations runs

5 SSCL checks work order status SSCL should see the updated
status stating Completed
Pending

Test Script Name: Work order completed in Maximo
Test Script Objective/Scenario: Create and complete a work order in Maximo
Tested Requirements/Verifications: Validate that a work order is updated to complete in the TRIRIGA system.
Test Script Setup
Post-State
Possible Exceptions
Result
(Pass/Fail)
1 SSCL opens active work order
2 SSCL selects the Completed action
3 Integrations runs
4 Service Manager opens work order

5 Service Manager checks updated work order
status
Work order should be updated to
Complete status
Pending

10.2.6 Work order closed in TRIRIGA
Test Script Name: Work order closed in TRIRIGA
Test Script Objective/Scenario: Create and close a work order in TRIRIGA and have it update in Maximo
Tested Requirements/Verifications: Validate that integrations sets the work order status to closed in Maximo.
Test Script Setup
Post-State
Possible Exceptions
Result
(Pass/Fail)
2 Service Manager opens Completed work
order
3 Service Manager selects the Close action
4 Integration runs

5 SSCL locates Closed work order SSCL verifies with Service
Manager that status is Closed
Pending

Test Script Name: Work orders manually closed in Maximo
Test Script Objective/Scenario: Create and close a work order in Maximo
Tested Requirements/Verifications: Identify work orders that are manually closed in Maximo
Test Script Setup
Post-State
Possible Exceptions
Result
(Pass/Fail)
1 SSCL manually closes a work order
2 Integration runs
3 Service Manager identifies manually closed
work orders
Portal or query should list all
work orders closed manually.

Pending

10.2.8 Work orders auto closed in Maximo
Test Script Name: Work orders auto closed in Maximo
Test Script Objective/Scenario: Have work orders auto close in Maximo and identify them
Tested Requirements/Verifications: Identify which work orders were auto closed in Maximo
Test Script Setup
Post-State
Possible Exceptions
Result
(Pass/Fail)
1 Maximo auto closes work orders
2 Integration runs
3 Service Manager logs in

Service Manager identifies auto close work
orders
Takes action with his team to
prevent this type of occurrence.
4 KPI runs and identifies auto closed work
orders
Management takes appropriate
actions.
Pending

Test Script Name: Work orders cancelled in TRIRIGA
Test Script Objective/Scenario: Cancel a work order in TRIRIGA
Tested Requirements/Verifications: Validate that work order status is changed to cancelled in Maximo
Test Script Setup
Post-State
Possible Exceptions
Result
(Pass/Fail)
2 Service Manager locates work order
3 Service Manager opens work order and
selects the Cancel action
4 Integration runs

5 SSCL locates and opens work order
6 SSCL checks on work order status SSCL validates with Service
Manager that the work order
status is set to Canceled
Pending

Test Script Name: Work orders cancelled in Maximo
Test Script Objective/Scenario: Cancel a work order in Maximo
Tested Requirements/Verifications: Identify work orders that are cancelled in Maximo
Test Script Setup
Post-State
Possible Exceptions
Result
(Pass/Fail)
1 SSCL opens work order
2 SSCL Cancels work order
3 Integration runs
4 Service Manager logs in and identifies Sees Canceled work orders and

Canceled work orders takes appropriate action.
Pending

10.2.11 Corrective maintenance work order created in Maximo
Test Script Name: Corrective maintenance work order created in Maximo
Test Script Objective/Scenario: Create corrective maintenance work order in Maximo and have integrations upload into
TRIRIGA
Tested Requirements/Verifications: Validate that corrective maintenance work orders are shown in TRIRIGA
Test Script Setup
Post-State
Possible Exceptions
Result
(Pass/Fail)
1 SSCL creates corrective maintenance work
order
2 Integration runs

4 Service Manager opens unassigned work
order
Service Manager verifies with
SSCL that work orders are
visible.
5 Service Manager assigns to appropriate party
6 Integration runs
7 SSCL sees work order is assigned to them
Pending

Test Script Name: Other status change occurs in Maximo
Test Script Objective/Scenario: Change status on work order in Maximo and have integration update in TRIRIGA
Tested Requirements/Verifications: Validate that status changes in Maximo are being updated in TRIRIGA
Test Script Setup
Post-State
Possible Exceptions
Result
(Pass/Fail)
1 SSCL makes status change to work order
2 Integration runs
4 Service Manager locates and opens work Service Manager validates with

order SSCL that status has changed
Pending
10.2.13 Reopen action occurs in TRIRIGA
Test Script Name: Reopen action occurs in TRIRIGA
Test Script Objective/Scenario: Reopen a completed work order in TRIRIGA and have it update in Maximo
Tested Requirements/Verifications: Validate that the work order Reopens in Maximo
Test Script Setup
Actors Integrations, SSCL, Service Manager
Post-State

Possible Exceptions
Result
(Pass/Fail)
2 Service Manager Reopens a completed work
order in TRIRIGA
3 Integration runs
4 SSCL logs into system
5 SSCL locates Reopened work order SSCL confirms with Service
Manager that the work order has
Reopened
6 SSCL completes work order again
Pending

Al-Borj - Integration QA Test Plan v0.04

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (19)

Similar to Al-Borj - Integration QA Test Plan v0.04

Similar to Al-Borj - Integration QA Test Plan v0.04 (20)

Al-Borj - Integration QA Test Plan v0.04