UNIT-5

1. Explain various Object Oriented Methodologies in detail.

Various Object Oriented Methodologies are

• RumBaugh’s OMT Model.

• Booch Methodologies.
• Jacobson Methodologies.

1.RumBaugh’s OMT Model

• The object modeling techniques (OMT) describes a method for the analysis, design and
implementation using an object-oriented technique.
• The dynamic behavior of objects within a system is described in OMT dynamic model.

OMT consists of four phases

Analysis: Objects, dynamic and functional models

System design: Basic architecture of the system

Object Design: Static, dynamic and functional models of objects.

Implementation: Reusable, extendible and robust code.

The system can be modeled with the help of 3 different models

1. Object Model
2. Dynamic Model
3. Functional Model

Object Model

• It is an object diagram containing interrelated objects.

• Objects are represented by object notation and it contains Name, Behavior and attributes.
• Association lines represent the relationship between the objects.
 •

Dynamic Model

• Represents a set of states possessed by the system.

• Interconnected lines represent the transition between the states.
• The system performs some activity when it is in a state.
• One or more event may occur in a state.
• Hence next state depends on the current state and event.
 Functional Model
• Represents flow of data between various functional blocks of the system.
• A functional model may be an external device, process or a Data store.
• Functional blocks are connected by labeled line.

• The above diagram represents the flow of data between various functional blocks.
• The external devices are represented in a rectangular box
• The Process is represented in a oval shape
• The Data Store is represented inside a parallel line.
• Labeled arrows represent direction of flow of data

2. The Booch Methodology

• Widely used Object oriented methodology.
• Covers the design and analysis phase of an OO system.
• Diagrams introduced by Booch are
➢ Class Diagram
➢ Object Diagram
➢ State Transition Diagram
➢ Module Diagram
➢ Process Diagram
➢ Interaction Diagram
The Macro Development Process:
The macro process serves as a controlling frame work for the micro process and can takes weeks (or) even
months. The macro development process consists of the following steps
• Conceptualization.
• Analysis and Development of the Architecture.
• Design or Create the System Architecture.
• Evolution or Implementation.
• Maintenance.
The Micro Development Process:
The micro process is a description of the day to day activities by a single (or) small group of software
developers. The micro development process consists of the following steps.
 • Identify classes and objects.
• Identify class and object semantics.
• Identify class and object relationships.
• Identify class and object interface and implementation.

3.The Jacobson Methodologies

• Jacobson and team came with the concept of Object Oriented Software Engineering(OOSE) and
Object Oriented Business Engineering(OOBE) which covers the entire project life cycle.
• Use Case is introduced by this team and later it is adopted in UML.
• The use cases are the text stories that are designed in order to understand the functionality of the
system.
• A scenario is a specific sequence of actions or interactions between actors and the system.
• Use Case represents the interaction between the actor and the system.
• << include>> relationship is a relationship in which one use case (the base use case) includes the
functionality of another use case (the inclusion use case).
• <<extend>> relationship to specify that one use case (extension) extends the behavior of another
use case (base).
 o Use case model:-
The use-case model defines the outside and inside of the system behaviour
o Domain Object Model:-
The objects of the real world are mapped in to the domain object model
o Analysis Object Model:-
The analysis object model presents how the source code should be carried out written
o Implementation model:
The implementation model represents the implementation of the system
o Test model:-
The test model constitutes the test plans, specification and reports.

2. Explain software quality assurance testing strategies in detail.

Debugging:

Debugging is a process of finding out where something went wrong and correcting the code to eliminate
the errors or bugs that cause unexpected results.

Kinds of errors:
In general, software has three types of errors such as
• Language (syntax) errors
• Run–time errors
• Logic errors

Language (syntax) errors

Language (syntax) errors are result of incorrectly constructed code, such as an incorrectly typed keyword
or punctuations.

Run–time errors
Run–time errors are detected on running, when a statement attempts an operation that is impossible to
carry out.

