GALGOTIAS UNIVERSITY

School of Computer Science and Engineering

Lab Manual

Name Aman Kumar Pandey PROGRAMME B. Tech.

SUBJECT CODE BTCS3503 SEMESTER V

SUBJECT Software Testing &

Quality assurance Admission No 20SCSE1010067

SUBMITTED TO Section 7
 INDEX

Signature
Sr.No Title of Lab Experiments Date

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.

6 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: -
ot a quadratic equation b. Real roots
maginary roots d. Equal Roots
Design the boundary value test cases.

7 etermine 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.

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

9. form 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

 EXPERIMENT 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

Software Requirements:

Rational Rose, Windows XP,

Theory:

An SRS is 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 is 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 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 is important to note that an SRS contains functional and nonfunctional requirements only; it does not offer design
suggestions, workable 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 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 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 is 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.?

Characteristics of a good SRS

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 it 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, do not 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?

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

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

Objective To get a graphical overview of the functionality provided by the system.

Prerequisite Knowledge of UML

Theory Use case diagram is a platform that can provide a mutual 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 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.
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 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 must 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 should not be any actor or use case floating
without any connection
 Use include relationship to encapsulate common behavior among use cases if any

Sample
Output
 EXPERIMENT - 3
Title Modeling E-R (Entity Relationship) 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 an 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 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 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:
Sample
Output
 EXPERIMENT - 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.
times 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.
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 5

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.
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 categorized 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 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 is 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 delivered and to ensure that all
incident reports have been resolved
○ To finalize and archive test ware such as scripts, test environments,
etc. for later reuse
○ To handover the test ware 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 must 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; it examines
the quality of the "end products" and the 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.
 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 each 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
 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 each 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
 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" << endl;
break;
 }
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
 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 are 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, reducing software defects and – this is the 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 critical 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 (Team
Foundation Server),
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 do not 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 run 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 do not 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.