S No Name of the Experiment

1 Study and usage of Open Project or similar software to draft a project plan

2 Study and usage of Open Project or similar software to track the progress of a project

3 Preparation of Software Requirement Specification Document, Design Documents and

Testing Phase related documents for some problems

4 Preparation of Software Configuration Management and Risk Management related

documents

5 Study and usage of any Design phase CASE tool

6 To perform unit testing and integration testing

7 To perform various white box and black box testing techniques

8 Testing of a web site

Experiment: 1

Name of the Experiment: Project plan drafting

Aim: Study and usage of planning software to draft a project plan

Definition of project plan

The purpose of Software Project Planning is to establish reasonable plans for performing the
software engineering and for managing the software project. Software Project Planning involves
developing estimates for the work to be performed, establishing the necessary commitments, and
defining the plan to perform the work.

The purpose of the Project Plan is to document all managerial aspects of a project that are
required to execute it successfully within its constraints. If some aspects are defined in separate
plans the Project Plan should refer to these documents
Project planning is part of project management, which relates to the use of schedules such as
charts to plan and subsequently report progress within the project environment

Software project planning is task, which is performed before the production of software actually
starts. It is there for the software production but involves no concrete activity that has any
direction connection with software production; rather it is a set of multiple processes, which
facilitates software production. Project planning may include the following:

Scope Management and goals

It defines the scope of project; this includes all the activities, process need to be done in order to
make a deliverable software product. Scope management is essential because it creates
boundaries of the project by clearly defining what would be done in the project and what would
not be done. This makes project to contain limited and quantifiable tasks, which can easily be
documented and in turn avoids cost and time overrun.
Project Goal
Functional Goals:
<functional goal #1>
<functional goal #2>
Priority Comment/Description/Reference
2 For details see the Project Requirements Specification Error!
Reference source not found.

Business Goals:
<Time-to-market>
<efficiency, cost, quality>

Technological Goals:
<technical goal #1>

Quality Goals: 2
<quality goal #1>

Project Estimation
For an effective management accurate estimation of various measures is a must. With correct
estimation managers can manage and control the project more efficiently and effectively.

Project estimation may involve the following:

 Software size estimation

Software size may be estimated either in terms of KLOC (Kilo Line of Code) or by
calculating number of function points in the software. Lines of code depend upon coding
practices and Function points vary according to the user or software requirement.

 Effort estimation
The managers estimate efforts in terms of personnel requirement and man-hour required
to produce the software. For effort estimation software size should be known. This can
either be derived by managers’ experience, organization’s historical data or software
size can be converted into efforts by using some standard formulae.
 Time estimation
Once size and efforts are estimated, the time required to produce the software can be
estimated. Efforts required is segregated into sub categories as per the requirement
specifications and interdependency of various components of software. Software tasks
are divided into smaller tasks, activities or events by Work Breakthrough Structure
(WBS). The tasks are scheduled on day-to-day basis or in calendar months.

The sum of time required to complete all tasks in hours or days is the total
time invested to complete the project.

 Cost estimation
This might be considered as the most difficult of all because it depends on more
elements than any of the previous ones. For estimating project cost, it is required to
consider -

o Size of software
o Software quality
o Hardware
o Additional software or tools, licenses etc.
o Skilled personnel with task-specific skills
o Travel involved
o Communication
o Training and support
o

Category Budget for Period in kUS$

M0-M1 M1-M2 M2-M3 M3-M4 M4-M5 M5-M6
Human Resources (internal)
Human Resources (external)
Purchases (COTS)
Equipment
Premises
Tools
Travel costs
Training
 Category Budget for Period in kUS$
M0-M1 M1-M2 M2-M3 M3-M4 M4-M5 M5-M6
Review activities
Other
Total 1 1 2 5 2 1
Total cumulated 1 2 4 9 11 12

Project Scheduling
Project Scheduling in a project refers to roadmap of all activities to be done with specified order
and within time slot allotted to each activity. Project managers tend to tend to define various
tasks, and project milestones and them arrange them keeping various factors in mind. They look
for tasks lie in critical path in the schedule, which are necessary to complete in specific manner
(because of task interdependency) and strictly within the time allocated. Arrangement of tasks
which lies out of critical path are less likely to impact over all schedule of the project.

For scheduling a project, it is necessary to -

 Break down the project tasks into smaller, manageable form

 Find out various tasks and correlate them
 Estimate time frame required for each task
 Divide time into work-units
 Assign adequate number of work-units for each task
 Experiment 2

Name of the Experiment: Track the progress of the project.

Aim: Study and usages of tracking software to track the progress of a project.

