Arunkumar Khannur's Software Testing Knowledge Center
   
 

3.7. Test Object

The characteristics of the component under test can be abstracted using structures and relationships that make the component fail. Certain kinds of base models, such as use cases and state transition diagrams lend themselves into direct testing.

Each of these models has a set of model constructs that serve as the basis of test scripts. These test model components are the test objects. A review or a test script tests one or more test objects in the test model.

For example, in requirement reviews, use cases are inspected in the requirements model. In state transition tests, paths from through the state transition graph from construction to destruction of the object are inspected.

Different test models are appropriate for different technical components.
Each path or flow is a model component that defined a specific review or test script in a test suite.

The base models appear along the right, cascading down the life cycle, to a working software system. We can transform each base model into a test model and test suites can be developed from the test model.
Phase Base Model Test Object Test Model Description Review
Requirement specifications Phase Requirements Model SRS document. Functional and Non functional specifications of the customer. Requirement Review to know Testability and Test Factors
Requirements Model Requirements use cases A series of actions between user and system. that comprise a single functionality at the system level, a scenario that shows a particular feature that the user drives. Ex: Flow Diagrams, Decision Tables. Use Case review to ensure coverage of primary flows, alternate flows, associated UI Design.
Analysis Phase Data Context Diagrams Data Context A picture of the system and its interfaces to external entities and systems. It shows the boundary between the system and its environment, in perspective to real world, with all inputs and outputs identified.
Ex: Data Context Diagram (DCD)
Review of DCDs to ensure all external entities and overall system functionality is covered.
Data Flow Diagrams Flow of data A picture of the system as a network of functional processes connected to each other by pipelines of data (Data Flows) and holding tanks of data (Data stores). The processes transform the data. The data flow diagram partitions the system into its component parts.
Ex: Data Flow Diagrams (DFD)
Review of the DFDs to ensure all system functionality and data flows are covered.
Process Specifications Process Specification The description of a function or process at the lowest level of decomposition. The specification is written for every granular functional aspect. It captures the transformation to be performed within each process that includes what inputs cause the desired outputs
Ex: Process Specifications (PSPECs)
Review of the process specification to ensure validity from every granular functional aspect.
Entity Relationship Diagrams Entities and Relationships among entities A graphical representation of the data objects and their relationships. The Entity Relationship Diagram defines all the data i.e. it can be input, stored and transformed and produced within an application. The data is organized into meaningful groups and the relationships are drawn across these groups.
Ex: Entity Relationship Diagrams (ERD)
Review of the ERD to ensure that all data objects are identified and their relationships are appropriately defined.
Control Context Diagrams Process and identification of appropriate inputs and outputs from and to external entities. Control Context Diagram (CCD) is similar to a Data Flow Diagram (DFD). The CCD has only one process and shows inputs and outputs from and to external entities and is broken down into smallest possible components. Clear, precise, complete specifications are written for these components. The data that appears on a Control Flow Diagram is the control data that causes a system state change, resulting in activation or deactivation of transforms Review of CCDs to ensure identification of appropriate inputs and outputs from and to external entities.
Control Flow Diagram Flow of control Control flows are modeled in a control flow diagram like the way data flows are modeled in data flow diagram. The processes and data stores are indicated like the way they are displayed on a DFD. The key difference that this diagram has with respect to the DFD is that the control flows are shown as a dotted line and a bar symbol is added to represent the control specification (CSPEC) that may change the state of the system. The External Entities are not displayed in a Control Flow Diagram (CFD). Review of control flow details
Control Specifications State Transition Diagrams Control Specification (CSPECs) are similar to Control Flow Diagrams, model the control flows indicated by a bar on CFD using State Transition Diagrams. The primary goal of the Control Specifications is to change the response of the data processor according to the past and present conditions both within and outside the system. Review of State transition diagrams for correctness.
Design Models Enhanced Entity Relationship Diagram Identification of all entities and the relationship among the entities. Grouping of similar entities. Entity Relationship diagrams is part of the Structured Analysis phase. While designing an Entity Relationship Diagram for a large system, entities belonging to similar type of transactions, should be grouped together resulting in many individual Entity Relationship Diagrams, which can be integrated together to accomplish the overall design of the entire system Review of EERDs to ensure complete coverage of the requirements and proper relationship definition among them and appropriate grouping.
Architecture Context Diagrams (ACD) High level architecture components Architecture Context Diagrams (ACD) represents the highest-level architecture of the system. The elements that make up the ACD are Architecture module, representing the whole system Review of high level architecture components to ensure maintainability, scalability.
Architecture Flow Diagrams (AFD) Physical allocation of the requirements model’s data and control processing and flows into the physical entities that perform the allocated tasks Architecture Flow Diagrams (AFD) is a network representation of the system’s physical configuration. AFD shows the physical allocation of the requirements model’s data and control processing and flows into the physical entities that perform the allocated tasks. It shows the physical partitioning of the system into its component pieces and the information flow among them. In an AFD, functional processes of the requirements model are allocated to the physical units of the system and additional processes are added as to support the new physical interfaces. Review of AFDs to ensure proper physical allocation of the requirements model’s data and control processing and flows into the physical entities that perform the allocated tasks
Structured Charts Definition of proper hierarchy, categorization of modules Structured chart is a tool to help define a hierarchical, modularized implementation model for a software system. Review of the structured chart to ensure proper definition of hierarchical structure and categorization of modules.
Architecture Interconnect Diagram Communication channels that exist between architecture components Architecture Interconnect Diagram (AID) is the representation of the communication channels that exist between architecture modules. The diagram shows the physical channels through which the communication between modules happens.
Chapin Charts Describes the procedures used to receive, process and transmit information. The chart provides all the necessary information regarding the logic of the program to begin with immediate coding to support specific function.
System Integration and Release Requirements Model System resource A specific thing that the system consumes while processing such as memory, network packets or disk space System stress test script
Requirements Model System performance A use case that specifies the performance characteristics of the part or all of the system System performance test script
Requirements Model System functionality A requirements document that specifies all the workflows System workflow test script
Requirements Model System vulnerability A specific weakness in the system, the exploitation of which, could result in sabotage, deliberate system damage, loss of system control or other security breaches System security test script

Each specific kind of test object addresses some aspect of the system that contributes to overall risk of failure. These divisions are by no means mutually exclusive. The test objects often overlap when you map them to the base model. The Test model must answer the question whether the model is testable or in other words, is it possible to develop a set of test scripts that achieves your acceptable level of risk.
 
 
 
Khannur's Book
Arunkumar Khannur, Software Testing - Techniques and Applications, Published by Pearson Publications, 2011 (ISBN:978-81-317-5836-6; Pages:341 + xxii)
Follow Khannur
         
Khannur's Company
ISQT Process & Consulting Services Pvt. Ltd., Bangalore, INDIA
Khannur's Software Testing Forum
STEP-AUTO Forum
 Contact Khannur
ISQT Process & Consulting Services Pvt. Ltd.
#732, 1st Floor, 12th Main,
3rd Block, Rajajinagar,
Bangalore - 560010, INDIA
Phone: +91 80 23012511
URL: www.isqtinternational.com
Email: khannur@isqtinternational.com
Skype: arun.isqt