Object Oriented Test Strategy for Web Applications
-
Upload
rubytester-testrus -
Category
Business
-
view
5.336 -
download
0
description
Transcript of Object Oriented Test Strategy for Web Applications
04/12/23 1
Object Oriented Test Design Strategy for Web Applications
Test Architecture for Constant Change
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?