In this experiment it is measure the progress of the project in different ways which is shown in
the graphs. Tracking your project and ensuring that it stays on target are the real guts of project
management. Building a good plan is not nearly as hard as keeping that plan on track after reality
sets in and starts taking your wonderful plan apart. Once your plan is set up and your resources
assigned, you are ready to start your project. This brings you to a different set of Project features,
which can help you track your progress and compare this progress to your original plan. In this
article, we’ll examine the following methods of tracking progress:

 Baselines
 Status using percent complete
 Status using actual work hours

Baselines
After you have your resources leveled and everything is set to begin, you might want to
baseline your project. Baseline is a common project management term. It refers to a set of
data about your project that represents its state before the work actually began. In Project, a
baseline is a copy of the Start, Finish, Work, and Cost for all the Resources and
Assignments, plus Duration for all the Tasks in your project.

Together, this data represents the state of your plan at the time the baseline is saved. The
baseline will be a valuable tool to use as your project progresses, and after it completes, to
compare how the real life of your project matched up with what you projected during the
planning stages.

 Status using actual work hours

The actual work method is basically the same as percentage complete, except it offers more detail. The
actual work approach is normally used when a resource uses a timecard to track how many hours are
spent working on each task for a given time period.
Resource Usage view set up to record actual work

 Status using percent complete

The percent complete method uses the general feelings of the resource or the project
manager about how complete an assignment or task is. You are asking your resource
to tell you what percentage of the work is complete. You then enter this information
into the Resource Usage view by adding in the Percent Work

Resource Usage with Percent Work Complete

Execution needs monitoring in order to check whether everything is going according to the
plan. Monitoring is observing to check the probability of risk and taking measures to address
the risk or report the status of various tasks.

These measures include -

 Activity Monitoring - All activities scheduled within some task can be monitored on
day-to-day basis. When all activities in a task are completed, it is considered as complete.
  Status Reports - The reports contain status of activities and tasks completed within a
given time frame, generally a week. Status can be marked as finished, pending or work-
in-progress etc.
 Milestones Checklist - Every project is divided into multiple phases where major tasks
are performed (milestones) based on the phases of SDLC. This milestone checklist is
prepared once every few weeks and reports the status of milestones.
Gantt Charts for Project tracking
A Gantt Chart is a traditional way to prepare and track a project plan. It shows activities on the
left and dates on top. Intersection of an activity and date cell is highlighted if that activity is to be
done on that date. Gantt Charts can provide these optional information
Gantt Chart
Gantt charts was devised by Henry Gantt . It represents project schedule with respect to time
periods. It is a horizontal bar chart with bars representing activities and time scheduled for the
project activities.
PERT Chart
PERT (Program Evaluation & Review Technique) chart is a tool that depicts project as network
diagram. It is capable of graphically representing main events of project in both parallel and
consecutive way. Events, which occur one after another, show dependency of the later event
over the previous one.
Experiment 3:
Name of the Experiment: Software requirement specification
Aim: To know the concepts of current project and define SRS according to SDLC
Software Requirement Specification

A Software Requirements Specification (SRS) is a complete description of the behavior of the

system to be developed. It includes a set of use cases that describe all the interactions the users
will have with the software. Use cases are also known as functional requirements. In addition to
use cases, the SRS also contains non-functional (or supplementary) requirements. Non-functional
requirements are requirements which impose constraints on the design or implementation (such
as performance engineering requirements, quality standards, or design constraints).

Requirements analysis in systems engineering and software engineering, encompasses those

tasks that go into determining the needs or conditions to meet for a new or altered product, taking
account of the possibly conflicting requirements of the various stakeholders, such as
beneficiaries or users.

Requirements analysis is critical to the success of a development project. Requirements must be

actionable, measurable, testable, related to identified business needs or opportunities, and
defined to a level of detail sufficient for system design. Requirements can be functional and non-
functional.

Conceptually, requirements analysis includes three types of activity:

 Eliciting requirements: the task of communicating with customers and users to determine
what their requirements are. This is sometimes also called requirements gathering.
 Analyzing requirements: determining whether the stated requirements are unclear,
incomplete, ambiguous, or contradictory, and then resolving these issues.
 Recording requirements: Requirements might be documented in various forms, such as
natural-language documents, use cases, user stories, or process specifications.

Requirements analysis can be a long and arduous process during which many delicate
psychological skills are involved. New systems change the environment and relationships
between people, so it is important to identify all the stakeholders, take into account all their
needs and ensure they understand the implications of the new systems. Analysts can employ
several techniques to elicit the requirements from the customer. Historically, this has included
such things as holding interviews, or holding focus groups (more aptly named in this context as
requirements workshops) and creating requirements lists. More modern techniques include
prototyping , and use cases. Where necessary, the analyst will employ a combination of these
methods to establish the exact requirements of the stakeholders, so that a system that meets the
business needs is produced.
In other words it helps the software engineers to identify the exact problem behind the
development of the software and to find the exact requirements for developing the software or
the system.
Software Requirements Specification
for

