Approach to development in OTM projects

Anton Moiseev

Amsterdam, March 2014

Anastasia Goncharova

2

AGENDA

What is extension

Development problems

Solution elements

How we use it

3

DEVELOPMENT IN OTM PROJECTS

Standard functionality What customer wants

80%

20%

How we meet customers needs in OTM projects

Configuration&Setup

Extentions

4

TYPES OF EXTENSIONS

Printing forms Operational Reports

GUI changes Integration Automation agents, programs and PL\SQL procedures

ERP

5

EXTENTIONS DEVELOPMENT PROBLEMS

Manual transfer of extensions between environments

Manual testing without regressive testing Different people who develop, test and transfer

Probability of critical errors on production system

6

STARTING POINT

Business-critical system Minimum downtime allowed A lot of extensions in the

project Big project team A lot of new requirements

after go-live

7

WHY WE STARTED TO SOLVE THE PROBLEM

(BUSINESS PERSPECTIVE)

Probability of violation of the terms of the project Increase project costs Errors in extensions => Additional downtime of the system => Financial Losses

8

LIFE IS LIFE…

9

The main GOAL: Approach:

Using classical approaches in development

Solution Elements:

1. Environments 2. Releases 3. Automated process of collecting and installation 4. Automated process of testing

HOW WE SOLVED THE PROBLEM

Don’t break the production!

10

PROJECT ENVIRONMENTS

Development Unit testing of extensions Unit testing of setups

DEV TEST

Integration testing of business-processes

Testing builds Performance testing

PROD

Production

Updating the environment after successful release on PROD

Usually 1 per day update

11

RELEASES

Release includes: Settings and configuration

changes of the system Extensions

Question: System in production and users want more and more???

Answer: Use releases!

Using releases you can: Plan the timing and

cost of the project Predict downtime for

the system

12

AUTOMATED PROCESS OF COLLECTING AND

INSTALLATION: GENERAL INFORMATION

Solution developed by CROC using Python and PL\SQL internally named HARDCODER . Consist of 2 parts: Collecting module to create build from source OTM environment using

predefined list of objects Installation module to update objects on destination OTM environment

and create backup of previous version of objects

Collecting module Installation module

Configuration files

Source OTM Environment

Build

Destination OTM Environment

Backup

13

AUTOMATED PROCESS OF COLLECTING AND

INSTALLATION: WHAT IS BUILD

Predefined structure of directories with .sql, .xml, .xsl, .rtf, .jspx files and installation .bat scripts

14

AUTOMATED PROCESS OF COLLECTING AND

INSTALLATION: ADVANTAGES

Elimination of bugs in build process, especially then several iterations of release testing performed

Automatic system of collecting and installation ensures that testing is always performed with the same set of modified objects

Reduction of time and costs to create and install build

15

AUTOMATED PROCESS OF TESTING: GENERAL

INFORMATION

Test case (.json file)

Testing system based on Java

OTM

Web application

Selenium Hub

Selenium WebDriver 2

Selenium WebDriver 1

Selenium WebDriver N

Testing cluster Web Server

Testing report

16

AUTOMATED PROCESS OF TESTING: TEST CASE

Simple OTM action, for example: creating order release preparing data …

Consist of 2 elements Testing scenario (GUI actions

sequence) Data preparation (.json file)

Existing micro scenarios can be used during preparing new test cases

Can be positive (without expected error) or negative (expected error)

Micro scenario

Test case

17

AUTOMATED PROCESS OF TESTING:

CAPABILITIES

Regressive capabilities of testing How to be sure that new extension didn’t broke some of previous extension?

Data combinations covering How to be sure that new extension works correctly with all significant data combinations?

Preparing data for testing How to prepare new data set for testing quickly?

18

AUTOMATED PROCESS OF TESTING: WHEN TO

USE

Regressive testing and checking compatibility with previous extensions is needed

A lot of testing iterations

0

50

100

150

200

250

1 2 3 4 5 10 50 100 200

Cost of automatictesting

Cost of manual tesing

Cost of testing

Count of testing iterations

19

HOW WE USE IT: GENERAL APPROACH

Starting conditions business-critical system in production ongoing process of new requirements and bugs fixing Main steps 1. Collect requirements 2. Set priorities 3. Divide to releases 4. Define standard or non-standard functionality 5. Develop and setup 1-st Release 6. Get final build for the 1-st Release 7. Begin tests…

20

HOW WE USE IT: TEST RELEASE

Starting conditions DEV environment = PROD environment Release components are tested on DEV, at the first blush - everything is OK Test cases are created\corrected for new extensions Main steps 1. Create\update configuration file for the build. Run Collecting module on DEV. Creating

the build. 2. TEST environment updated from PROD 3. Manual setups on TEST (that are not in the build) 4. Create backup of TEST environment 5. Run Installation module for TEST (transfer build from DEV to TEST) 6. Automatically running of autotests (usually during the night). All new extensions are

tested in total. Regressive testing of old extensions is also performed 7. Testing report is automatically prepared 8. If no error – PROD can be updated. 9. In case of errors - TEST is restored from backup. Fixing extensions and maybe test

cases, go to step 1.

21

HOW WE USE IT: TRANSFER RELEASE

Starting conditions Release is tested on TEST environment, everything is OK Main steps 1. Run Collecting module on PROD. Create the build of previous version of extensions

(extensions backup).

2. In predefined time interval perform manual setups (that are not in the build) on PROD

3. Run Installation module for TEST (transfer build from TEST to PROD)

4. In case of errors - return back manual setups and run Installation module for the build with previous version of extensions.

22

WHAT WE GET

Minimizing risks of critical errors on PROD Reduced time of development and testing

for complex releases

23

PLANS TO UPGRADE

Automate the process of testing for end-to-end processes Automate the process of transferring changes in setups and

properties-files

Updating the records and objects according to rules

Fully automated system for release’s installation

24

DOCUMENTATION PROCCESS

MD.070 Application Extensions Technical

Design

All source codes and scripts of installation are storage in the version control system – TFS

MD.020 Application Extension Definition and

Estimates

MD.050 Application Extensions Functional

Design

26

Q&A