Object Oriented Test Strategy for Web Applications

Object Oriented Test Design Strategy for Web Applications Test Architecture for Constant Change [email_address]

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?

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?

Distinguish Building Blocks of Test Architecture Business Domain Model UseCase Model UserInterface Model TestCase Model

What do we mean by Business Domain Model People use Language to engage in Business and produce Results

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?

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.

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.

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

Business Users and Goals. Events and System Responses Use Case Model …mixing it with… Business Domain Model

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 ?

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.

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.

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.

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?

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 .

User Interacts with System User Interface Model How UseCase is realized in Software Interactions

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?

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.

Expected Existence Expected Behavior TestCase Model - Concrete Examples of Abstract Descriptions

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

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

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 .

Human Readable Machine Executable Object Oriented Test Case Notation

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.

Tests in Object Oriented Language
Tests written in a OO notation can be automated
Child.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

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.

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?

Building Tests based on Model View Presenter Pattern UseCase as Presenter Object Brief Introduction

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

Thank You Questions?

http://rantsonsoftware.com	393
http://www.slideshare.net	10
http://translate.googleusercontent.com	3

Object Oriented Test Strategy for Web Applications

by rubytester (testrus)

Accessibility

Categories

Upload Details

Usage Rights

3 Embeds 406

Statistics

Object Oriented Test Strategy for Web Applications Presentation Transcript