This presentation provides an introduction to the LISA testing tool, including its architecture, deployment, core concepts, and UI navigation. Key points covered include the four main parts of LISA (Test, Virtualize, Validate, Pathfinder), how it is typically deployed with a base server and other components, important concepts like projects, test steps, filters, assertions, and data sets, and how to navigate the LISA user interface. The presentation recommends asking questions and reviewing additional documentation and demo videos to fully understand how to use LISA for testing purposes.

2. Agenda
• Notes about this presentation
• Intro to LISA
• Components in LISA architecture
• How it is deployed
• Core Concepts of LISA
• UI Navigation within LISA
• Next Steps
• Resources

3. Notes about Presentation
• Lots of information
• Lots of spoken information
• Even though short – ask your questions
– Better served by rating quality over quantity
• Architecture is very important – because it changes the way we do things
• Take notes as appropriate – will save you time
• Augment this presentation by watching demo videos
• DO ask the question “We want to do ‘y’, how does LISA do it?”
• This presentation will NOT include information about Virtualization

4. Intro to LISA
• Lisa is an integrated SOA testing tool
• It tests L&P, UI, Web Services, EJB, JUnit, etc.
• iTKO – Interactive Technical knockout
• 4 Parts to LISA – Bought together or separate:
– LISA Test
– LISA Virtualize
– LISA Validate
– LISA Pathfinder
• Everything controlled by licenses –just one product
• The LISA tool is file based.

5. Components in LISA Architecture
• Test Manager UI: Is the program on your desktop that you will be working in most of the time
• Coordinator: Tells components what to do (test), collects metrics, writes results
• Simulator: Actually runs the test (1 to many users – L&P uses more. QA will only use 1)
• Registry: Sole job is to keep track of everything.
• Local Mode:
everything is on
your machine
• Server Mode:
Only Test
Manager is on
your machine.
Other 3
components are
on a shared box.

6. How LISA is deployed
Base Server
Virtual Server
Workstation
(Desktop)
Workstation
(Desktop)
Workstation
(Desktop)…………….
Coordinator
Server
Simulator Server
Registry Server
Results
Database

7. Core Concepts of LISA

8. Core Concepts of LISA
• Projects: The folder structure signifies
the entire project.
• It is divided into folders that represent
the various artifacts (testcases, suites,
data files, virtual services, etc.)
• Represented by a single project file in
the file system – but accompanied with
a folder structure.
• Only one project open at a time.

9. Core Concepts of LISA
• Test Step: Essentially are the ‘Do What’ of test cases
• Each test case can have multiple test steps
• Examples: Raw SOAP, jdbc, MQ, etc.
• Simply right click on the canvas and pick your step!
• Symbols help differentiate between various steps

10. Core Concepts of LISA
• On the Right are the various features of a
test step.
• Most are common for every test step.
Important ones are Filters, Assertions,
Log Message, Data Sets, Documentation
• The step information contains three key
pieces of information:
• Name: Name of the step
• Think time: Time to wait, range to wait, a
Delay
• Next: What step to execute next. Key to
forming workflows.
• After looking at the work flow since
everything is a block – every block/step
has a ‘RESPONSE’

11. Core Concepts of LISA
The core of each step is context
sensitive. The screens that
pop out from the right
change per the step.
To the right are examples of a
JDBC step (above) and a
WSDL Step
The best way to understand a
step is to:
– Go through the official
LISA Documentation
– Open it and look at the
options.
– There will an additional
document that goes
over key steps and
particular step details.

12. Core Concepts of LISA
• Filter: “gets what you want to look at”
• Since every test step has a response, we can feed that
response into a filter.
• The filter can parse data from XML, text files, SQL results,
create dates, etc.
• There are a myriad of filters for various purposes
• Filters do not VALIDATE anything. They SELECT things.
• Example:
• Web Service Step does NOT DO anything besides send request and
get response.
• The Filter actually goes into the response and then gets us back
• individual elements to “send to cache” or gets us the
• entire step response

13. Core Concepts of LISA
• Assertion: Actually “VALIDATE”
• Many kinds of assertions, but not as many as the kinds of
filters
• Golden Copy will typically how we use it: referred to as a
Graphical XML Side-by-Side Comparison (Graphical XML
Diff)
• Summary: The step feeds into a filter, which feeds into an
assertion.
• Note: If you are feeding the entire response of the test step into
an assertion, you can bypass the filter. Eg. in a web service step,
you want to validate the entire response, so we would feed the
response of the Web Service step into the Graphical XML Diff.

14. Core Concepts of LISA
• Data Set: Simply a
mechanism to read data
not contained in
individual test steps.
• The workflow diagram is above
• The various features of the data set are on the right
• Important step is the “At end” option. Choice to go
to next step or restart (picked only if another
terminator is present).
• Suggestion for Customer Data: All
Customer/Account data lives in files
• Pro: Tests can be shared with development or other
QA groups and even Dev groups

15. Core Concepts of LISA
• LISA Property: similar to the cache variables in Integra.
• Essentially they are variables within LISA.
• To reference a LISA property you simply include the variable name within
curly braces eg. {{name}}.
• The curly braces essentially mean: ‘value of’
• We can initialize PROPERTIES by:
{{num=3}} or {{name=“bob”}}
• We can also specify properties in a file in either key=value format or xml
format and use a particular filter to read them in.
• Very importantly, filters can be used to ‘slice and dice’ a TEST STEP’S
response to then push a portion (or element) of the response into a
PROPERTY.

16. Core Concepts of LISA
• Config Files: These files store various LISA properties.
• Typically used to indicate environment specific information.
• Eg. in OPS we would use QA1.config, QA2.config, QA6.cofig.
• Only 1 config file can be active at once.
• Typically every property in one config file will exist in every other
• In QA: all messages (projects) for the same service will have the
same properties.

17. Core Concepts of LISA
• Test Suites: collection of tests
• Add tests in many ways
• Run against a staging
document
• Pick the coordinator server by
default you want this run on
• In our case, probably Base
Server
• In the lower portion:
• Add tests, directories, other
suites, directory trees
• Serial Vs. Parallel – TBD
• Only regression suites will be LISA suites – not individual TCs
• OFFICIAL suite runs should be done when Registry points to base
server – This has to do with RESULTS STORAGE

18. Core Concepts of LISA
• Staging Document: Gives details
about how a test is to be run
• Keep in mind that some/many options
hail from a L&P POV
• Instances
• Cycles
• MAX Run Time
• Distribution Selection
• Simulator Spread
• Reports – will be saved in Results DB
• Metrics – typically for L&P, but
possibly useful for Web SVC testing

19. Core Concepts of LISA
• Reports: How you will be looking at test runs for
historical purposes
• You need to have Adobe Flash plug-in on your system
• Still in the nascent stages of usage
• The best way to go through this is with a demo, but
we will not since we have open questions with iTKO

20. UI Navigation within LISA

21. Resources
• www.itko.com
• Official LISA Documentation and User Guide
• Videos that show multiple smaller steps/scenarios
• Web SVC QA’s iTKO LISA Best Practices Documents
• support@itko.com
• Measure twice and cut once – if you are not sure about what
to do, please ask. It is twice as expensive to fix a mistake once
someone else finds it.

22. Questions