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 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


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 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


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.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





Test Scripts


10 TEST SCRIPTS

10.1 TRIRIGA / 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.


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





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


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

Test Script Conducted By: Overall Test Result 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


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





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


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.

Test Script Conducted By: Overall Test Result Fail






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








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.





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








5 Opens existing invoice process record that contains the invoice needing to be voided

6 Void the record

7 Integration runs


9 Verifies sales orders were voided.





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


1 Log into AX

2 Locate sales order

3 Make changes to sales lines They are not allowed to





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


1 Finance logs into AX and selects Accounts 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






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





10.2 TRIRIGA / 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


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







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


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




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


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







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


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







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


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





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



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







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


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.


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


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.







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



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







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


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.







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


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







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


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




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



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




al-borj - integration qa test plan v0.04

Documents

testing definitions

phases of testing

unit testing

types of testing

functionalgraphical

integrations testing

user acceptance testing

security license testing