Logic errors
Logic errors occur when expected output is not formed.

Testing Strategies: -
The objective of s/w testing is to uncover errors. The various testing strategies are
Black Box testing
BLACK BOX TESTING, also known as Behavioral Testing, is a software testing method in which the
internal structure/design/implementation of the item being tested is not known to the tester.

White box testing:

• White box testing assumes that specific logic important and must be tested to guarantee
system’s proper functioning.
• One form of white box testing called path testing, makes certain that each path in a object’s
method is executed at least once during testing.

Integration Testing
Integration Testing is defined as a type of testing where software modules are integrated logically and
tested as a group.

Top–down testing
In Top Down Integration Testing, testing takes place from top to bottom. High-level modules are tested
first and then low-level modules and finally integrating the low-level modules to a high level to ensure the
system is working as intended.

Bottom Up Testing
Each component at lower hierarchy is tested individually and then the components that rely upon these
components are tested.

Regression Testing
Regression Testing is defined as a type of software testing to confirm that a recent program or code
change has not adversely affected existing features.

Alpha Testing
Alpha Testing is defined as a type of software testing performed to identify bugs before releasing the
product to real users.

Beta Testing
Beta testing is performed by Clients or End Users who are not employees of the organization.
System Testing:
• System Testing is the testing of a complete and fully integrated software product.
• System Testing is actually a series of different tests whose sole purpose is to exercise the full
computer-based system.
Recovery testing
The purpose of recovery testing is to verify the system’s ability to recover from varying points of failure.

Stress testing
Stress testing is a type of testing that determines the stability and robustness of the system. It is a non-
functional testing technique.

Performance testing
Performance Testing is defined as a type of software testing to ensure software applications will perform
well under their expected workload.

Security testing
The goal of security testing is to identify the threats in the system and measure its potential
vulnerabilities, so the system does not stop functioning or is exploited.

Explain Test Case and Test Plan in detail..

What is Test case?

A test case is a document, which has a set of test data, preconditions, expected results and
postconditions, developed for a particular test scenario in order to verify compliance against a
specific requirement.

Test Case Template

Test Suite ID:

The ID of the test suite to which this test case belongs.
Test Case ID:
The ID of the test case.
Test Case Summary:
The objective of the test case.
Prerequisites:
Any prerequisites or preconditions that must be fulfilled prior to executing the test.
Test Script / Procedure:
Step-by-step procedure to execute the test.
Test Data:
The test data, or links to the test data, that are to be used while conducting the test.
Expected Result:
The expected result of the test.
Actual Result:
The actual result of the test; to be filled after executing the test.
Status:
The status as Pass or Fail based on the expected result against the actual result. If the actual and
expected results are the same, mention it as Passed. Else make it as Failed.
Remarks:
Any comments on the test case or test execution.
Created By:
The name of the author of the test case.
Date of Creation:
The date of creation of the test case.
Executed By:
The name of the person who executed the test.
Date of Execution:
The date of execution of the test.
Test Environment:
The environment (Hardware/Software/Network) in which the test was executed.

Example:
Best Practice for writing good Test Case Example
o Write in simple and easy-to-understand language.
o Use active voice instead of passive voice: Do this, do that.
o Use exact and consistent names.
o Including End User Perspective.
o Using Correct Naming Conventions.
o Providing Test Case Description.
o Including Assumptions.
o Providing Steps Involved.
o Giving Details of Test Data.
o Making it Reusable.

Test Plan:
A Test Plan is a detailed document that describes the test strategy, objectives, schedule,
estimation, deliverables, and resources required to perform testing for a software product.
How to write a Test Plan
Test Plan is the most important task of Test Management Process. Follow the seven steps
below to create a test plan.

1. Analyze the product

2. Design the Test Strategy
3. Define the Test Objectives
4. Define Test Criteria
5. Resource Planning
6. Plan Test Environment
7. Schedule & Estimation
8. Determine Test Deliverables