<Project>

Version 1.0 approved

Prepared by <author>

<organization>

<date created>
Table of Content

1. Introduction ............................................................................................................................13
1.1 Purpose...............................................................................................................................13
1.2 Document Conventions ......................................................................................................13
1.3 Intended Audience and Reading Suggestions ....................................................................13
1.4 Product Scope ....................................................................................................................13
1.5 References ..........................................................................................................................13
2. Overall Description ................................................................................................................13
2.1 Product Perspective ............................................................................................................13
2.2 Product Functions ..............................................................................................................14
2.3 User Classes and Characteristics .......................................................................................14
2.4 Operating Environment ......................................................................................................14
2.5 Design and Implementation Constraints ............................................................................14
2.6 User Documentation ..........................................................................................................14
2.7 Assumptions and Dependencies ........................................................................................14
3. External Interface Requirements .........................................................................................14
3.1 User Interfaces ...................................................................................................................14
3.2 Hardware Interfaces ...........................................................................................................15
3.3 Software Interfaces ............................................................................................................15
3.4 Communications Interfaces ...............................................................................................15
4. System Features .....................................................................................................................15
4.1 System Feature 1 ................................................................................................................15
4.2 System Feature 2 (and so on) ............................................. Error! Bookmark not defined.
5. Other Nonfunctional Requirements Error! Bookmark not defined.
5.1 Performance Requirements ................................................................................................16
5.2 Safety Requirements ..........................................................................................................16
5.3 Security Requirements .......................................................................................................16
5.4 Software Quality Attributes ...............................................................................................16
5.5 Business Rules ................................................................... Error! Bookmark not defined.

6. Other Requirements ..............................................................................................................16

Introduction

Purpose

<Identify the product whose software requirements are specified in this document, including the
revision or release number. Describe the scope of the product that is covered by this SRS,
particularly if this SRS describes only part of the system or a single subsystem.>

Document Conventions

<Describe any standards or typographical conventions that were followed when writing this
SRS, such as fonts or highlighting that have special significance. For example, state whether
priorities for higher-level requirements are assumed to be inherited by detailed requirements, or
whether every requirement statement is to have its own priority.>

Intended Audience and Reading Suggestions

<Describe the different types of reader that the document is intended for, such as developers,
project managers, marketing staff, users, testers, and documentation writers. Describe what the
rest of this SRS contains and how it is organized. Suggest a sequence for reading the document,
beginning with the overview sections and proceeding through the sections that are most
pertinent to each reader type.>

Product Scope

<Provide a short description of the software being specified and its purpose, including relevant
benefits, objectives, and goals. Relate the software to corporate goals or business strategies. If a
separate vision and scope document is available, refer to it rather than duplicating its contents
here.>

References

<List any other documents or Web addresses to which this SRS refers. These may include user
interface style guides, contracts, standards, system requirements specifications, use case
documents, or a vision and scope document. Provide enough information so that the reader
could access a copy of each reference, including title, author, version number, date, and source
or location.>
Overall Description

Product Perspective

<Describe the context and origin of the product being specified in this SRS. For example, state
whether this product is a follow-on member of a product family, a replacement for certain
existing systems, or a new, self-contained product. If the SRS defines a component of a larger
system, relate the requirements of the larger system to the functionality of this software and
identify interfaces between the two. A simple diagram that shows the major components of the
overall system, subsystem interconnections, and external interfaces can be helpful.>
Product Functions

<Summarize the major functions the product must perform or must let the user perform. Details
will be provided in Section 3, so only a high level summary (such as a bullet list) is needed here.
Organize the functions to make them understandable to any reader of the SRS. A picture of the
major groups of related requirements and how they relate, such as a top level data flow diagram
or object class diagram, is often effective.>

User Classes and Characteristics

<Identify the various user classes that you anticipate will use this product. User classes may be
differentiated based on frequency of use, subset of product functions used, technical expertise,
security or privilege levels, educational level, or experience. Describe the pertinent
characteristics of each user class. Certain requirements may pertain only to certain user classes.
Distinguish the most important user classes for this product from those who are less important to
satisfy.>

Operating Environment

<Describe the environment in which the software will operate, including the hardware platform,
operating system and versions, and any other software components or applications with which it
must peacefully coexist.>

Design and Implementation Constraints

