Al-Borj - Integration QA Test Plan v0.04
-
Upload
christopher-pittman -
Category
Documents
-
view
46 -
download
1
Transcript of Al-Borj - Integration QA Test Plan v0.04
Al-Borj - Integration QA Test Plan v0.04.doc ii
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.
Al-Borj - Integration QA Test Plan v0.04.doc iii
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
Al-Borj - Integration QA Test Plan v0.04.doc iv
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
Al-Borj - Integration QA Test Plan v0.04.doc 2
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
Al-Borj - Integration QA Test Plan v0.04.doc 3
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.
Al-Borj - Integration QA Test Plan v0.04.doc 4
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.
Al-Borj - Integration QA Test Plan v0.04.doc 5
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.
Al-Borj - Integration QA Test Plan v0.04.doc 6
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.
Al-Borj - Integration QA Test Plan v0.04.doc 7
4 DEFECT REPORTING All discrepancies, deficiencies, or other anomalies observed during testing are documented, tracked, and resolved in accordance with IT team\s 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
Al-Borj - Integration QA Test Plan v0.04.doc 8
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
Al-Borj - Integration QA Test Plan v0.04.doc 9
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
Al-Borj - Integration QA Test Plan v0.04.doc 10
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.
Al-Borj - Integration QA Test Plan v0.04.doc 11
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.
Al-Borj - Integration QA Test Plan v0.04.doc 12
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
Al-Borj - Integration QA Test Plan v0.04.doc 13
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
Al-Borj - Integration QA Test Plan v0.04.doc 14
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.1.9 Payment applied in AX and sent to TRIRIGA
8.2 TRIRIGA / Maximo Integration
8.2.1 New work orders created in TRIRIGA
8.2.2 Maximo PM work orders sent to TRIRIGA
8.2.3 Priority changes in TRIRIGA and sent to Maximo
8.2.4 Work order completed in TRIRIGA
8.2.5 Work order completed in Maximo
8.2.6 Work Order closed In TRIRIGA
8.2.7 Work orders manually closed in Maximo
Al-Borj - Integration QA Test Plan v0.04.doc 15
8.2.8 Word orders auto closed in Maximo
8.2.9 Work orders cancelled in TRIRIGA
8.2.10 Work orders cancelled in Maximo
8.2.11 Corrective maintenance work order created in Maximo
8.2.12 Other status change occurs in Maximo
Test Scripts
Al-Borj - Integration QA Test Plan v0.04.doc 16
10 TEST SCRIPTS
10.1 TRIRIGA / AX Integration
Al-Borj - Integration QA Test Plan v0.04.doc 17
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
Al-Borj - Integration QA Test Plan v0.04.doc 18
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:
Al-Borj - Integration QA Test Plan v0.04.doc 19
10.1.2 New Tenants in AX to TRIRIGA
Test Record ID: 8.1.2
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
Actors Finance, Integration
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.
Step(s) Data Entry/ Notes Expected Result Actual 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
Al-Borj - Integration QA Test Plan v0.04.doc 20
Integration runs Pass
Finance logs into TRIRIGA Pass
Finance locates new tenants Validates that all data appears and is correct
Pass
Test Script Conducted By: Overall Test Result Pass
Test Script Executed Date:
Test Script Comments:
Al-Borj - Integration QA Test Plan v0.04.doc 21
10.1.3 Changes made to TRIRIGA tenant record and updated in AX
Test Record ID: 8.1.3
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.
Additional Information:
Test Author: Chris Pittman/Omar Al Salahi
Test Script Setup
Actors Finance, Integration
Pre-State (1) Integration between AX and TRIRIGA is actively monitoring for new records.
Post-State The record should be updated with the new information.
Possible Exceptions
Step(s) Data Entry/ Notes Expected Result Actual 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
Al-Borj - Integration QA Test Plan v0.04.doc 22
5 Finance locates updated tenant records Validates that updated information matches
Test Script Conducted By: Overall Test Result Pending
Test Script Executed Date:
Test Script Comments:
Al-Borj - Integration QA Test Plan v0.04.doc 23
10.1.4 Changes made to AX tenant record and updated in TRIRIGA
Test Record ID: 8.1.4
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.
Additional Information:
Test Author: Chris Pittman/Omar Al Salahi
Test Script Setup
Actors Finance, Integration
Pre-State (1) Integration between AX and TRIRIGA is actively monitoring for new records.
Post-State Changes made to the record should be updated in TRIRIGA.
Possible Exceptions
Step(s) Data Entry/ Notes Expected Result Actual 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
Al-Borj - Integration QA Test Plan v0.04.doc 24
Finance logs into TRIRIGA Portal opens
Finance locates updated tenant records Validates that all updated areas are correct
Test Script Conducted By: Overall Test Result Pass
Test Script Executed Date:
Test Script Comments:
Al-Borj - Integration QA Test Plan v0.04.doc 25
10.1.5 RE Invoices created in TRIRIGA and sent to AX
Test Record ID: 8.1.5
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
Additional Information:
Test Author: Chris Pittman/Omar Al Salahi
Test Script Setup
Actors Finance, Integration
Pre-State (1) Integration between AX and TRIRIGA is actively monitoring for new records.
Post-State
Possible Exceptions
Step(s) Data Entry/ Notes Expected Result Actual 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
Al-Borj - Integration QA Test Plan v0.04.doc 26
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.
Test Script Conducted By: Overall Test Result Fail
Test Script Executed Date:
Test Script Comments:
Al-Borj - Integration QA Test Plan v0.04.doc 27
10.1.6 RE Invoices modified in TRIRIGA and updates sent to AX
Test Record ID: 8.1.6
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.
Additional Information:
Test Author: Chris Pittman/Omar Al Salahi
Test Script Setup
Actors Finance, Integration
Pre-State (1) Integration between AX and TRIRIGA is actively monitoring for new records.
Post-State
Possible Exceptions
Step(s) Data Entry/ Notes Expected Result Actual 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
Al-Borj - Integration QA Test Plan v0.04.doc 28
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
9 Finance logs into AX and selects Accounts Receivable then select All Sales Orders
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.
Test Script Conducted By: Overall Test Result Pending
Test Script Executed Date:
Test Script Comments:
Al-Borj - Integration QA Test Plan v0.04.doc 29
10.1.7 RE Invoices voided in TRIRIGA
Test Record ID: 8.1.7
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.
Additional Information:
Test Author: Chris Pittman/Omar Al Salahi
Test Script Setup
Actors Finance, Integration
Pre-State (1) Integration between AX and TRIRIGA is actively monitoring for new records.
Post-State
Possible Exceptions
Step(s) Data Entry/ Notes Expected Result Actual 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
Al-Borj - Integration QA Test Plan v0.04.doc 30
5 Opens existing invoice process record that contains the invoice needing to be voided
6 Void the record
7 Integration runs
8 Finance logs into AX and selects Accounts Receivable then select All Sales Orders
9 Verifies sales orders were voided.
Test Script Conducted By: Overall Test Result Pending
Test Script Executed Date:
Test Script Comments:
Al-Borj - Integration QA Test Plan v0.04.doc 31
10.1.8 Changes made to Sales Line items in AX and sent to TRIRIGA
Test Record ID: 8.1.8
Test Script Name: Changes made to Sales Line items in AX and sent to TRIRIGA
Test Script Objective/Scenario:
Tested Requirements/Verifications:
Additional Information:
Test Author: Chris Pittman/Omar Al Salahi
Test Script Setup
Actors Finance, Integration
Pre-State (1) Integration between AX and TRIRIGA is actively monitoring for new records.
Post-State
Possible Exceptions
Step(s) Data Entry/ Notes Expected Result Actual Result (Pass/Fail)
1 Log into AX
2 Locate sales order
3 Make changes to sales lines They are not allowed to
Test Script Conducted By: Overall Test Result Pending
Al-Borj - Integration QA Test Plan v0.04.doc 33
10.1.9 Payment applied in AX and sent to TRIRIGA
Test Record ID: 8.1.9
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
Additional Information:
Test Author: Chris Pittman/Omar Al Salahi
Test Script Setup
Actors Finance, Integration
Pre-State (1) Integration between AX and TRIRIGA is actively monitoring for new records.
Post-State
Possible Exceptions
Step(s) Data Entry/ Notes Expected Result Actual Result (Pass/Fail)
1 Finance logs into AX and selects Accounts Receivable
2 Select Payment Journal
3 Select New action
Al-Borj - Integration QA Test Plan v0.04.doc 34
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
10 Finance logs into TRIRIGA Home portal appears
11 Select the Contracts portal
Contract portal appears
12 Select the Receivables tab Receivables options appear
13 Select the Generate Lease Invoices option
14 Opens existing invoice process record that contains the invoice needing to be checked
15 Checks that the payment has moved from Contract Payments – To Process down to Payment - Processed
Test Script Conducted By: Overall Test Result Pending
Test Script Executed Date:
Test Script Comments:
Al-Borj - Integration QA Test Plan v0.04.doc 36
10.2 TRIRIGA / Maximo Integration
10.2.1 New work orders created in TRIRIGA
Test Record ID: 8.2.1
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.
Additional Information:
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
Step(s) Data Entry/ Notes Expected Result Actual 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!”.
Al-Borj - Integration QA Test Plan v0.04.doc 37
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
Test Script Conducted By: Overall Test Result Pending
Test Script Executed Date:
Test Script Comments:
Al-Borj - Integration QA Test Plan v0.04.doc 38
10.2.2 Maximo PM work orders sent to TRIRIGA
Test Record ID: 8.2.2
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.
Additional Information:
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
Possible Exceptions
Step(s) Data Entry/ Notes Expected Result Actual 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
Al-Borj - Integration QA Test Plan v0.04.doc 39
Test Script Conducted By: Overall Test Result Pending
Test Script Executed Date:
Test Script Comments:
Al-Borj - Integration QA Test Plan v0.04.doc 40
10.2.3 Priority changes in TRIRIGA and sent to Maximo
Test Record ID: 8.2.3
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
Additional Information:
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
Possible Exceptions
Step(s) Data Entry/ Notes Expected Result Actual Result (Pass/Fail)
1 Service Manager logs into TRIRIGA.
2 Service Manager creates test work order in TRIRIGA
3 Integrations runs
Al-Borj - Integration QA Test Plan v0.04.doc 41
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
Test Script Conducted By: Overall Test Result Pending
Test Script Executed Date:
Test Script Comments:
Al-Borj - Integration QA Test Plan v0.04.doc 42
10.2.4 Work order completed in TRIRIGA
Test Record ID: 8.2.4
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
Additional Information:
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 order status should change to completed in Maximo
Possible Exceptions
Step(s) Data Entry/ Notes Expected Result Actual 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
Al-Borj - Integration QA Test Plan v0.04.doc 43
5 SSCL checks work order status SSCL should see the updated status stating Completed
Test Script Conducted By: Overall Test Result Pending
Test Script Executed Date:
Test Script Comments:
Al-Borj - Integration QA Test Plan v0.04.doc 44
10.2.5 Work order completed in Maximo
Test Record ID: 8.2.5
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.
Additional Information:
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
Possible Exceptions
Step(s) Data Entry/ Notes Expected Result Actual Result (Pass/Fail)
1 SSCL opens active work order
2 SSCL selects the Completed action
3 Integrations runs
4 Service Manager opens work order
Al-Borj - Integration QA Test Plan v0.04.doc 45
5 Service Manager checks updated work order status
Work order should be updated to Complete status
Test Script Conducted By: Overall Test Result Pending
Test Script Executed Date:
Test Script Comments:
Al-Borj - Integration QA Test Plan v0.04.doc 46
10.2.6 Work order closed in TRIRIGA
Test Record ID: 8.2.6
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.
Additional Information:
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
Possible Exceptions
Step(s) Data Entry/ Notes Expected Result Actual Result (Pass/Fail)
1 Service Manager logs into TRIRIGA
2 Service Manager opens Completed work order
3 Service Manager selects the Close action
4 Integration runs
Al-Borj - Integration QA Test Plan v0.04.doc 47
5 SSCL locates Closed work order SSCL verifies with Service Manager that status is Closed
Test Script Conducted By: Overall Test Result Pending
Test Script Executed Date:
Test Script Comments:
Al-Borj - Integration QA Test Plan v0.04.doc 48
10.2.7 Work orders manually closed in Maximo
Test Record ID: 8.2.7
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
Additional Information:
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
Possible Exceptions
Step(s) Data Entry/ Notes Expected Result Actual 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.
Al-Borj - Integration QA Test Plan v0.04.doc 49
Test Script Conducted By: Overall Test Result Pending
Test Script Executed Date:
Test Script Comments:
Al-Borj - Integration QA Test Plan v0.04.doc 50
10.2.8 Work orders auto closed in Maximo
Test Record ID: 8.2.8
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
Additional Information:
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
Possible Exceptions
Step(s) Data Entry/ Notes Expected Result Actual Result (Pass/Fail)
1 Maximo auto closes work orders
2 Integration runs
3 Service Manager logs in
Al-Borj - Integration QA Test Plan v0.04.doc 51
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.
Test Script Conducted By: Overall Test Result Pending
Test Script Executed Date:
Test Script Comments:
Al-Borj - Integration QA Test Plan v0.04.doc 52
10.2.9 Work orders cancelled in TRIRIGA
Test Record ID: 8.2.9
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
Additional Information:
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
Possible Exceptions
Step(s) Data Entry/ Notes Expected Result Actual Result (Pass/Fail)
1 Service Manager logs into TRIRIGA
2 Service Manager locates work order
3 Service Manager opens work order and selects the Cancel action
4 Integration runs
Al-Borj - Integration QA Test Plan v0.04.doc 53
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
Test Script Conducted By: Overall Test Result Pending
Test Script Executed Date:
Test Script Comments:
Al-Borj - Integration QA Test Plan v0.04.doc 54
10.2.10 Work orders cancelled in Maximo
Test Record ID: 8.2.10
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
Additional Information:
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
Possible Exceptions
Step(s) Data Entry/ Notes Expected Result Actual 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
Al-Borj - Integration QA Test Plan v0.04.doc 55
Canceled work orders takes appropriate action.
Test Script Conducted By: Overall Test Result Pending
Test Script Executed Date:
Test Script Comments:
Al-Borj - Integration QA Test Plan v0.04.doc 56
10.2.11 Corrective maintenance work order created in Maximo
Test Record ID: 8.2.11
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
Additional Information:
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
Possible Exceptions
Step(s) Data Entry/ Notes Expected Result Actual Result (Pass/Fail)
1 SSCL creates corrective maintenance work order
2 Integration runs
3 Service Manager logs into TRIRIGA
Al-Borj - Integration QA Test Plan v0.04.doc 57
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
Test Script Conducted By: Overall Test Result Pending
Test Script Executed Date:
Test Script Comments:
Al-Borj - Integration QA Test Plan v0.04.doc 58
10.2.12 Other status change occurs in Maximo
Test Record ID: 8.2.12
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
Additional Information:
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
Possible Exceptions
Step(s) Data Entry/ Notes Expected Result Actual Result (Pass/Fail)
1 SSCL makes status change to work order
2 Integration runs
3 Service Manager logs into TRIRIGA
4 Service Manager locates and opens work Service Manager validates with
Al-Borj - Integration QA Test Plan v0.04.doc 59
order SSCL that status has changed
Test Script Conducted By: Overall Test Result Pending
Test Script Executed Date:
Test Script Comments:
10.2.13 Reopen action occurs in TRIRIGA
Test Record ID: 8.2.12
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
Additional Information:
Test Author: Chris Pittman
Test Script Setup
Actors Integrations, SSCL, Service Manager
Pre-State (1) Integration between Maximo and TRIRIGA is actively monitoring for new records.
Post-State
Al-Borj - Integration QA Test Plan v0.04.doc 60
Possible Exceptions
Step(s) Data Entry/ Notes Expected Result Actual Result (Pass/Fail)
1 Service Manager logs into TRIRIGA
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
Test Script Conducted By: Overall Test Result Pending
Test Script Executed Date:
Test Script Comments: