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