How to design a test case for an inter-class?

As the integration of object oriented system begins, the designing of test cases becomes difficult. Testing of collaborations among classes should start at this point. It can be accomplished by applying random and partitioning methods and also scenario based and behavioral testing.

Multiple class random test cases can be generated in following steps:
- Generate random test sequences from the list of class operations for each client class and these messages are sent to server classes.
- Collaborator class and the operation is determined for each message that is generated.
- The transmitted messages are determined for each operation in the server object.
- The next level of operations are determined for each of the messages.

A state diagram for a class is used to help in deriving a sequence of tests that exercises the dynamic behavior and the classes that are collaborated with it. The tests that are designed should achieve all state coverage. Every behavior for the class should be adequately exercised. In case of inter class test case design, multiple state diagrams are used to track the behavioral flow of the system.

A state diagram can be traversed in a breadth first manner. It implies that a test case exercises a single transition. When a new transition is to be tested only previously tested transitions are used.

How to create a behavioral model in software engineering?

While other analysis modeling elements provides a static view of the software, behavioral modeling depicts the dynamic behavior. The behavioral model uses input from scenario based, flow oriented and class based elements to represent the states of analysis classes and the system as a whole. To accomplish this, states are identified, the events that cause a class to make a transition from one state to another are defined, and the actions that occur as transition is accomplished are also identified. State diagrams and sequence diagrams are the UML notation used for behavioral modeling.

The behavioral model is an indication showing how a software responds to external event. Steps to be followed are:
- All use cases are evaluated.
- Events are identified and their relation to classes are identified.
An event occurs whenever the system and an user exchange information. An event is not the information that is exchanged but a fact that information has been exchanged.

- A sequence is created for use-case.
- A state diagram is built.
There are two different characterizations of states in behavioral modeling : state of class as system performs its function and the state of the system as seen from outside. The system has states that represent specific externally observable behavior whereas a class has states that represent its behavior as the system performs its functions.
- Behavioral model is reviewed for accuracy and consistency.

Some best practices that contribute to improved software testing Part III

There is always a search for best practices going on. Some are well known and some hidden. Testing does not stand alone. It is intimately dependant on the development practices. These practices have come from many sources. These practices can be divided in three parts:
- Basic Practices
- Foundation Practices
- Incremental Practices

The incremental practices include:
- Teaming Testers with Developers
This practice should understand the kinds of teaming that are beneficial and the environments in which they are employed. This practice should be more than just a concept.
- Code coverage
Code coverage is the numerical metric that measures the elements of code. this practice should include the information about the tools and methods of how to employ code coverage and track results.
- Automated Environment Generator
Setting up test environments to execute test cases is the most difficult task. This practice should capture the issues, tools and techniques that are associated with setting up the environment, the break down and automatic running of test cases.
- Testing to help ship on demand
Testing process should be viewed as one that enables changes that occur late and handles market pressures and still do not break the product or ship schedule. This practice should identify how to work this concept in organizations.
- State task diagram
State transition diagrams are used to capture functional operations of an application. It allows you to create test cases automatically. This practice has more than one application and one need to capture the tools, methods and uses.
- Memory Resource Failure Simulation
This practice addresses loss of memory because of poor management or lack of garbage collection. It should develop methods and tools for use on different platforms and language environments.
- Statistical Testing
the concept of statistical testing is to use software testing as a means to assess the reliability of software as opposed to a debugging process. It needs to work on the software along an operational profile and measuring interfailure times used to estimate reliability.
- Semiformal Methods
A semi formal method is one where specifications that are captured may be in state transition diagrams or tables that can be used for even test generation.
- Check-in tests for code
Check-in tests couple an automatic test program with the change control system. the chances of the code breaking the build are minimized.
- Minimizing regression test cases
To minimize regression tests, several methods are there out of which one method looks at code coverage and distill test cases to a minimal set. Sometimes, it does confuse a structural metric with a functional test.
- Instrumented versions for MTTF
Mean time between failures(MTTF) can be measured if the failures are recorded and returned to vendor. It enhances the quality of the product that is meaningful to user. It also captures first failure data that benefits the diagnosis and problem determination.
- Benchmark Trends
This practice could be initiated by benchmarking and then advance the practice to include a large pool with customers and competitors.
- Bug Bounties
These are the initiatives that charge the organization with a focus on detecting software bugs.

Flow Oriented Modeling - Creating a Data Flow Model

Flow models focus on the flow of data objects as they are transformed by processing functions. Derived from structured analysis,flow models use the data flow diagram, a modeling notation that depicts how input is transformed into output as data objects move through the system. Each software function that transforms data is described by a process specification or narrative. In addition to data flow, this modeling element also depicts control flow.

Data flow oriented modeling is the most widely used analysis notation. Flow oriented modeling focuses on structured analysis and design, follows a top to down methodology and uses a graphical technique depicting information flows and the transformations that are applied as data moves from input to output.

The modeling tools that are used to build a data flow oriented model include context diagrams, data flow diagrams, entity relationship diagram, control flow diagram, state transition diagram, data dictionary, process specification and control specification.

Steps to create a data flow model
- Diagram 0: develop a context diagram.
- Decompose the Process into high level processes.
- In parallel to this, develop data flow diagrams, entity relationship diagrams and state transition diagrams.
- Define data stores which includes normalization.
- Develop data dictionary.
- Finalize data flow diagrams, entity relationship diagram and state transition diagrams.
- Develop process specifications which includes PDL, decision tables or trees.
- Perform transformational analysis which includes developing structure charts.
Information flow continuity must be maintained as each data flow diagram level is refined. This means that input and output at one level must be the same as input and output at a refined level.

Overview of The Interaction Model - Use cases, Sequence diagrams, State diagrams, User interface prototype

The interaction model of web applications enables a conversation between an end user and application functionality, content, and behavior. Interaction model is made up of four elements:
- Use cases
- Sequence diagrams
- State diagrams
- User interface prototype

Some use cases describe the interactions between end user categories and the system. Other use cases refine the interactions, providing the analysis detail necessary to guide design and construction. Use cases provide a one-dimensional view of the interaction.

Sequence diagrams are a shorthand representation of the manner in which dynamic elements(user actions) collaborate with the structural elements(analysis classes) of the system. There is a need to ensure that traceability exists between the classes that have been defined and the use-cases that describe system interaction. Sequence diagrams can be created for each use-case once analysis classes are defined for the use case. Sequence diagrams present a second dimension that is more procedural in nature.

As the interaction occurs, state diagrams are another way to represent the dynamic behavior of the web application. State diagrams can be represented at different levels of abstraction. State diagrams provide a third dimension that is more behavioral and contains information about potential navigation pathways that is not provided by use cases or the sequence diagram.
Large complex web applications benefits from interaction model that encompasses the three representations : use cases, sequence diagrams and state diagrams.


User Interface Prototype : The layout of user interface, content it presents, interaction mechanisms, and overall aesthetic of user-web application connections have much to do with user satisfaction and the overall acceptance of the web application. User interface prototype is performed during the creation of analysis model.