Lab Manual

Software Testing & Quality

SUBJECT PROGRAMME B. Tech.
assurance

SUBJECT CODE BTCS3503 SEMESTER VI

DURATION OF
CREDITS
SEMESTER 24 Weeks

PREREQUISITE CSE101 (Software SESSION

SUBJECTS DURATION 2 Hrs per Week
Engineering)

APPROVED BY:

DEAN/HOD

1. VISION AND MISSION OF GALGOTIAS UNIVERSITY

VISION
 To be known globally for value-based education, research, creativity and innovation

MISSION

 Establish state-of-the-art facilities for world class education and research.

 Collaborate with industry and society to align the curriculum.
 Involve in societal outreach programs to identify concerns and provide sustainable ethical solutions.
 Encourage life-long learning and team-based problem solving through an enabling environment.

2. VISION AND MISSION OF DEPARTMENT

VISION

 To be known globally as a premier department of computer science and engineering for value-based
education, multi-disciplinary research and innovation.

MISSION

 Create a strong foundation on fundamentals of computer science and engineering through outcome based
teaching- learning process.
 Establish state-of-art facilities for analysis design and implementation to develop sustainable ethical
solution.
 Conduct multi-disciplinary research for developing innovative solution
 Involve the students in group activity including that of professional bodies to develop leadership and
communication skills.

3. PROGRAM EDUCATIONAL OBJECTIVES

PEO1 Graduates of Computer Science and Engineering will be globally competent and
provide sustainable solutions for interdisciplinary problems as team players
Graduates of Computer Science and Engineering will engage in professional
PEO2 activities with ethical practices in the field of Computer Science and Engineering
to enhance their own stature to contribute towards society
Graduates of Computer Science and Engineering will acquire specialized
PEO3 knowledge in emerging technologies for research, innovation and product
development.

4. PROGRAMME OUTCOMES

Engineering knowledge: Apply the knowledge of mathematics, science,

PO1 engineering fundamentals, and an engineering specialization to the solution of
complex engineering problems.
Problem analysis: Identify, formulate, review research literature, and analyze
PO2 complex engineering problems reaching substantiated conclusions using first
principles of mathematics, natural sciences, and engineering sciences.
Design/development of solutions: Design solutions for complex engineering
PO3 problems and design system components or processes that meet the specified
needs with appropriate consideration for the public health and safety, and the
cultural, societal, and environmental considerations.
Conduct investigations of complex problems: Use research-based knowledge
PO4 and research methods including design of experiments, analysis and interpretation
of data, and synthesis of the information to provide valid conclusions
Modern tool usage: Create, select, and apply appropriate techniques, resources,
PO5 and modern engineering and IT tools including prediction and modeling to
complex engineering activities with an understanding of the limitations.
The engineer and society: Apply reasoning informed by the contextual
PO6 knowledge to assess societal, health, safety, legal and cultural issues and the
consequent responsibilities relevant to the professional engineering practice.
Environment and sustainability: Understand the impact of the professional
PO7 engineering solutions in societal and environmental contexts, and demonstrate the
knowledge of, and need for sustainable development
PO8 Ethics: Apply ethical principles and commit to professional ethics and
responsibilities and norms of the engineering practice.
PO9 Individual and team work: Function effectively as an individual, and as a
member or leader in diverse teams, and in multidisciplinary settings.
Communication: Communicate effectively on complex engineering activities
PO10 with the engineering community and with society at large, such as, being able to
comprehend and write effective reports and design documentation, make effective
presentations, and give and receive clear instructions.
Project management and finance: Demonstrate knowledge and understanding
PO11 of the engineering and management principles and apply these to one’s own
work, as a member and leader in a team, to manage projects and in
multidisciplinary environments.
Life-long learning: Recognize the need for, and have the preparation and ability
PO12 to engage in independent and life-long learning in the broadest context of
technological change.
 Programme specifics Outcome (PSO)
PSO1 Able to analyze, design and implement sustainable and ethical solutions in the
field of computer science.
PSO2 Able to use problem solving skills to develop efficient algorithmic solutions.

5. EXPERIMENTAL SETUP DETAILS FOR THE COURSE

Software Requirements
 Intel Pentium , Turbo C

Hardware Requirements
 No specific requirements. Any computer Hardware capable of running DOS can be used for this course.

EXPERIMENT LIST
 Sr.No Title of Lab Experiments
1. Understanding an SRS .

2. Make a Use case diagram for railway reservation system

3. Make an ER diagram for Library management system.

4. To prepare DATA FLOW DIAGRAM for any project.

5. Introduction to software testing and quality assurance.

6To determine the nature of roots of a quadratic equation, its input is triple of +ve integers (say
x,y,z) and values may be from interval [1,100]. The program output may have one of the
following:-
a. Not a quadratic equation b. Real roots
c. Imaginary roots d. Equal Roots
Design the boundary value test cases.

To
7 determine the type of triangle. Its input is triple of +ve integers (say x ,y,z) and the values may
be from interval[1,100].The program output may be one of the following [Scalene, Isosceles,
Equilateral, Not a Triangle]. Perform BVA.

8WAP in C/C++ to find the area of a circle, Triangle, Square and Rectangle and perform

9.Perform different level of testing for your application

10 Study of Any Test Management Tool (QA Complete).

11 Perform software development and software testing in Banking system

12 Perform software development and software testing in e commerce

6. COURSE OUTCOMES (COs):

Course outcomes (COs)
 CO1 Understand the key concerns that are common to software Engineering &
development processes.
CO2 Understand the approaches implementing in Software Testing
Select appropriate process models, approaches and techniques to manage a
CO3 Error-free software.

CO4 Recognize the importance of software Maintenance & Software Testing Tools
reliability and how we can Testing software and what measures are used.
CO5 Understand the Software Quality Assurance (SQA) architecture and identify
Software quality management standards and procedures
CO6 Gain understanding of latest trends and research areas in the course

7. CO-PO-PSO MAPPING:
CO's PO1 PO2 PO3 PO4 PO5 PO6 PO7 PO8 PO9 PO10 PO11 PO12 PSO1 PSO2
CO1 3 1 2 2 1 1 1 1
CO2 3 2 2 1 2 2
CO3 2 3 2 3 2 2 1 2 2
CO4 3 1 2 2 2 1 2 1
CO5 3 1 1 2 3 1 1 2 1
CO6 2 2 1 1 2 1 1

7.1 Relationship between the COs and Program Outcomes Pos with experiments:
S. Course Outcomes Mapped Program Outcomes Mapping of Rubrics
 No for mapping course
. outcomes
Understand the key Exp No. 1,2,3,4,5
concerns that are common Mid-term internal
1 to software Engineering & PO1, PO2, PO3, PO6, PO10, PO12 PSO1, PSO2 evaluation,
development processes. End-term external
evaluation
Understand the Exp No. 6, 7
approaches implementing Mid-term internal
2 PO1, PO2, PO3, PO12, PSO1, PSO2
in Software Testing evaluation, End-term
external evaluation
Select appropriate
process models,
Exp No. 8, 12
approaches and
PO1, PO2, PO3, PO4, PO5, PO6, PO9, PSO1, End- term internal
3 techniques to manage PSO2 evaluation, End-term
a Error-free external evaluation
software.

Recognize the importance

of software Maintenance & Exp No. 9, 10,
Software Testing Tools End- term internal
4 PO1, PO2, PO3, PO4, PO5, PO10, PSO1, PSO2
reliability and how we can evaluation, End-term
Testing software and what external evaluation
measures are used.
Understand the Software
Quality Assurance (SQA) Exp No. 11,12
architecture and identify End- term internal
5 PO1,PO2,PO3,PO4,PO5,PO10,OP12,PSO1,PSO2
Software quality evaluation, End-term
management standards and external evaluation
procedures
Gain understanding of
6 latest trends and research PO1, PO2, PO3, PO4, PO5, PSO1, PSO2
areas in the course

8. LAB EVALUATION SCHEME

 Component of evaluation Internal/external Rubric for CO Marks

Continuous evaluation R0 20

Pre-final lab test Internal R1 20

R3(Theory, tools,
Internal viva 10 (2+4+4)
Result interpretation )

ETE Lab test R1 20

Lab Report External R2 20

External Viva R3(Theory, tools, 10(2+4+4)

Result interpretation)

Total: 100

8.1 R0 : Rubrics for continuous evaluation

S.
Rubrics - Parts Marks
No.
1 Able to define the problem statement 2
2 Able to convert the problem statement into program 3
3 Implementation 5
4 Compile and Interpret the results 5
5 Viva – voce 5
Total 20

8.2 R1 : Internal Lab Test

Maximum Marks: 20
Level of Achievement
Assessment Parameter Ma
Very Good
Excellent (4) Fair (2) Poor (1) ppe
(3)
d
CO
a Identify Demonstrates Adequate Superficial Lack of CO
appropriate tests, deep Knowledge Knowledge Knowledge information 1
procedures and of algorithms and of most of about most of
algorithms/tools Procedure; Algorithms algorithms the algorithms
Answer the and and and
related questions procedures procedures; procedures;
with explanations answer the able to cannot even
and elaboration related answer only answer basic
questions, some of the related
 but fails to related basic
questions
elaborate Questions
Define the Define the Define the
problems problems problems with
Define the
with full with full insufficient
problems with
justification justification systems
full justification
Implementation of and and knowledge CO
b and implement
problem Statement implement implement and 2
the systems that
the system the system implement the
works perfectly
that does not that does system that
alright
give 100% not give does not give
results results results
Adequate
insight but
Little
missed some
insight and No insight
important
Excellent insight analyzed and entirely
points in
and well focused only the missed the
results and
result and most basic point of the
discussion;
discussion; Data points; experiment;
Result Analysis and interpreted CO
c completely and Interpreted little or no
Data Interpretation most data 3
appropriately some data attempt to
correctly but
interpreted and no correctly but interpret data
some
over- significant or over-
conclusions
interpretation errors, interpreted
may be
omissions data.
suspect or
still present
over-
interpreted

8.3 R2: Lab Report

Maximum Marks: 20
Level of Achievement
Assessment Mapped
Excellent(4) Very Good (3) Fair (2) Poor (1)
Parameter CO
Coding is
Coding is
complete,
complete and Coding is brief
relevant
Executed and missing
Program and (Achieved all the
successfully significant No program
a Result requirements) CO4
but failed in requirement of reported
Representation and Executed
representing problem
successfully.
result statement;
result discussion
discussion.
was clear.
Organization of Lab report is Lab report is Report
Poor
Report and well organized well contains few
organizatio
b Timely as directed and organized but errors and not CO5
n and late
Submission submitted on not submitted on
submission
Result time submitted on time
 Representation
time
and Discussion

8.4 R3: Viva

Level of Achievement
Assessment Very Good Mapped
Excellent (4) Fair (2) Poor (1)
Parameter (3) CO
Knowledge of
theory of
a CO1
practical
problems

Implementation
b CO2
logics

c Execution CO5

8.5 Internal lab Assessment format

GALGOTIAS UNIVERSITY
Department of Computer Science and Engineering
Assessment of Internal lab Test
Subject Code : Subject Name:
Session : Class :
Date : Max. Marks :
Knowledge of
S. Execution and Total
Enrollment Algorithms and
No Name of the Student Result (10) (20)
No. Procedures (10)
1.
2.
3.
4.
5.
 6.
7.

8.6 Continuous Assessment Format

Internal Lab Assessment (End Semester)

Continuous Internal
S. Enrol. Name of the Total Marks
assessment Assessment
No. No. Student (50) (in words)
(30) Test (20)
1.
2.
3.
4.
5.
6.
7.
8.

9. EXPERIMENT WRITE UPS

 EXPERIMENT DETAILS

EXCERCISE NO. 1

Aim: Understanding an SRS.

Requirements:

Hardware Requirements:

 PC with 300 megahertz or higher processor clock speed recommended; 233 MHz minimum required.
 128 megabytes (MB) of RAM or higher recommended (64 MB minimum supported)
 1.5 gigabytes (GB) of available hard disk space
 CD ROM or DVD Drive
 Keyboard and Mouse(compatible pointing device).

Software Requirements:

Rational Rose, Windows XP,

Theory:

An SRS is basically an organization's understanding (in writing) of a customer or potential client's system
requirements and dependencies at a particular point in time (usually) prior to any actual design or development
work. It's a two-way insurance policy that assures that both the client and the organization understand the other's
requirements from that perspective at a given point in time.

The SRS document itself states in precise and explicit language those functions and capabilities a software system
(i.e., a software application, an eCommerce Web site, and so on) must provide, as well as states any required
constraints by which the system must abide. The SRS also functions as a blueprint for completing a project with
as little cost growth as possible. The SRS is often referred to as the "parent" document because all subsequent
project management documents, such as design specifications, statements of work, software architecture
specifications, testing and validation plans, and documentation plans, are related to it.

It's important to note that an SRS contains functional and nonfunctional requirements only; it doesn't offer design
suggestions, possible solutions to technology or business issues, or any other information other than what the
development team understands the customer's system requirements to be.

A well-designed, well-written SRS accomplishes four major goals:

 It provides feedback to the customer. An SRS is the customer's assurance that the development
organization understands the issues or problems to be solved and the software behavior necessary to
address those problems. Therefore, the SRS should be written in natural language (versus a formal
language, explained later in this article), in an unambiguous manner that may also include charts, tables,
data flow diagrams, decision tables, and so on.
  It decomposes the problem into component parts. The simple act of writing down software requirements in
a well-designed format organizes information, places borders around the problem, solidifies ideas, and
helps break down the problem into its component parts in an orderly fashion.
 It serves as an input to the design specification. As mentioned previously, the SRS serves as the parent
document to subsequent documents, such as the software design specification and statement of work.
Therefore, the SRS must contain sufficient detail in the functional system requirements so that a design
solution can be devised.
 It serves as a product validation check. The SRS also serves as the parent document for testing and
validation strategies that will be applied to the requirements for verification.

SRSs are typically developed during the first stages of "Requirements Development," which is the initial
product development phase in which information is gathered about what requirements are needed--and not.
This information-gathering stage can include onsite visits, questionnaires, surveys, interviews, and perhaps a
return-on-investment (ROI) analysis or needs analysis of the customer or client's current business
environment. The actual specification, then, is written after the requirements have been gathered and analyzed.

SRS should address the following

The basic issues that the SRS shall address are the following:

a) Functionality. What is the software supposed to do?

b) External interfaces. How does the software interact with people, the system’s hardware, other
hardware, and other software?
c) Performance. What is the speed, availability, response time, recovery time of various software
functions, etc.?
d) Attributes. What are the portability, correctness, maintainability, security, etc. considerations?
e) Design constraints imposed on an implementation. Are there any required standards in effect,
implementation language, policies for database integrity, resource limits, operating environment(s) etc.?

Chracteristics of a good SRS

An SRS should be

a) Correct
b) Unambiguous
c) Complete
d) Consistent
e) Ranked for importance and/or stability
f) Verifiable
g) Modifiable
h) Traceable

Correct - This is like motherhood and apple pie. Of course you want the specification to be correct. No one
writes a specification that they know is incorrect. We like to say - "Correct and Ever Correcting." The discipline is
keeping the specification up to date when you find things that are not correct.
Unambiguous - An SRS is unambiguous if, and only if, every requirement stated therein has only one
interpretation. Again, easier said than done. Spending time on this area prior to releasing the SRS can be a waste
of time. But as you find ambiguities - fix them.

Complete - A simple judge of this is that is should be all that is needed by the software designers to create the
software.

Consistent - The SRS should be consistent within itself and consistent to its reference documents. If you call an
input "Start and Stop" in one place, don't call it "Start/Stop" in another.

Ranked for Importance - Very often a new system has requirements that are really marketing wish lists. Some
may not be achievable. It is useful provide this information in the SRS.

Verifiable - Don't put in requirements like - "It should provide the user a fast response." Another of my favorites
is - "The system should never crash." Instead, provide a quantitative requirement like: "Every key stroke should
provide a user response within 100 milliseconds."

Modifiable - Having the same requirement in more than one place may not be wrong - but tends to make the
document not maintainable.

Traceable - Often, this is not important in a non-politicized environment. However, in most organizations, it is
sometimes useful to connect the requirements in the SRS to a higher level document. Why do we need this
requirement?

A sample of basic SRS Outline

1. Introduction
1.1 Purpose
1.2 Document conventions
1.3 Intended audience
1.4 Additional information
1.5 Contact information/SRS team members
1.6 References

2. Overall Description
2.1 Product perspective
2.2 Product functions
2.3 User classes and characteristics
2.4 Operating environment
2.5 User environment
2.6 Design/implementation constraints
2.7 Assumptions and dependencies

3. External Interface Requirements

3.1 User interfaces
3.2 Hardware interfaces
3.3 Software interfaces
3.4 Communication protocols and interfaces
4. System Features
4.1 System feature A
4.1.1 Description and priority
4.1.2 Action/result
4.1.3 Functional requirements
4.2 System feature B

5. Other Nonfunctional Requirements

5.1 Performance requirements
5.2 Safety requirements
5.3 Security requirements
5.4 Software quality attributes
5.5 Project documentation
5.6 User documentation

6. Other Requirements
Appendix A: Terminology/Glossary/Definitions list
Appendix B: To be determined

Conclusion: The SRS was made successfully by following the steps described above.

Experiment no.2

Title Make a Use case diagram for railway reservation system/ ATM

Objective It will provide students graphical overview of the functionality provided by the system.

Prerequis Knowledge of UML

ite
Theory Use case diagram is a platform that can provide a common understanding for the end-users,
developers and the domain experts. It is used to capture the basic functionality i.e. use cases, and the
users of those available functionality, i.e. actors, from a given problem statement.

In this experiment, we will learn how use cases and actors can be captured and how different use
cases are related in a system.

Use case diagrams

Use case diagrams belong to the category of behavioral diagram of UML diagrams. Use case
diagrams aim to present a graphical overview of the functionality provided by the system. It consists
of a set of actions (referred to as use cases) that the concerned system can perform one or more actors,
and dependencies among them.

Actor

An actor can be defined as an object or set of objects, external to the system, which interacts with the
system to get some meaningful work done. Actors could be human, devices, or even other systems.
For example, consider the case where a customer withdraws cash from an ATM. Here, customer is a
human actor.

Actors can be classified as below:

 Primary actor: They are principal users of the system, who fulfill their goal by availing some
service from the system. For example, a customer uses an ATM to withdraw cash when he
needs it. A customer is the primary actor here.
 Supporting actor: They render some kind of service to the system. "Bank representatives",
who replenishes the stock of cash, is such an example. It may be noted that replenishing stock
of cash in an ATM is not the prime functionality of an ATM.

In a use case diagram primary actors are usually drawn on the top left side of the diagram.

Use Case

A use case is simply functionality provided by a system.

Continuing with the example of the ATM, withdraw cash is a functionality that the ATM provides.
Therefore, this is a use case. Other possible use cases include, check balance, change PIN, and so on.

Use cases include both successful and unsuccessful scenarios of user interactions with the system. For
example, authentication of a customer by the ATM would fail if he enters wrong PIN. In such case,
an error message is displayed on the screen of the ATM.

Subject

Subject is simply the system under consideration. Use cases apply to a subject. For example, an ATM
is a subject, having multiple use cases, and multiple actors interact with it. However, one should be
careful of external systems interacting with the subject as actors.
Graphical Representation

An actor is represented by a stick figure and name of the actor is written below it. A use case is
depicted by an ellipse and name of the use case is written inside it. The subject is shown by drawing a
rectangle. Label for the system could be put inside it. Use cases are drawn inside the rectangle, and
actors are drawn outside the rectangle, as below:

Association between Actors and Use Cases

A use case is triggered by an actor. Actors and use cases are connected through binary associations
indicating that the two communicates through message passing.

An actor must be associated with at least one use case. Similarly, a given use case must be associated
with at least one actor. Associations among the actors are usually not shown. However, one can depict
the class hierarchy among actors.

Use Case Relationships

Three types of relationships exist among use cases:

 Include relationship
 Extend relationship
 Use case generalization

Include Relationship

Include relationships are used to depict common behavior that are shared by multiple use cases. This
could be considered analogous to writing functions in a program in order to avoid repetition of
writing the same code. Such a function would be called from different points within the program.

Example

For example, consider an email application. A user can send a new mail, reply to an email he has
received, or forward an email. However, in each of these three cases, the user must be logged in to
perform those actions. Thus, we could have a login use case, which is included by compose mail,
reply, and forward email use cases. The relationship is shown in figure - 02.
 Generalization relationship is depicted by a solid arrow from the specialized (derived) use case to the
more generalized (base) use case.

Identifying Actors

Given a problem statement, the actors could be identified by asking the following questions :

 Who gets most of the benefits from the system? (The answer would lead to the identification
of the primary actor)
 Who keeps the system working? (This will help to identify a list of potential users)
 What other software / hardware does the system interact with?
 Any interface (interaction) between the concerned system and any other system?

Identifying Use cases

Once the primary and secondary actors have been identified, we have to find out their goals i.e. what
the functionality they can obtain from the system is. Any use case name should start with a verb like,
"Check balance".

Guidelines for drawing Use Case diagrams

Following general guidelines could be kept in mind while trying to draw a use case diagram:

 Determine the system boundary

 Ensure that individual actors have well-defined purpose
 Use cases identified should let some meaningful work done by the actors
 Associate the actors and use cases -- there shouldn't be any actor or use case floating without
any connection
 Use include relationship to encapsulate common behavior among use cases , if any

Sample Use case diagrams for the chosen project is captured using above mentioned basics
Output
 Experiment No:3

Title Modeling E-R diagram for the chosen project.

Objective Students will be able to create a logical design of database for real world objects

Prerequis Knowledge of UML

ite

Theory
Introduction

Developing databases is a very important task to develop a system. Before going to form exact
database tables and establishing relationships between them, we conceptually or logically can model
our database using ER diagrams.

In this experiment we will learn how to find the entities, its attributes and how the relationships
between the entities can be established for a system.

Entity Relationship Model

Entity-Relationship model is used to represent a logical design of a database to be created. In ER

model, real world objects (or concepts) are abstracted as entities, and different possible associations
among them are modeled as relationships.

For example, student and school -- they are two entities. Students study in school. So, these two
entities are associated with a relationship "Studies in".

As another example, consider a system where some job runs every night, which updates the database.
Here, job and database could be two entities. They are associated with the relationship "Updates".

Entity Set and Relationship Set

An entity set is a collection of all similar entities. For example, "Student" is an entity set that abstracts
all students. Ram, John are specific entities belonging to this set. Similarly, a "Relationship" set is a
set of similar relationships.

Attributes of Entity

Attributes are the characteristics describing any entity belonging to an entity set. Any entity in a set
can be described by zero or more attributes.

For example, any student has got a name, age, an address. At any given time a student can study only
at one school. In the school he would have a roll number, and of course a grade in which he studies.
These data are the attributes of the entity set Student.

Keys

One or more attribute(s) of an entity set can be used to define the following keys:

 Super key: One or more attributes, which when taken together, helps to uniquely identify an
entity in an entity set. For example, a school can have any number of students. However, if we
know grade and roll number, then we can uniquely identify a student in that school.
 Candidate key: It is a minimal subset of a super key. In other words, a super key might
 EXCERCISE NO. 4

AIM: To prepare DATA FLOW DIAGRAM for any project.

REQUIREMENTS:

Hardware Interfaces

 Pentium(R) 4 CPU 2.26 GHz, 128 MB RAM

 Screen resolution of at least 800 x 600 required for proper and complete viewing of screens. Higher
resolution would not be a problem.
 CD ROM Driver

Software Interfaces

 Any window-based operating system (Windows 95/98/2000/XP/NT)

 WordPad or Microsoft Word

THEORY
Data flow diagrams illustrate how data is processed by a system in terms of inputs and outputs.
Data Flow Diagram Notations
You can use two different types of notations on your data flow diagrams: Yourdon & Coad or Gane & Sarson.

Process Notations

Yourdon and Coad

Process Notations

Gane and Sarson

Process Notation
Process
A process transforms incoming data flow into outgoing data flow.
 Datastore Notations

Yourdon and Coad

Datastore Notations

Gane and Sarson

Datastore Notations
DataStore
Datastores are repositories of data in the system. They are sometimes also referred to as files.

Dataflow Notations

Dataflow
Dataflows are pipelines through which packets of information flow. Label the arrows with the name of the data
that moves through it.

