04/12/23 1

Object Oriented Test Design Strategy for Web Applications

Test Architecture for Constant Change

marekj@testr.us

04/12/23 2

Design to Eliminate defects

Every time Software slows the Business the Software has an identifiable and measurable defect.

With each defect Business User’s usefulness of the system diminishes. Defects introduce 'drag' which can be measured.

How do we Architecture Tests to Eliminate Defects and not simply Discover them?

04/12/23 3

Design for Constant Change

It seems that Requirement is whatever the Business User expects to be or to happen, either now or in the future. – that is correct!

It seems that Functional Requirements are never frozen. Customer demands change, avoids specific agreement on functionality. – that is correct !

How do we design Software Tests for Constant Change?

04/12/23 4

Distinguish Building Blocks of Test Architecture

Business Domain ModelUseCase Model

UserInterface ModelTestCase Model

04/12/23 5

What do we mean by Business Domain Model

People use Language

to engage in Business

and produce Results

04/12/23 6

To Engage and Move in Business

Construct the Map of the Abstract World* What concepts do people communicate with each

other to accomplish business?

Discover how to Navigate with Shared Vocabulary* What words do people use to convey business

meaning? * What are ways of speaking about ‘doing things’ and

producing results?

04/12/23 7

Meaning Making with Distinctions and Signifiers

What makes this ‘thing’ be this ‘thing’?* Semantics, Distinguishing: … a Customer is

someone who…? A Contract is a …. ?

What special words, semantic signifiers exist that reference events, things, and relationships between them?* When I say X I mean ‘this thing’. When I say Y I

mean ‘that thing’* First X then Y and Z in the end. If Y is before X then

Z can’t happen.

04/12/23 8

Business Domain Test Strategy

Business Domain Model suggests why and how it needs to be tested.

Discover and Reveal Business Value.* Distinguish behavioral and informational

attributes of business objects.

* Behavioral attributes drive business rules, constraints, test conditions.

* Informational attributes provide structure of existence.

04/12/23 9

Business Domain Test Metrics

TestCase design and TestCoverage criteria derive from the Business Domain Model.* How would you know a bug if saw it?

How do you describe a defect? how do you classify defects?

* How would you know business value if it existed? How do you describe ‘it works’?

04/12/23 10

Business Users and Goals. Events and System Responses

Use Case Model

…mixing it with…

Business Domain Model

04/12/23 11

UseCase Modeling

Who are the People using the system?* Users, Roles, Actors

What are they trying to accomplish?* HappyPaths, Scenarios, Outcomes, Goals,

Sequences of events and responses

Why are they using the system?* Business Domain Usage Modeling – Who does what

to produce value. How is Business Model realized in software system?

04/12/23 12

User requests. System responds

UseCase is about Behavior.* What happens? And then what happens? And what

else happens? And if it doesn't happen then what happens instead?

UseCase accounts for every user’s goal and all conditons that will stop him/her from accomplishing it.

04/12/23 13

Test Analysis - Textual

Use Case Textual Analysis uncovers Business Domain Model and its usage.

It introduces User Interface Model* Who does what in what place* How something looks like and how it behaves.* The place to put things.

04/12/23 14

Test Analysis - Visual

UseCase is an interaction model to uncover TestCases that verify functional requirements (conditions, rules, constraints)

Interaction model is Non-linear, best shown as diagrams, sketches (Acitivity, Sequence)* Diagrams as Communication Tool. * One page Diagram is worth a thousand words and

sometimes a well constructed sentence is worth a thousand pictures.

04/12/23 15

Test Inventory. Scope and Context

UseCase delineates Scope and Context* What Objects exist in what UseCase and how do

those Objects interact? Scope and Behavior

Test Analysis produces Inventory of TestsCases* How many and what kinds for this Behavior in this

Scope?

04/12/23 16

Finding Defects in UseCases

Most defects can be eliminated with rigorous Test Analysis of UseCase text and by visually modeling its behavior without ever executing a test (and before any code is ever written)* Many UseCases ignore the system’s responses and

possible conditions. If only Users are talking in the UseCase the Systems’ behavior is not shown.

* Sofware behavior happens when System responds and not when the user Requests.

04/12/23 17

User Interacts with System

User Interface Model

How UseCase is realized

in Software Interactions

04/12/23 18

User Interface Model

How does the user know the system?* Presentation Layer, Boundary Objects, Physical View,

How does the user move through the system?* Application Map. Behavior. Page Context. What is this

‘thing’ the user is looking at? What is this ‘thing’ the user is clicking? Selecting? Expecting? Experiencing?

04/12/23 19

UserInterface realizes UseCase

User Interface Model is a wiring (plumbing) for the UseCase. It creates UseCase exisence for the User. It is a presentation of Context.* UseCase is ‘what happens?’* UserInterface is ‘how does that exist?’ - Not

necessarily the details but sketch, a skeleton a wire frame

Link UseCase Scenarios to UserInterace Model for TestCase design.

04/12/23 20

Expected ExistenceExpected Behavior

TestCase Model - Concrete Examples

of Abstract Descriptions

04/12/23 21

To Distinguish Test Case

TestCase is an inventory of Tests

Executed in Context (Scope)

Validating expected existence and expected behavior of the System

Agreed by Stakeholders

Resulting in pass or failure

04/12/23 22

Expectations = Requirements

TestCase is a collaboration of models in context* Domain Model, UseCase Model, UserInterface Model

TestCase models Requirements in context* expected existence and expected behaviour.

Each test validates Contract between Customer and Developer* For this behavior in this context the test Passes or

Fails* Concrete Example of Usage

04/12/23 23

TestCase vs UseCase

TestCase is distinct from UseCase* UseCase models events and responses – User and

System.* TestCase models specific behavior in the context of

UseCase Scenario. It realizes UseCase with a set of functional requirements using Concrete Example.

04/12/23 24

Human ReadableMachine Executable

Object Oriented

Test Case Notation

04/12/23 25

Tests in Natural Language

Tests written in a Natural Language are processed only by Human Beings* Pages and Pages of Text. Lots of presentation layer with lots of

embedded data (tables with data, numbered outlines. Footnote explanations)

Costly to Write and Slow to Execute.* Every time the test is run by a Human Being reading Text of Test Case

and translating steps into interactions with the System.* Very costly, error prone, slow, risky

Almost all TestCases are written in Natural Language* …or are not written at all and tests are conducted by expert users only

who have a secret knowledge of how the system behaves and what is an isn’t a defect.

04/12/23 26

Tests in Object Oriented Language

Tests written in a OO notation can be automatedChild.clean(your_room)‘Billy, go clean your room’ said Mom to her Child

Room.clean()Said Billy to his Room (but Room did not return response)

Object.message(argument)Said Object to another Object.

Fast to write and fast to execute.* Each step is about expected state and expected behviour.* Response is built in to the requests* Reusable parts. Plug and play

04/12/23 27

Understanding TestObjects

Tests in Object Oriented Language are Human Readable and Understandable* TestObjects are known ‘things’* All ‘things’ are found in DomainModel, UseCase Model or User

Interface Model.

Every ‘thing’ in a TestCase is a TestObject* Shared vocabulary drives TestCase standard notation

Each ‘step’ in TestCases is a TestObjects sending a messages to another.

04/12/23 28

Request, Response

Object Oriented Notation captures the Interaction between Objects.* Every request gets a reponse

When Mom sends a message to Billy does she get an answer?* Yes – but not what does the call to Billy return?

04/12/23 29

Building Tests based on Model View Presenter Pattern

UseCase as Presenter Object

Brief Introduction

04/12/23 30

UseCase Driven Test Automation

Solution with 3 parts* Model: Domain Model, Business Objects, Data, Test

Configurations, System Under Test, Users, Roles* View: User Interface Model, Browser, Pages* Presenter: UseCase Driven design* Model ‘speaks’ to Controller to interact with View.* Data drives the TestCase to interact with Browser

Let’s repeat short and sweet* Model is Structure and Behaviour Of Test Objects* View is Presentation.* Controller is Test based on UseCase

04/12/23 31

Thank You

Questions?