<Describe any items or issues that will limit the options available to the developers. These might
include: corporate or regulatory policies; hardware limitations (timing requirements, memory
requirements); interfaces to other applications; specific technologies, tools, and databases to be
used; parallel operations; language requirements; communications protocols; security
considerations; design conventions or programming standards (for example, if the customer’s
organization will be responsible for maintaining the delivered software).>

User Documentation

<List the user documentation components (such as user manuals, on-line help, and tutorials)
that will be delivered along with the software. Identify any known user documentation delivery
formats or standards.>

Assumptions and Dependencies

<List any assumed factors (as opposed to known facts) that could affect the requirements stated
in the SRS. These could include third-party or commercial components that you plan to use,
issues around the development or operating environment, or constraints. The project could be
affected if these assumptions are incorrect, are not shared, or change. Also identify any
dependencies the project has on external factors, such as software components that you intend to
reuse from another project, unless they are already documented elsewhere (for example, in the
vision and scope document or the project plan).>
External Interface Requirements

User Interfaces
<Describe the logical characteristics of each interface between the software product and the
users. This may include sample screen images, any GUI standards or product family style guides
that are to be followed, screen layout constraints, standard buttons and functions (e.g., help) that
will appear on every screen, keyboard shortcuts, error message display standards, and so on.
Define the software components for which a user interface is needed. Details of the user
interface design should be documented in a separate user interface specification.>

Hardware Interfaces

<Describe the logical and physical characteristics of each interface between the software
product and the hardware components of the system. This may include the supported device
types, the nature of the data and control interactions between the software and the hardware,
and communication protocols to be used.>

Software Interfaces

<Describe the connections between this product and other specific software components (name
and version), including databases, operating systems, tools, libraries, and integrated commercial
components. Identify the data items or messages coming into the system and going out and
describe the purpose of each. Describe the services needed and the nature of communications.
Refer to documents that describe detailed application programming interface protocols. Identify
data that will be shared across software components. If the data sharing mechanism must be
implemented in a specific way (for example, use of a global data area in a multitasking
operating system), specify this as an implementation constraint.>

Communications Interfaces

<Describe the requirements associated with any communications functions required by this
product, including e-mail, web browser, network server communications protocols, electronic
forms, and so on. Define any pertinent message formatting. Identify any communication
standards that will be used, such as FTP or HTTP. Specify any communication security or
encryption issues, data transfer rates, and synchronization mechanisms.>
System Features
<This template illustrates organizing the functional requirements for the product by system
features, the major services provided by the product. You may prefer to organize this section by
use case, mode of operation, user class, object class, functional hierarchy, or combinations of
these, whatever makes the most logical sense for your product.>

System Feature 1

<Don’t really say “System Feature 1.” State the feature name in just a few words.>
4.1.1 Description and Priority
<Provide a short description of the feature and indicate whether it is of High, Medium, or
Low priority. You could also include specific priority component ratings, such as
benefit, penalty, cost, and risk (each rated on a relative scale from a low of 1 to a
high of 9).>
4.1.2 Stimulus/Response Sequences
<List the sequences of user actions and system responses that stimulate the behavior
defined for this feature. These will correspond to the dialog elements associated
with use cases.>
 4.1.3 Functional Requirements
<Itemize the detailed functional requirements associated with this feature. These are the
software capabilities that must be present in order for the user to carry out the
services provided by the feature, or to execute the use case. Include how the
product should respond to anticipated error conditions or invalid inputs.
Requirements should be concise, complete, unambiguous, verifiable, and
necessary. Use “TBD” as a placeholder to indicate when necessary information is
not yet available.>

Performance Requirements

<If there are performance requirements for the product under various circumstances, state them
here and explain their rationale, to help the developers understand the intent and make suitable
design choices. Specify the timing relationships for real time systems. Make such requirements
as specific as possible. You may need to state performance requirements for individual
functional requirements or features.>

Safety Requirements

<Specify those requirements that are concerned with possible loss, damage, or harm that could
result from the use of the product. Define any safeguards or actions that must be taken, as well
as actions that must be prevented. Refer to any external policies or regulations that state safety
issues that affect the product’s design or use. Define any safety certifications that must be
satisfied.>

Security Requirements

<Specify any requirements regarding security or privacy issues surrounding use of the product
or protection of the data used or created by the product. Define any user identity authentication
requirements. Refer to any external policies or regulations containing security issues that affect
the product. Define any security or privacy certifications that must be satisfied.>

Software Quality Attributes

<Specify any additional quality characteristics for the product that will be important to either
the customers or the developers. Some to consider are: adaptability, availability, correctness,
flexibility, interoperability, maintainability, portability, reliability, reusability, robustness,
testability, and usability. Write these to be specific, quantitative, and verifiable when possible. At
the least, clarify the relative preferences for various attributes, such as ease of use over ease of
learning.>

