DI 5.3 16:15 – 17:15 INTEGRATIONSCHAOS? TROTZ UNIT · PDF file(Mainframe, ERM, ) ... Different behaviour then the used mock/simulator for development ... Wide range of test data

DI 5.316:15 – 17:15

INTEGRATIONSCHAOS? TROTZ UNIT-TESTS UND AUFWENDIGER GUI-TESTS?Schnittstellenorientierung im Softwaredesign ist längst state of the art - gerade dann, wenn die neue oder geänderte Anwendung in eine komplexe Unternehmens-IT integriert werden und mit vielen anderen Anwendungen zusammen spielen muss. Doch warum kommt es immer wieder zu ausuferenden Integrationsphasen, wo Anwendungen schier nicht zusammen arbeiten wollen. Wo, wann und vor allem wie eine weitere Schnittstellenorientierung im Projekt die Integrationsaufwände und -risiken reduzieren und die Qualität steigern kann, zeigt diese interaktive Session.

Ludwig Ronny Eckardt (Diplom Informatiker) arbeitet als Software-Architekt und Berater bei der T-Systems Multimedia Solutions GmbH. Er verfügt über umfangreiche Erfahrungen als Anforderungsmanager, Software Architekt und Test Manager aus Projekten mit Geschäftsprozess- und Service-orientierten Unternehmensanwendungen.

© T-Systems Multimedia Solutions | Integrationschaos? Trotz Unit-Tests und aufwendiger GUI-Tests? | L.R. Eckardt | 2014

HINWEISE

Alle innerhalb der Präsentation genannten und gegebenenfalls durch Dritte geschützteMarken und Kennzeichen unterliegen den Bestimmungen des jeweils gültigenKennzeichenrechts und den Rechten der jeweiligen eingetragenen Eigentümer. DieVerwendung von Marken und Kennzeichen In dieser PDF dient lediglich zur Informationund gibt keine Auskunft über deren freien Verfügbarkeit.

Die in der Präsentation enthaltenen Fotos und Grafiken dürfen nicht unabhängig vondieser Präsentation und auch nicht einzeln verwendet werden.

Eine Veröffentlichung dieser Präsentation, auch auszugsweise, ist ohne ausdrücklicheGenehmigung des Autors Ludwig Ronny Eckardt nicht zulässig.

2


Integrationschaos? Trotz Unit-Tests und aufwendiger GUI-Tests?

T-SystemsMultimedia Solutions

Ludwig Ronny EckardtRequirements, Software Architecture, Quality Assurance

OOP 2014München


DIGITALE DIENSTE MIT LEIDENSCHAFTWIR SIND IHR PARTNER FÜR DIE ZUKUNFT IMDIGITALEN LEBENS- UND GESCHÄFTSRAUM

E-COMMERCE INTERNET PORTALE INTRANET PORTALE INNOVATIONEN WEB-IT MANAGEMENT


T-Systems Multimedia Solutions


ExampleeCommerce-Shop

Business Scenario: e-Commerce Web Shop

Customer uses e-Shop via Browser




Use cases requireinteraction of a lot of IT-systems



IT-Systems may be Complex

(Mainframe, ERM, … )

Consist of subcomponents


Use cases requireinteraction of a lot of IT-systems

Outside (B2B)(Payment ProviderOnline Marketing,Logistic/Tracking,…)



Backoffice-IT-systems have GUI for humans too

Outside Development Team: Recognition of IT-systems via GUI



Backoffice-IT-systems have GUI for humans too

Outside Development Team: Recognition of IT-systems via GUI

Let’s focus the interaction between IT-systems


Rough Development Process == illustrative ==QA-activities during test phases are part of everyone's process.

Test ProductionImplementationFunctional + Technical DesignRequirement

User Acceptance Test

System Integration Test

for each system

Integration

Unit Test

Unit Integration Test

System Test


Implementation and System Test of Web Shop

Execution of test cases

interaction of the IT-systems during tests

surrounding IT-systems must be integrated

BUT …

Tester

and


Consumer does not match to current version of the interface of provider: Provider reacts different then expected

Different then documented Incomplete Implementation of Provider-Side Wrong interpretation of the specification

(Different teams for consumer and provider-implementation) Different behaviour then the used mock/simulator for development Just sunshine scenarios work …

Infrastructure problems Security certificates do not match …

Non-functional problems Provider has performance issues, when adding more consumers

…

And if available …Integration nightmare


So what can we do about it ?


Specification of system-interface both sides have to be compliant

Early and complete Specification of System-Interfaces (1/2)

Essentially a Key Lock Principle

<<System Interface>>Order Mgmt Customer Mgmt

<<Consumer>> <<Provider>>

Functional Specification Technical Specification

Operation(s) - Business Functions

In- and Out-Parameters

Transferred Data Structures

Validation

Functional Exceptions

Functional Protocol (Interaction-Seq.)

Technical Protocol – transport