HOW TO DRAW DATA FLOW DIAGRAMS (cont'd)

Data Flow Diagram Layers

Draw data flow diagrams in several nested layers. A single process node on a high level diagram can be expanded
to show a more detailed data flow diagram. Draw the context diagram first, followed by various layers of data
flow diagrams.
 The nesting of data flow layers

Context Diagrams
A context diagram is a top level (also known as Level 0) data flow diagram. It only contains one process node
(process 0) that generalizes the function of the entire system in relationship to external entities.
 External Entity Notations

External Entity
External entities are objects outside the system, with which the system communicates. External entities are
sources and destinations of the system's inputs and outputs.

DFD levels
The first level DFD shows the main processes within the system. Each of these processes can be broken into
further processes until you reach pseudocode.

An example first-level data flow diagram

Conclusion: The dataflow diagram was made successfully by following the steps described above.
Experiment 1

AIM: Introduction to software testing and quality assurance.

➔ Software
Software is a set of instructions and its documentation that tells a computer what
to do or how to perform a task. Software includes all different software programs
on a computer, such as applications and the operating system.
Examples : Adobe Photoshop, MacOS, Google Chrome, etc.

➔ Program
A computer program is a list of instructions that tell a computer what to do.
Everything a computer does is done by using a computer program. A computer
program is written in a programming language. Programs stored in the memory of
a computer enable the computer to perform tasks in sequence or even
intermittently.

Example:
import random
print(‘Random Dice
Roll: ’) N =
random.randint(1, 6)
print(N)

➔ Software Engineering
 Software engineering is an engineering branch associated with the
development of software products using well-defined scientific principles,
methods and procedures Objectives of Software Engineering :
➢ Maintainability
➢ Correctness
➢ Reusability
➢ Testability
➢ Reliability
➢ Portability

➔ V-Model
The V-model is an SDLC model where execution of processes happens in a
sequential manner in a V-shape. It is also known as the Verification and
Validation model.
The V-Model is an extension of the waterfall model and is based on the
association of a testing phase for each corresponding development stage. This
means that for every single phase in the development cycle, there is a directly
associated testing phase. This
 is a highly-disciplined model and the next phase starts only after completion of
the previous phase.

➔ Software Testing
Software testing is the process of verifying a system with the purpose of
identifying any errors, gaps or missing requirements versus the actual
requirement. Software testing is broadly categorised into two types - functional
testing and non-functional testing.
The process of software testing aims not only at finding faults in the existing
software but also finding measures to improve the software in terms of efficiency,
accuracy and usability.

➔ Software Testing Process

We can divide the activities within the fundamental test process into the following
basic steps:
➢ Planning and Control
○ Test planning involves producing a document that describes an overall
approach and test objectives. It involves reviewing the test basis,
identifying the test conditions based on analysis of test items, writing
test cases and Designing the test environment.
➢ Analysis and Design
○ To review the test basis. The test basis is the information on which
test cases are based, such as requirements, design specifications,
product risk analysis, architecture and interfaces
○ To identify test conditions
○ To design the tests
➢ Implementation and Execution
 ○ Test execution involves actually running the specified test on a
computer system either manually or by using an automated test tool. It
is a Fundamental Test Process in which actual work is done.
➢ Evaluating exit criteria and Reporting
○ To assess if more test are needed or if the exit criteria specified should be
changed
○ To write a test summary report for stakeholders
➢ Test closure
○ To check which planned deliverables are actually delivered and to
ensure that all incident reports have been resolved
○ To finalize and archive testware such as scripts, test environments,
etc. for later reuse
○ To handover the testware to the maintenance organization. They will
give support to the software
➔ Quality Assurance
Quality Assurance is defined as an activity to ensure that an organization is
providing the best possible product or service to customers. QA focuses on
improving the processes to deliver Quality Products to the customer. An
organization has to ensure that processes are efficient and effective as per the
quality standards defined for software products.

➔ Quality Control
It is a Software Engineering process used to ensure quality in a product or a
service. It does not deal with the processes used to create a product; rather it
examines the quality of the "end products" and the final outcome. The main aim
of Quality control is to check whether the products meet the specifications and
requirements of the customer. If an issue or problem is identified, it needs to be
fixed before delivery to the customer. QC also evaluates people on their quality
level skill sets and imparts training and certifications.
➔ Why should we test?
The testing is important since it discovers defects/bugs before the delivery to the
client, which guarantees the quality of the software. It makes the software more
reliable and easy to use. Thoroughly tested software ensures reliable and high-
performance software operation. Without proper testing, we could potentially
release software which could malfunction and cause serious injuries.
If software testing is not done, it can lead to major software failures like Year
2000 problem, Patriot Missile Error, etc.

➔ Who should do the testing?

It depends on the process and the associated stakeholders of the project(s).
In the IT industry, large companies have a team with responsibilities to
evaluate the developed software in context of the given requirements.
Professionals who test software include QA Analysts, Test Engineers, Test
Analysts, Software Testers, SQA, Quality Assurance, Performance Testers,
Usability Testers.

➔ What should we test?

We would want that worse conditions should occur in the very beginning of the
project only than in the later phases.
Test the common case of everything you can. This will tell you when that code
breaks after you make some change. Test the edge cases of a few unusually
complex code that you think will probably have errors. Whenever you find a bug,
write a test case to cover it before fixing it. Add edge-case tests to less critical
code whenever someone has time to kill.

➔ Verification and Validation

Verification involves the evaluation of artifacts of software development to
ensure that the product being developed will comply with its requirements.
Verification involves the evaluation of artifacts of software development to ensure
that the product being developed will comply with its requirements. It involves
activities like document review, test cases review, walk-throughs, inspection etc.

Validation involves validation of a developed software product to check if it

conforms to the specified business requirements. It involves dynamic testing of a
software product by running it. It involves activities like functional testing,
automation testing etc.
➔ Error, Bug, Fault and Failure
➢ Error
○ Any incorrect human action that produces a problem in the system is
called error. A person can make an error (mistake), which can lead
to introduction of a defect (fault or bug).
○ Error may occur because of time pressure, human fallibility,
Inexperienced or insufficient people on project,
miscommunication, technology constraint, complexity of project.
➢ Bug
○ Occurs due to coding error.
○ These are fatal errors that could block a functionality,
○ results in a crash, or cause performance bottlenecks
➢ Fault
○ Fault can be caused just because of error or can be defined as
the representation of errors.
○ Problems like an invalid step, lack of resources or inappropriate
data definition could cause a fault in a program.
➢ Failure
○ Whenever fault executes failure occur or the deviation identified by the
end user while execution is called as failure. When user expectation is
not met it is a failure. If a defect in a code is executed that can lead to
failure, but not necessarily in all circumstances.
➔ Deliverables and Milestones
A milestone is a term related to a schedule. Similar to milestones on a road,
project milestones tell you where you are in the project schedule. These control
points help identify that a number of tasks or key deliverables have been
completed allowing you to move on to the next phase of your project.
A deliverable is just another word for a product that is planned to be supplied to
certain project stakeholders for their perusal. It may be an intermediate product
for comments, or a final product.

➔ Alpha, Beta and Acceptance Testing

➢ Acceptance testing is performed to determine whether or not the software
system has met the requirement specifications. The main purpose of this test is
to gauge whether the application meets the intended specifications and
satisfies the client’s requirements.
➢ Alpha Testing is a type of software testing performed to identify bugs before
releasing the product to real users or to the public. Unit testing, integration
testing and system testing when combined are known as alpha testing.
➢ Beta Testing is performed by real users of the software application in a
real environment. In beta testing a sample of the intended audience tests
the application. Beta testing is also known as pre-release testing.

➔ Quality and Reliability

Quality is the degree to which something is fit for purpose or how well something
performs its functions. For example, a high speed train that is fast, energy
efficient, safe, comfortable and easy to operate might be considered high quality.
 Reliability is defined as the probability that a product, system, or service will
perform its intended function adequately for a specified period of time, or will
operate in a defined environment without failure.. For example, a high speed train
that is durable for 20 years and remains safe in high winds and earthquakes.

➔ Static and Dynamic Testing

➢ Static Testing is a type of testing in which the code is not executed. It can be
done manually or by a set of tools. This type of testing checks the code,
requirement documents and design documents and puts review comments
on the work document.
➢ Dynamic testing is done when the code is in operation mode. Dynamic testing
is performed in a runtime environment. When the code being executed is input
with a value, the result or the output of the code is checked and compared with
the expected output.

➔ White box and Black box testing

White box testing is when we test the internal structure of a software module: the
code itself. White-box testing is also called glass testing or open-box testing. It is
usually performed by the team members who know the code, usually developer.
Since the developers have an in-depth understanding of the project code, they
are capable of making the changes in the source code easily and in a small time.
Techniques included in white-box testing :
➢ Control Flow Testing
➢ Data Flow testing
➢ Statement coverage
➢ Path testing

Black box testing is a type of testing in which the tester only focuses on the
inputs and the expected outputs, without knowing how the application works
internally and how
 these inputs are processed. Tester treats the Application Under Test (AUT) as a
black box.
Techniques included in black-box testing :
➢ Regression Testing
➢ Functional Testing

➔ Why is 100% testing not possible?

100% testing is often not possible due to the following reasons:
➢ The domain of possible inputs of a program is too large to be completely used
in testing a system. There are both valid inputs and invalid inputs.
➢ The program may have a large number of states. There may be timing
constraints on the inputs, that is, an input may be valid at a certain time and
invalid at other times. An input value which is valid but is not properly timed
is called an inopportune input.
➢ The input domain of a system can be very large to be completely used in
testing a program.
➢ The design issues may be too complex to completely test. The design may have
included implicit design decisions and assumptions. For example, a
programmer may use a global variable or a static variable to control program
execution.
➢ It may not be possible to create all possible execution environments of the
system. This becomes more significant when the behavior of the software
system depends on the real, outside world, such as weather, temperature,
altitude, pressure, and so on.

➔ Limitations of testing
Limitations to software testing depend upon many factors:
➢ Money - Software testing requires a considerable amount of money in order
to upkeep a product.
➢ Time constraint - Testing is a huge part of the software development
process and requires a considerable amount of time to assure the quality of a
product.
➢ Number of Resources - This is related to time constraint. More testers
and human resources are needed to meet a deadline.
 ➢ Dedicated Staging Environment - It is a tough job to maintain a
stage environment or QA environment as close as possible to the
Production environment.
➢ How much to automate? - You cannot automate 100% business process. So
a thorough evaluation is needed on that part.
➢ False Positives and False Negatives - This is in respect to automation
testing. False positive is a case where in spite of a bug the automation script
yields a positive result. A false negative is vice-versa.

➔ Six Sigma Concept

Six Sigma is a disciplined, statistical-based, data-driven approach and
continuous improvement methodology for eliminating defects in a product,
process or service. Sigma represents the population standard deviation, which is
a measure of the variation in a data set collected about the process. If a defect is
defined by specification limits separating good from bad outcomes of a process,
then a six sigma process has a process mean (average) that is six standard
deviations from the nearest specification limit.
 Experiment 6

Aim:
A. To determine the nature of roots of a quadratic equation, its input is triple of +ve integers
(say x,y,z) and values may be from interval [1,100]. The program output may have one of
the following:-
a. Not a quadratic equation
b. Real roots
c. Imaginary roots
d. Equal roots
Design the boundary value test cases.

Algorithm:
1. Take 3 inputs corresponding to coefficients of the quadratic equation.
2. Check whether the inputs lie in a given domain.
3. If coefficients are not representative of a quadratic equation, STOP.
4. Else check the value of discriminant of given equation.
5. If the discriminant is greater than 0, roots are real and different.
6. Else if discriminant is equal to 0, roots are real and equal.
7. Else if discriminant is less than 0, roots are imaginary/complex.
8. Print total test cases = 4n+1, n: number of inputs.

Code:
#include <iostream>
#include <math.h>
using namespace
std;

int bva(int a, int b, int

c) { if (a==0) {
cout << "not a quadratic\
n"; return 0;
}
int d = b*b - 4*a*c;
double sqrt_val = sqrt(abs(d));
cout << a << "\t" << b << "\t" << c << "\
t"; if(d < 0) {
cout << "Imaginary Roots\t\t";
 cout << -(double)b / (2*a) << "+i"<<sqrt_val << ",
"; cout << -(double)b/(2*a) << "-i"<<sqrt_val <<
endl;
} else if(d == 0) {
cout << "real and equal\t\t";
cout << - (double) b / (2*a) << endl;
} else
{ cout << "Real and Distinct\t";
cout << (double) (-b + sqrt_val)/(2*a);
cout << ", " << (double) (-b - sqrt_val)/(2*a) << endl;

}
return 0;
}

int main() {
int min, max;

cout << "Enter range" <<

endl; cin >> min >> max;

if(min < 0 || max > 100) {

cout << "Invalid range"
<<endl; printf("Invalid
range\n"); return 0;
}

int nominal = (min + max)/2;

int values[] = {min, min+1, nominal, max-1, max};

cout << "a\tb\tc\tOutput\t\t\tRoots" <<

endl; for(int i=0;i<5;i++) {
bva(values[i],nominal, nominal);
}

for(int i=0;i<5;i++) {
if(values[i] !=
nominal)
bva(nominal, values[i], nominal);
}

for(int i=0;i<5;i++) {
if(values[i] !=
nominal)
bva(nominal, nominal, values[i]);
}

return 0;
}
Output

Boundary Value Analysis:

Input range: [1, 100]

Minimum Above Nominal Below Maximum

Minimum Maximum

a 1 2 50 99 100

b 1 2 50 99 100

c 1 2 50 99 100

Test cases

Test Case a b c Expected

1 1 50 50 Real & Distinct

2 2 50 50 Real & Distinct

3 50 50 50 Imaginary

4 99 50 50 Imaginary

5 100 50 50 Imaginary

6 50 1 50 Imaginary
 7 50 2 50 Imaginary

8 50 50 50 Imaginary

9 50 99 50 Imaginary

10 50 100 50 Real & Equal

11 50 50 1 Real & Distinct

12 50 50 2 Real and Distinct

13 50 50 50 Imaginary

14 50 50 99 Imaginary

15 50 50 100 Imaginary

Test cases 3, 8 and 13 are redundant. Hence, total number of test cases are 15 - 2 = 13 = 4*n + 1 [n=3].
 Experiment 7

Aim:
To determine the type of triangle. Its input is triple of +ve integers (say x,y,z) and the
values may be from interval[1,100].The program output may be one of the following
[Scalene, Isosceles, Equilateral, Not a Triangle]. Perform BVA.

Algorithm:
1. Take 3 inputs corresponding to three sides of the triangle.
2. Check whether the inputs lie in a given domain.
3. If sides are not representative of a triangle, STOP.
4. Else check the relation between given sides.
5. If all sides are equal, the triangle is equilateral.
6. Else if 2 sides are equal the triangle is isosceles.
7. Else if no sides are equal, the triangle is scalene.
8. Print total test cases = 4n+1, n: number of inputs.

Code:
#include <iostream>
#include <math.h>
using namespace
std;

int bva(int a, int b, int c) {

cout << a << "\t" << b << "\t" << c;

if (((a+b)>c) && ((b+c) > a) && ((c+a) >

b)) { if ((a==b) && (b==c)) {
cout << "\tEquilateral" << endl;
}
else if ((a==b) || (b==c) ||
(c==a)) { cout << "\tIsosceles"
<< endl;
}
else {
cout << "\tScalene" << endl;
}
return 0;
}
else {
cout << "\tNot a triangle" << endl;
 return 0;
}

int main() {
int min, max;

cout << "Enter range" <<

endl; cin >> min >> max;

if(min < 0 || max > 100) {

cout << "Invalid range"
<<endl; printf("Invalid
range\n"); return 0;
}

int nominal = (min + max)/2;

int values[] = {min, min+1, nominal, max-1, max};

cout << "a\tb\tc\tExpected output" <<

endl; for(int i=0;i<5;i++) {
bva(values[i],nominal, nominal);
}

for(int i=0;i<5;i++) {
if(values[i] != nominal)
bva(nominal, values[i], nominal);
}

for(int i=0;i<5;i++) {
if(values[i] != nominal)
bva(nominal, nominal, values[i]);
}

return 0;
}
Output

Boundary Value Analysis:

Input range: [1, 100]

Minimum Above Nominal Below Maximum

Minimum Maximum

a 1 2 50 99 100

b 1 2 50 99 100

c 1 2 50 99 100

Test cases

Test Case a b c Expected

1 1 50 50 Isosceles

2 2 50 50 Isosceles

3 50 50 50 Equilateral

4 99 50 50 Isosceles
 5 100 50 50 Not a triangle

6 50 1 50 Isosceles

7 50 2 50 Isosceles

8 50 50 50 Equilateral

9 50 99 50 Isosceles

10 50 100 50 Not a triangle

11 50 50 1 Isosceles

12 50 50 2 Isosceles

13 50 50 50 Equilateral

14 50 50 99 Isosceles

15 50 50 100 Isosceles

Test cases 3, 8 and 13 are redundant. Hence, total number of test cases are 15 - 2 = 13 = 4*n + 1 [n=3].
 Experiment 8

Aim:
A. WAP in C/C++ to find the area of a circle, Triangle, Square and Rectangle and perform
equivalence class testing.

Algorithm:
1. Display Menu with choices for Circle, Triangle, Square, Rectangle
2. Take user input
3. If choice=1, take radius as input and calculate area of circle
4. Else if choice=2, take height and base of triangle as input and calculate area of triangle.
5. Else if choice=3, take side of square as input and calculate area of square.
6. Else if choice=4, take height and width of rectangle as input and calculate area of
rectangle.
7. Else if choice=5, STOP.
8. Else, display wrong choice

Code:
#include<iostream>
using namespace
std;

void menu()
{
cout << endl << "1. Area of circle" <<
endl; cout << "2. Area of triangle" <<
endl;
cout << "3. Area of square" << endl;
cout << "4. area of rectangle" <<
endl; cout << "5. Exit" << endl;
}

void result(int choice)

{
switch (choice)
{ case 1: {
int r;
cout << "Enter radius"
<<endl; cin >> r;
if ((r<1)||(r>100)) {
cout << "Invalid range" <<
 }
cout << "Area of circle is: " << 3.14*r*r <<
endl; break;
}
case 2: {
int h, b;
cout << "Enter base and height" <<
endl; cin >> b >> h;
if (((h<1) || (h>100)) || ((b<1) ||
(b>100))) { cout << "Invalid range" <<
endl;
break;
}
cout << "Area of triangle is " << 0.5*b*h <<
endl; break;
}
case 3: {
int s;
cout << "Enter side:" <<
endl; cin >> s;
if ((s<1) || (s>100)) {
cout << "Invalid
range"<<endl; break;
}
cout << "Area of square " << s*s <<
endl; break;
}
case 4: {
int h,w;
cout << "Enter width and height" <<
endl; cin >> w >> h;
if (((h<1) || (h>100)) || ((w<1) ||
(w>100))) { cout << "Invalid range" <<
endl;
break;
}
cout << "Area of rectangle is " << w*h <<
endl; break;
}
case 5:
break;
default: {
cout << "Wrong input" <<endl;
}

}
}

int main()
{
int choice;
do {
menu();
 cin >> choice;
result(choice);
} while (choice != 5);

return 0;
}

Output
Equivalence Class Testing:

➔ Case 1: Circle
◆ Input Domain

Input Class Domain

I1 r: r<=0

I2 r: r>100

I3 r: 1 <= r <= 100

◆ Output Domain

Output Class Domain

O1 Circle if 1<=r<=100

O2 Not a circle if r<0

◆ Test Cases

r Expected Output

0 Invalid input

5 50.24

101 Invalid input

➔ Case 2: Triangle
◆ Input Domain

Input Class Domain

I1 h: h<=0

I2 h: h>100

I3 h: 1<= h <= 100

 I4 b: b<=0

I5 b: b > 100

I6 b: 1<=b<=100

◆ Output Domain

Output Class Domain

O1 Triangle if h,b >0

O2 Not a triangle otherwise

◆ Test Cases

h b Expected Output

0 8 Invalid Input

2 3 3

101 8 Invalid input

2 0 Invalid input

3 2 3

3 101 Invalid input

➔ Case 3: Square
◆ Input Domain

Input Class Domain

I1 s: s<=0

I2 s: s>100

I3 s: 1 <= s <= 100

◆ Output Domain
 Output Class Domain

O1 Square if 1<=r<=100

O2 Not a square if r<0

◆ Test Cases

s Expected Output

0 Invalid input

5 25

101 Invalid input

➔ Case 4: Rectangle
◆ Input Domain

Input Class Domain

I1 h: h<=0

I2 h: h>100

I3 h: 1<= h <= 100

I4 b: b<=0

I5 b: b > 100

I6 b: 1<=b<=100

◆ Output Domain

Output Class Domain

O1 Rectangle if h,b >0

O2 Not a rectangle otherwise

◆ Test Cases

h b Expected Output

0 8 Invalid Input

2 3 6

101 8 Invalid input

2 0 Invalid input

3 2 6

3 101 Invalid input

 EXPERIMENT NO. 9
Perform different level of testing for your application
 EXPERIMENT-10

Aim:- a) Study of Any Test Management Tool (QA Complete).

Introduction: Take the guess work out of the software delivery lifecycle. Provide your QA and
development teams with the power to collaborate, track project progress, and report on
requirements, test cases, and defects.
QA Complete allows you to take a strategic approach to testing by prioritizing key test functions,
accounting for risk, planning for coverage, and controlling test execution. Employing effective
test case management helps you ensure you’re running the right tests, and thus avoid releasing an
application that is not customer-ready.
Key Features:
Test Case Management:
The ability to organize, plan, and analyze your testing efforts across the lifecycle is critical to
your success or failure whether you use manual or automated test cases today. As projects cope
with fewer development resources, higher quality expectations, and shorter development
timelines, any serious development effort needs better test case management. QA Complete
delivers.
● Manage manual test cases and link them back to the original requirements, thereby
ensuring a requirement has been met. Evaluate the test run history of those automated
tests right from QA Complete.
● Employ re-usable manual test libraries to quickly create new test scenarios.
● Graphically report automated test runs with plug-ins for many leading automated testing
tools, including Test Complete and HP Quick Test Pro (QTP).
● Organize your test library any way you like: by component, functional area, release, or
Agile sprint.
● Add, print, edit, or email test cases with a single click.
Test Automation Tool Integrations:
QA Complete supports many automated testing tools, including Automated QA Test Complete
and HP Quick Test Pro. Integration with test automation tools allows you review the run history
of any automated test on any machine, so if you have a test lab with multiple machines running
automated tests, you can compare machine run history. Since you can co-ordinate both manual
and automated tests, you have better test information to make release decisions.
By integrating automated testing into QA Complete, you can:
● Launch the tests from within your automated tool and automatically report the run
information to QA Complete for analysis of runs over time.
● Trend results using graphical dashboards and schedule tests to run unattended.
Bi-Directional Traceability:
The goal of traceability is to ensure “adequate” test coverage for each software requirement. It is
important to maintain traceability both forwards and backwards, from requirement to test case
 and from test case to requirement. This ensures that design specifications are appropriately
verified and that requirements are appropriately validated, ultimately reducing software defects
and – this is the ultimate goal, after all – improving code quality.
● Link together requirements, test cases, and reported defects.
● Drag and drop functionality to link test cases or defects to a requirement.
● With one click, see a traceability report showing all linkages to a particular requirement.
Requirements Management:
QA Complete helps you manage requirements regardless of your team’s development
methodology. It lets you define requirements for each release and track the release for which
each requirement is scheduled. Govern workflow and state transitions. Using workflow, you can
force design reviews, approvals, or test reviews.
● Easily set rules for status transitions.
● Automatically assign tasks to team members based on requirement status; receive email
alerts when requirements change.
● Attach documents to any requirement (such as detail designs, specifications, and
prototypes), and track versions of those documents.
● Add notes to the requirement, allowing the team to discuss requirement changes and
other important issues.
● View an audit history of any requirement, showing who made a change, the date and time
of the change, and the before-and-after values.
● Rely on an extensive set of standard and ad-hoc dashboards and reports (requirements
missing test cases, etc.)
Defect and Issue Tracking:
QA Complete allows you to track status and resolution progress of defects and issues for each
release. Instead of spending your time entering data, the software automatically generates a
defect identifier on failed test cases. Integration with Atlassian JIRA, Bugzilla, and other web-
based defect tracking tools allow you to blend QA Complete features with the defect tracking
tools your organization already uses.
● Coordinate QA and development teams to coordinate activities as bugs are found. QA
Complete has a full featured defect tracking component.
● If your team already owns a bug tracking system (like JIRA, Bugzilla, Microsoft TFS,
etc.), you can create defects inside of QA Complete and have those automatically
synchronized with your bug tracking system.
● Source code integration lets you associate source code with fixed defects. By doing this,
you can quickly discover which code modules are the most buggys, allowing your team
to put effort into raising the quality of that code.
● Defect reports and dashboards show defects by severity, priority, or other criteria.

Seamless Integration with other ALM tools:

 If your team has already sunk costs into an existing requirements or defect management tools, it
may be difficult to convince your team to switch. With QA Complete, you don’t have to switch.
QA Complete can seamlessly integrate with many defects and ALM tools including Microsoft
Team Foundation Server (TFS), HP Quality Center, IBM Rational Doors, IBM Rational
Requisite Pro, Rational Team Concert, Atlassian JIRA, Rally, Version One, Bugzilla, and Accept
360.

Seamless Integration with Source Control Systems:

Associating defects and requirements with source code provides great traceability, allowing you
to quickly discover troublesome code and requirements that required the most re-work. Using the
QA Complete SCM integrators, you can associate defects or requirements when checking in
source code.

Extensive Dashboards and Reporting for QA Activities:

QA Complete provides an array of analysis tools. Status screens, dashboards, and reports help
you stay on track, better plan your next release, and answer the most pressing questions about
your software development projects. For example:
● Are you progressing properly in your test cycle? The Test Case Trending dashboard
shows how many test cases are still awaiting ru n, how many passed, and how many have
failed, day-by-day.
● Which tester has the most assigned defects? View a Defect Assignee report that shows
defects by assignee. Click the assignee graph to get further details, print, export to Word,
Excel or PDF, or email the results.
● Review team and project variances, allowing you to you learn from each project as to
improve future estimates.

Easy Data Entry:

QA Complete makes it easy for you to automatically generate a defect from a failed test case.
With one-click cloning of records, you can pass along to your development team all the relevant
steps to reproduce the problem, along with expected and actual results, without having to re-enter
anything.
● Automatically create a link between the defect and the test case.
● Existing test cases linked to a requirement automatically link the defect to the
requirement as well for full traceability.

Flexible Licensing Model:

 Our QA Complete SaaS offering allows you to focus on your core business activities while
keeping costs down. Our online option means you don’t have to mess with server configuration,
hardware support, or other data center annoyances. Sign up to get up and running immediately
and leave the hosting to us.
● On-demand, available anytime, from anywhere.
● Sign up and turn it on with no implementation effort.
● Safe and secure Data Center.
● For those who would prefer to host the software, or are unable to use a SaaS model, we
also offer an on-premise option. Both are backed by our outstanding and friendly support
staff.

Web-Based User Interface:

QA Complete has a Web interface. Nothing needs to be installed on your hard drive.
● Users with an Internet connection may access QA Complete from home or anywhere in
the world.
● Distributed and offshore teams can easily share QA artifacts with one another and local
teams.
● Supports all major browsers, including Internet Explorer, Fire Fox, Safari, and Google
Chrome.
 Experiment no 11

Perform software development and software testing in Banking system

Experiment no 12

Perform software development and software testing in e commerce.