Other Requirements
<Define any other requirements not covered elsewhere in the SRS. This might include database
requirements, internationalization requirements, legal requirements, reuse objectives for the
project, and so on. Add any new sections that are pertinent to the project.>
Experiment 4
Preparation of Software Configuration Management and Risk Management related
documents

Configuration management is a process of tracking and controlling the changes in software in

terms of the requirements, design, functions and development of the product.

The process of identifying and defining the items in the system, controlling the change of these
items throughout their life cycle, recording and reporting the status of items and change
requests, and verifying the completeness and correctness of items”.

Generally, once the SRS is finalized there is less chance of requirement of changes from user. If
they occur, the changes are addressed only with prior approval of higher management, as there
is a possibility of cost and time overrun.

Baseline
A phase of SDLC is assumed over if it baselined, i.e. baseline is a measurement that defines
completeness of a phase. A phase is baselined when all activities pertaining to it are finished
and well documented. If it was not the final phase, its output would be used in next immediate
phase.

Configuration management is a discipline of organization administration, which takes care of

occurrence of any change (process, requirement, technological, strategical etc.) after a phase is
baselined. CM keeps check on any changes done in software.

Change Control
Change control is function of configuration management, which ensures that all changes made
to software system are consistent and made as per organizational rules and regulations.

A change in the configuration of product goes through following steps -

 Identification - A change request arrives from either internal or external source. When
change request is identified formally, it is properly documented.

 Validation - Validity of the change request is checked and its handling procedure is
confirmed.
  Analysis - The impact of change request is analyzed in terms of schedule, cost and
required efforts. Overall impact of the prospective change on system is analyzed.

 Control - If the prospective change either impacts too many entities in the system or it is
unavoidable, it is mandatory to take approval of high authorities before change is
incorporated into the system. It is decided if the change is worth incorporation or not. If
it is not, change request is refused formally.

 Execution - If the previous phase determines to execute the change request, this phase
take appropriate actions to execute the change, does a thorough revision if necessary.

 Close request - The change is verified for correct implementation and merging with the
rest of the system. This newly incorporated change in the software is documented
properly and the request is formally is closed.

Risk Management Process

There are following activities involved in risk management process:

 Identification - Make note of all possible risks, which may occur in the project.
 Categorize - Categorize known risks into high, medium and low risk intensity as per
their possible impact on the project.
 Manage - Analyze the probability of occurrence of risks at various phases. Make plan to
avoid or face risks. Attempt to minimize their side-effects.
 Monitor - Closely monitor the potential risks and their early symptoms. Also monitor the
effects of steps taken to mitigate or avoid them.
Sr No Type of Risk Priority Action to be Supporting
taken Document
if any

1 Project
organization
risk

2 Impact risk

3 Requirement
risk

4 Technical
risk

5 Planning
risk
Experiment 5
Study and usage of any Design phase CASE tool

CASE stands for Computer Aided Software Engineering which is software that supports one
or more software engineering activities within a software development process, and is gradually
becoming popular for the development of software as they are improving in the capabilities and
functionality and are proving to be beneficial for the development of quality software.

CASE TOOLS:

Whenever a new system is installed, the implementation integrates a number of related and
different tasks. The process has to be efficiently organized and it is for this very reason that
CASE tools are developed. With the help of CASE, the installation process can be automated
and coordinated within the developed and adopted system life cycle.

CASE tools are the software engineering tools that permit collaborative software development
and maintenance. Almost all the phases of the software development life cycle are supported by
them such as analysis; design, etc., including umbrella activities such as project management,
configuration management etc. In general, standard software development methods such as
Jackson Structure programming or structured system analysis and design method are also
supported by CASE tools. CASE tools may support the following development steps for
developing data base application:

 Creation of data flow and entity models

 Establishing a relationship between requirements and models
 Development of top-level design
 Development of functional and process description
 Development of test cases.

Case Tool used in the software engineering in the design phase to increase the efficiency
of a software the case tool has some properties.

 A standard methodology: A CASE tool must support a standard software development

methodology and standard modeling techniques. In the present scenario most of the
CASE tools are moving towards UML.
 Flexibility: Flexibility in use of editors and other tools. The CASE tool must offer
flexibility and the choice for the user of editors' development environments.
 Strong Integration: The CASE tools should be integrated to support all the stages. This
implies that if a change is made at any stage, for example, in the model, it should get
reflected in the code documentation and all related design and other documents, thus
providing a cohesive environment for software development.
 Integration with testing software: The CASE tools must provide interfaces for