Technical Protocol – content format

Technical Exceptions

Non functional requirements Service Level Agreements

(Performance, Load, Support)

Security, …


Description – essential for business side

Early and complete Specification of System-Interfaces (2/2)

Customer MgmtOrder Mgmt<<Consumer>> <<Provider>>

Functional Specification Technical Specification

Path through infrastructure

Routing / Mediation / Transformation by Middleware

Basis settings in provider, …

Communication contract – essential for successful communication

! Both sides need to stand to the contract !


A lot of documentation !

Who cares about it ?

Formal Review of Documentation Artefacts simple checklist Alternative: fill-in form Alternative: customize your modelling tool (check for mandatory fields)

When? Early: start to review requirements Later: Specifications & Design-Models

HINT: Mind to build up a glossary – or better a domain model

Side-effects: consistence over all interfaces Find lacks of information and design EARLY Have complete information, when implementation and test start Important for Governance Information to fill the API/SOA-Service-Repository

Quality Assurance by fast and easyinterface-focused review of specification



Test the interfaces of each IT-System before integration

Test the functionality before integration with other systems

First test only independent functionality

GUI Tests

Interface Tests Direct test of the

<<system interface>> Interface-Test Suite replaces

the real system “Web Shop” (Test driver is <<consumer>>)

All known – our Unit Tests !?

<<System Interface>>

Web Shop

Payment Provider


Order Mgmt

Interface Test Suite

<<System under Test>><<User Interface>>

Tester


Unit Test – done by developers

System under Test

Unit Test Suite

Simulator A Simulator B


Synchronous unit tests but asynchronous in real integration

Simulator / Mocks Not available (yet) Has to be developed? Limited functionality

Test data Has to be created?

Unit Test – done by developersMore challenges in unit-testing

System under Test

Unit Test Suite

Simulator A Simulator B


Interface test –How to complement

the unit-test

Interface Test – done by specialized test teamUse a specialized Test Tool

Direct test of the system interface

Tests can address the GUI and the interface

Cover all matching test kinds

Easy creation of typical test case logic

Support for lots of different transport and content-technologies(HTTP/HTTPS,TCP/IP,JDBC,JMS (e.g., WebSphere, webMethods, Sonic, TIBCO), MQ,MTOM(XOP)/MIME/DIME attachments REST,SOAP,UDDI,WS-*,WS-Security,SAML,More/custom)

Integration in test management tools

Automation of tests with CI-Integration


Web Shop

Payment Provider


Order Mgmt


<<System under Test>>

<<User Interface>>



Project Phases Environments

DEV Development Environment

ST System Test Environment

UAT User Acceptance Test Environment

… environments for Teaching Show Cases

DEV

UATST


Implementation and System Test of Web Shop

Execution of test cases

interaction of the IT-systems during tests

surrounding IT-systems must be integrated

BUT …

and

Tester


Put each IT-System under Test (SuT) before integration in a sandbox.

Test the functionality before integration with other systems GUI Tests Interface Tests

First test only independent functionality

Interface-Test Suite replaces the real system “Web Shop” (driver is <<consumer>>)

If functionality needs other IT-systems Replace the real systems

Order Mgmt Simulator replaces real system “Order Mgmt” (simulator is <<provider>>)


Web Shop

Payment Provider

<System Interface>>

Order Mgmt


Order MgmtSimulator

<<System under Test>><<User Interface>>

Tester


31

SimulatorsLevels of functionality

Business logic - Dynamic, in real time computed responseWide range of test data – may be stored in data base

Ready compiled response depend on request

Static response – no mater what request

Perf

orm

ance

pro

files

Management of simulators(Release, Environment)



Remember: Test data is everywhere !

Web Shop

Payment Provider

Order Mgmt


Order MgmtSimulator

<<System under Test>>

Test data

Test data

Test data

Management needed

Across

Environments

Releases

Full reset of environment before start of test

Test data may be distributed by Interface Test Suite in Test Case Prepare Phase

<<User Interface>>


Used Tools for Interface Test and Simulator-Development

+ a set of self developed add-ons / helpers


Put it all together – save time, save costs, know the quality.


Did you recognize challenges of your projects?

T-Systems Multimedia Solutions GmbHAkkreditiertes Test and Integration Center Quality Assurance of System-Interfaces and SOA-Services

Ludwig Ronny EckardtRequirements Management, Software Architecture, Quality Assurance+49 351 2820 2162 (Phone)+49 175 269 13 38 (Mobile)[email protected]

http://www.t-systems-mms.com/TIC



E-COMMERCE INTERNET PORTALE INTRANET PORTALE INNOVATIONEN WEB-IT MANAGEMENT


T-Systems Multimedia Solutions


Documents

DI 5.3 16:15 – 17:15 INTEGRATIONSCHAOS? TROTZ UNIT · PDF file(Mainframe, ERM, ) ... Different behaviour then the used mock/simulator for development ... Wide range of test data