Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Object Oriented Test Strategy for Web Applications


Published on

Distinguish Test Modeling and Collboration of parts to establish OO TestStrategy.

Published in: Business, Technology
  • Be the first to comment

Object Oriented Test Strategy for Web Applications

  1. 1. Object Oriented Test Design Strategy for Web Applications Test Architecture for Constant Change [email_address]
  2. 2. Design to Eliminate defects <ul><li>Every time Software slows the Business the Software has an identifiable and measurable defect . </li></ul><ul><li>With each defect Business User’s usefulness of the system diminishes. Defects introduce 'drag' which can be measured. </li></ul><ul><li>How do we Architecture Tests to Eliminate Defects and not simply Discover them? </li></ul>
  3. 3. Design for Constant Change <ul><li>It seems that Requirement is whatever the Business User expects to be or to happen, either now or in the future. – that is correct! </li></ul><ul><li>It seems that Functional Requirements are never frozen. Customer demands change, avoids specific agreement on functionality. – that is correct ! </li></ul><ul><li>How do we design Software Tests for Constant Change? </li></ul>
  4. 4. Distinguish Building Blocks of Test Architecture Business Domain Model UseCase Model UserInterface Model TestCase Model
  5. 5. What do we mean by Business Domain Model People use Language to engage in Business and produce Results
  6. 6. To Engage and Move in Business <ul><li>Construct the Map of the Abstract World </li></ul><ul><ul><li>What concepts do people communicate with each other to accomplish business? </li></ul></ul><ul><li>Discover how to Navigate with Shared Vocabulary </li></ul><ul><ul><li>What words do people use to convey business meaning? </li></ul></ul><ul><ul><li>What are ways of speaking about ‘doing things’ and producing results? </li></ul></ul>
  7. 7. Meaning Making with Distinctions and Signifiers <ul><li>What makes this ‘thing’ be this ‘thing’ ? </li></ul><ul><ul><li>Semantics, Distinguishing: … a Customer is someone who… ? A Contract is a …. ? </li></ul></ul><ul><li>What special words, semantic signifiers exist that reference events, things, and relationships between them? </li></ul><ul><ul><li>When I say X I mean ‘this thing’. When I say Y I mean ‘that thing’ </li></ul></ul><ul><ul><li>First X then Y and Z in the end. If Y is before X then Z can’t happen. </li></ul></ul>
  8. 8. Business Domain Test Strategy <ul><li>Business Domain Model suggests why and how it needs to be tested. </li></ul><ul><li>Discover and Reveal Business Value. </li></ul><ul><ul><li>Distinguish behavioral and informational attributes of business objects. </li></ul></ul><ul><ul><li>Behavioral attributes drive business rules, constraints, test conditions. </li></ul></ul><ul><ul><li>Informational attributes provide structure of existence. </li></ul></ul>
  9. 9. Business Domain Test Metrics <ul><li>TestCase design and TestCoverage criteria derive from the Business Domain Model. </li></ul><ul><ul><li>How would you know a bug if saw it? How do you describe a defect ? how do you classify defects ? </li></ul></ul><ul><ul><li>How would you know business value if it existed? How do you describe ‘it works’ ? </li></ul></ul>
  10. 10. Business Users and Goals. Events and System Responses Use Case Model …mixing it with… Business Domain Model
  11. 11. UseCase Modeling <ul><li>Who are the People using the system? </li></ul><ul><ul><li>Users, Roles, Actors </li></ul></ul><ul><li>What are they trying to accomplish ? </li></ul><ul><ul><li>HappyPaths, Scenarios, Outcomes, Goals, Sequences of events and responses </li></ul></ul><ul><li>Why are they using the system ? </li></ul><ul><ul><li>Business Domain Usage Modeling – Who does what to produce value. How is Business Model realized in software system ? </li></ul></ul>
  12. 12. User requests . System responds <ul><li>UseCase is about Behavior . </li></ul><ul><ul><li>What happens? And then what happens? And what else happens? And if it doesn't happen then what happens instead? </li></ul></ul><ul><li>UseCase accounts for every user’s goal and all conditons that will stop him/her from accomplishing it. </li></ul>
  13. 13. Test Analysis - Textual <ul><li>Use Case Textual Analysis uncovers Business Domain Model and its usage. </li></ul><ul><li>It introduces User Interface Model </li></ul><ul><ul><li>Who does what in what place </li></ul></ul><ul><ul><li>How something looks like and how it behaves. </li></ul></ul><ul><ul><li>The place to put things. </li></ul></ul>
  14. 14. Test Analysis - Visual <ul><li>UseCase is an interaction model to uncover TestCases that verify functional requirements (conditions, rules, constraints) </li></ul><ul><li>Interaction model is Non-linear, best shown as diagrams, sketches (Acitivity, Sequence) </li></ul><ul><ul><li>Diagrams as Communication Tool. </li></ul></ul><ul><ul><li>One page Diagram is worth a thousand words and sometimes a well constructed sentence is worth a thousand pictures. </li></ul></ul>
  15. 15. Test Inventory. Scope and Context <ul><li>UseCase delineates Scope and Context </li></ul><ul><ul><li>What Objects exist in what UseCase and how do those Objects interact? Scope and Behavior </li></ul></ul><ul><li>Test Analysis produces Inventory of TestsCases </li></ul><ul><ul><li>How many and what kinds for this Behavior in this Scope? </li></ul></ul>
  16. 16. Finding Defects in UseCases <ul><li>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) </li></ul><ul><ul><li>Many UseCases ignore the system’s responses and possible conditions. If only Users are talking in the UseCase the Systems’ behavior is not shown. </li></ul></ul><ul><ul><li>Sofware behavior happens when System responds and not when the user Requests . </li></ul></ul>
  17. 17. User Interacts with System User Interface Model How UseCase is realized in Software Interactions
  18. 18. User Interface Model <ul><li>How does the user know the system? </li></ul><ul><ul><li>Presentation Layer, Boundary Objects, Physical View, </li></ul></ul><ul><li>How does the user move through the system? </li></ul><ul><ul><li>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? </li></ul></ul>
  19. 19. UserInterface realizes UseCase <ul><li>User Interface Model is a wiring (plumbing) for the UseCase. It creates UseCase exisence for the User . It is a presentation of Context. </li></ul><ul><ul><li>UseCase is ‘what happens?’ </li></ul></ul><ul><ul><li>UserInterface is ‘how does that exist?’ - Not necessarily the details but sketch, a skeleton a wire frame </li></ul></ul><ul><li>Link UseCase Scenarios to UserInterace Model for TestCase design. </li></ul>
  20. 20. Expected Existence Expected Behavior TestCase Model - Concrete Examples of Abstract Descriptions
  21. 21. To Distinguish Test Case <ul><li>TestCase is an inventory of Tests </li></ul><ul><li>Executed in Context (Scope) </li></ul><ul><li>Validating expected existence and expected behavior of the System </li></ul><ul><li>Agreed by Stakeholders </li></ul><ul><li>Resulting in pass or failure </li></ul>
  22. 22. Expectations = Requirements <ul><li>TestCase is a collaboration of models in context </li></ul><ul><ul><li>Domain Model, UseCase Model, UserInterface Model </li></ul></ul><ul><li>TestCase models Requirements in context </li></ul><ul><ul><li>expected existence and expected behaviour. </li></ul></ul><ul><li>Each test validates Contract between Customer and Developer </li></ul><ul><ul><li>For this behavior in this context the test Passes or Fails </li></ul></ul><ul><ul><li>Concrete Example of Usage </li></ul></ul>
  23. 23. TestCase vs UseCase <ul><li>TestCase is distinct from UseCase </li></ul><ul><ul><li>UseCase models events and responses – User and System. </li></ul></ul><ul><ul><li>TestCase models specific behavior in the context of UseCase Scenario . It realizes UseCase with a set of functional requirements using Concrete Example . </li></ul></ul>
  24. 24. Human Readable Machine Executable Object Oriented Test Case Notation
  25. 25. Tests in Natural Language <ul><li>Tests written in a Natural Language are processed only by Human Beings </li></ul><ul><ul><li>Pages and Pages of Text. Lots of presentation layer with lots of embedded data (tables with data, numbered outlines. Footnote explanations) </li></ul></ul><ul><li>Costly to Write and Slow to Execute. </li></ul><ul><ul><li>Every time the test is run by a Human Being reading Text of Test Case and translating steps into interactions with the System. </li></ul></ul><ul><ul><li>Very costly, error prone, slow, risky </li></ul></ul><ul><li>Almost all TestCases are written in Natural Language </li></ul><ul><ul><li>… 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. </li></ul></ul>
  26. 26. Tests in Object Oriented Language <ul><li>Tests written in a OO notation can be automated </li></ul><ul><ul><li>Child.clean(your_room) </li></ul></ul><ul><ul><li>‘ Billy, go clean your room’ said Mom to her Child </li></ul></ul><ul><ul><li>Room.clean() </li></ul></ul><ul><ul><li>Said Billy to his Room (but Room did not return response) </li></ul></ul><ul><ul><li>Object.message(argument) </li></ul></ul><ul><ul><li>Said Object to another Object. </li></ul></ul><ul><li>Fast to write and fast to execute. </li></ul><ul><ul><li>Each step is about expected state and expected behviour. </li></ul></ul><ul><ul><li>Response is built in to the requests </li></ul></ul><ul><ul><li>Reusable parts. Plug and play </li></ul></ul>
  27. 27. Understanding TestObjects <ul><li>Tests in Object Oriented Language are Human Readable and Understandable </li></ul><ul><ul><li>TestObjects are known ‘things’ </li></ul></ul><ul><ul><li>All ‘things’ are found in DomainModel, UseCase Model or User Interface Model. </li></ul></ul><ul><li>Every ‘thing’ in a TestCase is a TestObject </li></ul><ul><ul><li>Shared vocabulary drives TestCase standard notation </li></ul></ul><ul><li>Each ‘step’ in TestCases is a TestObjects sending a messages to another. </li></ul>
  28. 28. Request, Response <ul><li>Object Oriented Notation captures the Interaction between Objects. </li></ul><ul><ul><li>Every request gets a reponse </li></ul></ul><ul><li>When Mom sends a message to Billy does she get an answer? </li></ul><ul><ul><li>Yes – but not what does the call to Billy return? </li></ul></ul>
  29. 29. Building Tests based on Model View Presenter Pattern UseCase as Presenter Object Brief Introduction
  30. 30. UseCase Driven Test Automation <ul><li>Solution with 3 parts </li></ul><ul><ul><li>Model: Domain Model, Business Objects, Data, Test Configurations, System Under Test, Users, Roles </li></ul></ul><ul><ul><li>View: User Interface Model, Browser, Pages </li></ul></ul><ul><ul><li>Presenter: UseCase Driven design </li></ul></ul><ul><ul><li>Model ‘speaks’ to Controller to interact with View. </li></ul></ul><ul><ul><li>Data drives the TestCase to interact with Browser </li></ul></ul><ul><li>Let’s repeat short and sweet </li></ul><ul><ul><li>Model is Structure and Behaviour Of Test Objects </li></ul></ul><ul><ul><li>View is Presentation. </li></ul></ul><ul><ul><li>Controller is Test based on UseCase </li></ul></ul>
  31. 31. Thank You Questions?