automatic testing tools that take care of regression and other kinds of testing software
under the changing requirements.
  Support for reverse engineering: A CASE tools must be able to generate complex
models from already generated code.
 On-line help: The CASE tools provide an online

CASE TOOL

INRODUCTION TO RATIONAL ROSE

Rational Rose is a powerful visual modeling tool to aid in the analysis and design of object-
oriented software systems. It is used to model your system before you write any code, so you can
be sure that the system is architecturally sound from the beginning. It helps with system analysis
by enabling you to design use cases and Use Case diagrams to show the system functionalities. It
will let you design Interaction diagram to show how the objects work together to provide the
needed functions. Class diagrams can be created to show the classes in a system and how they
relate to each other. Component diagrams can be developed to illustrate how the classes map to
implementation components. Finally, Deployment diagrams can be produced to show the
network design for the system.
Starting Rational Rose
When Rational Rose starts up, the following screen is displayed.
Use Case view The Use Case view is an implementation-independent look at the system. It focuses
on a high-level picture of what the system will do, without worrying about the details of how the
system will do. Use Case view includes:
Actors
Use cases Associations
Use case documentation
Use Case diagrams
Sequence diagrams
Collaboration diagrams
Basic Use Case Diagram Symbols and Notations

System

Draw your system's boundaries using a rectangle that contains use cases. Place actors outside the
system's boundaries.
Use Case

Draw use cases using ovals. Label with ovals with verbs that represent the system's functions.

Actors

Actors are the users of a system. When one system is the actor of another system, label the actor
system with the actor stereotype.

Relationships

Illustrate relationships between an actor and a use case with a simple line. For relationships
among use cases, use arrows labeled either "uses" or "extends." A "uses" relationship indicates
that one use case is needed by another in order to perform a task. An "extends" relationship
indicates alternative options under a certain use case.
Experiment 6

To perform unit testing and integration testing

Unit testing, a testing technique using which individual modules are tested to determine if there
are any issues by the developer himself. It is concerned with functional correctness of the
standalone modules.

The main aim is to isolate each unit of the system to identify, analyze and fix the defects. Unit
testing is a software testing method by which individual units of source code, sets of one or more
computer program modules together with associated control data, usage procedures, and
operating procedures, are tested to determine whether they are fit for use. Intuitively, one can
view a unit as the smallest testable part of an application. Unit tests are created before the code
itself is written. When the tests pass, that code is considered complete. The same unit tests are
run against that function frequently as the larger code base is developed either as the code is
changed or via an automated process with the build. If the unit tests fail, it is considered to be a
bug either in the changed code or the tests themselves. The unit tests then allow the location of
the fault or failure to be easily traced. Since the unit tests alert the development team of the
problem before handing the code off to testers or clients, it is still early in the development
process.

Simplifies integration

Unit testing may reduce uncertainty in the units themselves and can be used in a bottom-
up testing style approach. By testing the parts of a program first and then testing the sum of
its parts, integration testing becomes much easier.

Unit testing provides a sort of living documentation of the system. Developers looking to learn
what functionality is provided by a unit, and how to use it, can look at the unit tests to gain a
basic understanding of the unit's interface

When software is developed using a test-driven approach, the combination of writing the unit
test to specify the interface plus the refactoring activities performed after the test is passing, may
take the place of formal design.

Unit Testing - Advantages:

Reduces Defects in the Newly developed features or reduces bugs when changing the
existing functionality.

Reduces Cost of Testing as defects are captured in very early phase.

Improves design and allows better refactoring of code.

Unit Tests, when integrated with build gives the quality of the build as well.
Integration Testing

The purpose of integration testing is to verify functional, performance, and

reliability requirements placed on major design items. These "design items", i.e.
assemblages (or groups of units), are exercised through their interfaces using black box
testing, success and error cases being simulated via appropriate parameter and data inputs.
Simulated usage of shared data areas and inter-process communication is tested and
individual subsystems are exercised through their input interface. Test cases are
constructed to test whether all the components within assemblages interact correctly, for
example across procedure calls or process activations, and this is done after testing
individual modules, i.e. unit testing. The overall idea is a "building block" approach, in
which verified assemblages are added to a verified base which is then used to support the
integration testing of further assemblages.
Some different types of integration testing are big bang, top-down, and bottom-up. Other
Integration Patterns are: Collaboration Integration, Backbone Integration, Layer Integration,
Client/Server Integration, Distributed Services Integration and High-frequency Integration.

Bottom Up Testing is an approach to integrated testing where the lowest level components are
tested first, then used to facilitate the testing of higher level components. The process is repeated
until the component at the top of the hierarchy is tested.
All the bottom or low-level modules, procedures or functions are integrated and then tested.
After the integration testing of lower level integrated modules, the next level of modules will be
formed and can be used for integration testing. This approach is helpful only when all or most of
the modules of the same development level are ready. This method also helps to determine the
levels of software developed and makes it easier to report testing progress in the form of a
percentage.
Top Down Testing is an approach to integrated testing where the top integrated modules are
tested and the branch of the module is tested step by step until the end of the related module.
Unit testing, a testing technique using which individual modules are tested to determine if there
are any issues by the developer himself. It is concerned with functional correctness of the
standalone modules.

The main aim is to isolate each unit of the system to identify, analyze and fix the defects.
Experiment: 7

To perform various White box and Black Box testing Techniques

Black-box testing
It is carried out to test functionality of the program. It is also called ‘Behavioral’ testing. The tester
in this case, has a set of input values and respective desired results. On providing input, if the output
matches with the desired results, the program is tested ‘ok’, and problematic otherwise.

In this testing method, the design and structure of the code are not known to the tester, and testing
engineers and end users conduct this test on the software.

Black-box testing techniques:

 Equivalence class - The input is divided into similar classes. If one element of a class passes
the test, it is assumed that all the class is passed.

 Boundary values - The input is divided into higher and lower end values. If these values
pass the test, it is assumed that all values in between may pass too.

 Cause-effect graphing - In both previous methods, only one input value at a time is tested.
Cause (input) – Effect (output) is a testing technique where combinations of input values are
tested in a systematic way.

 Pair-wise Testing - The behavior of software depends on multiple parameters. In pairwise

testing, the multiple parameters are tested pair-wise for their different values.

 State-based testing - The system changes state on provision of input. These systems are
tested based on their states and input.
White-box testing
It is conducted to test program and its implementation, in order to improve code efficiency or
structure. It is also known as ‘Structural’ testing.

In this testing method, the design and structure of the code are known to the tester. Programmers of
the code conduct this test on the code.

The below are some White-box testing techniques:

 Control-flow testing - The purpose of the control-flow testing to set up test cases which
covers all statements and branch conditions. The branch conditions are tested for both being
true and false, so that all statements can be covered.

 Data-flow testing - This testing technique emphasis to cover all the data variables included
in the program. It tests where the variables were declared and defined and where they were
used or changed.

Testing Levels
Testing itself may be defined at various levels of SDLC. The testing process runs parallel to
software development. Before jumping on the next stage, a stage is tested, validated and verified.

Testing separately is done just to make sure that there are no hidden bugs or issues left in the
software. Software is tested on various levels -

Unit Testing
While coding, the programmer performs some tests on that unit of program to know if it is error
free. Testing is performed under white-box testing approach. Unit testing helps developers decide
that individual units of the program are working as per requirement and are error free.

Integration Testing
Even if the units of software are working fine individually, there is a need to find out if the units if
integrated together would also work without errors. For example, argument passing and data
updation etc.

System Testing
The software is compiled as product and then it is tested as a whole. This can be accomplished using
one or more of the following tests:

 Functionality testing - Tests all functionalities of the software against the requirement.

 Performance testing - This test proves how efficient the software is. It tests the
effectiveness and average time taken by the software to do desired task. Performance testing
is done by means of load testing and stress testing where the software is put under high user
and data load under various environment conditions.

 Security & Portability - These tests are done when the software is meant to work on
various platforms and accessed by number of persons.

Acceptance Testing
When the software is ready to hand over to the customer it has to go through last phase of testing
where it is tested for user-interaction and response. This is important because even if the software
matches all user requirements and if user does not like the way it appears or works, it may be
rejected.

 Alpha testing - The team of developer themselves perform alpha testing by using the system
as if it is being used in work environment. They try to find out how user would react to
some action in software and how the system should respond to inputs.

 Beta testing - After the software is tested internally, it is handed over to the users to use it
under their production environment only for testing purpose. This is not as yet the delivered
product. Developers expect that users at this stage will bring minute problems, which were
skipped to attend.

Regression Testing
Whenever a software product is updated with new code, feature or functionality, it is tested
thoroughly to detect if there is any negative impact of the added code. This is known as regression
testing.

Testing Documentation
Testing documents are prepared at different stages -

Before Testing
Testing starts with test cases generation. Following documents are needed for reference –

 SRS document - Functional Requirements document

 Test Policy document - This describes how far testing should take place before releasing the
product.

 Test Strategy document - This mentions detail aspects of test team, responsibility matrix
and rights/responsibility of test manager and test engineer.

 Traceability Matrix document - This is SDLC document, which is related to requirement

gathering process. As new requirements come, they are added to this matrix. These matrices
help testers know the source of requirement. They can be traced forward and backward.

While Being Tested

The following documents may be required while testing is started and is being done:

 Test Case document - This document contains list of tests required to be conducted. It
includes Unit test plan, Integration test plan, System test plan and Acceptance test plan.

 Test description - This document is a detailed description of all test cases and procedures to
execute them.

 Test case report - This document contains test case report as a result of the test.

 Test logs - This document contains test logs for every test case report.
Experiment: 8

Name of the Experiment Testing of a web site

In testing website the performance and functions of the website is testing. All the pages of the
websites are testing all the pages are connected with each other and working properly .there are
some points to check the web site,
 Anchor text: Inspect anchor text from internal links for all pages in your website.
 Broken links: Check for broken links, redirects, canonical references, refreshes and
more.
 Keyword content analysis: Detailed page-by-page and site wide keyword content
analysis.
 HTML and CSS errors: HTML/CSS validation ensures pages are crawled and shown
correctly.
 Character sets and MIMEs: If a page outputs this wrong, it can cause various indexing
problems.
 PageRank sculpting: Analyze how internal link juice flows to important pages you need
to rank.
 Page META and titles: Check if all page titles, headers, descriptions and keywords are
unique.
 Canonical and robots: See which URLs are canonical, noindex, nofollow, robots
excluded etc
 Custom search: Search and check all pages for custom text and code, e.g. Google
Analytics.
 Spell check: Check websites for spelling errors using a variety of spell checker
dictionaries.
 File size: Optimize bandwidth usage and download time caused by large pages and
images.
 Response and download time: Stress test webserver with multiple concurrent requests.

To get started on using all these tools, see our complete guide on doing site and SEO audits.

Check Broken Links and Redirects with Link Checker

The website link analysis tools in our program is able to discover broken links and file references
in all HTML and CSS files. You can even have the link extractor of the crawler engine include
Java script code when it searches for and extracts links. Depending on configuration, redirect
and link checking can include references to all file types, e.g. documents, images and videos.
After completing website scan, you are shown all found URLs in a tree like Windows Explorer.
This allows you to quickly find and solve all broken links and redirects. You can view detailed
information on all found items. Need to understand how come a page with error 404 not
found response code is listed? Our program can show you all places that use, link or redirect to
it.
A1 Website Analyzer is a complete link checker solution. Unlike online link checker tools, this
allows testing websites located anywhere including localhost, internet, local file system,
and local area network. There is no fixed limit on pages, links or URLs you can check. Even
budget computers using our website analysis and link checker software can handle well above
100.000 pages and millions of links.

Analyze Website and Internal Link Juice Distribution

Internal links is an important factor for search engine indexing and ranking. If you can improve
the Internal linking structure to focus on important pages with your products and quality content,
it can give you an important boost in search engines.

This process was in the past commonly referred to as PageRank sculpting by people in the search
engine optimization and website marketing industries. At the time, it was widely used to avoid
leaking link juice on outgoing links to low-quality websites by tagging them with the no
follow instruction. These days, it is all about making sure your website distributes link
importance to the important pages in a natural way.
We consider our tool unmatched when it comes to optimizing internal link juice flow for
PageRank sculpting. Experiment with different internal linking structures (e.g. website
navigation and content topic silos) or no follow internal and outgoing links to quickly see how it
effects the way internal link juice is distributed within a website.
A1 Website Analyzer can show how all pages:
 Links to internal.
 Links to external outgoing.
 Linked by internal URLs.
 Calculated importance score.
 Scaled importance score.

The importance score weighs the strength of all links and pages within a website. This means a
link gives more juice if it originates from a highly linked page that contains few links. The scaled
score is logarithmic and have values in range.

Website Analyzer, Link Checker and HTML Validator

 Program can integrate with your favourite online SEM, SEO and website analysis tools.
 Website scan can CSS validate and HTML validate all pages in your website for CSS and
HTML errors.
 Performance and stress test your entire website by configuring crawler behavior and max
load options.
 Automate website scans. Automation support through command line parameters and
Windows Task Scheduler.
 Data collected from website scans are saved or can be exported as XML or CSV. Perfect
for website data mining.
Load and Performance Test Tools
- Load test tool from Agile Load SA for testing all types of web and mobile applications.
Main features include automatic recording of test scenarios, distributed load injectors,
topological and threshold analysis of anomalies, infrastructure monitoring creation of
custom test reports for each user profile. Also available in the EC2 For Web Services,
Html Web 2.0 such as Adobe Flash/Flex, J2EE, .Net, PHP, Mainframe Portals,
ERP/CRM Portals, Microsoft Silverlight, Microsoft Share point.