NRI

INSTITUTE OF TECHNOLOGY

Subject: Software Engineering Lab

Branch : Computer Science & Engineering

Course : B.Tech Year : II-II

Name : K Bharath sai varma

Roll Number : 19KN1A0570

Pothavarappadu (V), Agiripalli(M), Krishna District, A.P. Pin:521212

Ph: (0866) 2469666, (08656) 324999

1
 INDEX

1. Problem Statement Topic Page

3 No
2. Requirement Analysis and Software Requirement Specification 3
2.1 Requirement Analysis 3
2.2 Software Requirement Specification 4
3. Design 7
3.1 Design Document 7
3.2 Study and usage of Design Phase Case Tool 11
4. Testing 15
4.1 Testing Phase Related Documents for the Problems 15
4.2 Unit Testing and Integration Testing 18
4.2.1 Unit Testing 18
4.2.2 Integration Testing 23
4.3 White-Box and Black-Box Testing Techniques 27
4.3.1 White-Box Testing 27
4.3.2 Black-Box Testing 29

2
 AI Diet Consultant

1. Problem statement

Artificial dietitian project is an application with artificial intelligence about human diets. It acts
as a diet consultant similar to a real dietitian. This system acts in a similar way as that of a
dietitian. A person in order to know his/her diet plan needs to give some information to the
dietitian such as its body type, weight, height and working hour details, along with the target
goal they want to reach. Similar way this system also provides the diet plan according to the
information entered by the user. 

The system asks all this data from the user and processes it to provide the diet plan to the user.
Thus the user does not need to visit any dietitian which also saves time and the user can get the
required diet plan in just a click. The project also has a login page where in the user is required to
register. This project requires internet access and thus there is a disadvantage of server failure. 

The system will give more accurate results as it accepts the data entered by the user and
processes it depending on some metrics already known to the application on the basis of which a
diet plan is generated and ask the user if the user accepts the diet plan. If not accepted the system
may also give and alternative diet plan.

2. REQUIREMENT ANALYSIS AND SOFTWARE REQUIREMENT

SPECIFICATION SHEET:

a. Requirement analysis:

Requirements analysis is critical to the success or failure of a systems or software project.

The requirements should be documented, actionable, measurable, testable, traceable,
related to identified business needs or opportunities, and defined to a level of detail
sufficient for system design. Conceptually, requirements analysis includes four types of
activity:
 i. Eliciting requirements: the task of communicating with customers
and users to determine what their requirements are. This is sometimes
also called requirements gathering.
ii. Analyzing requirements: determining whether the stated requirements
are unclear, incomplete, ambiguous, or contradictory, and then
resolving these issues.
iii. Requirements modeling: Requirements might be documented in
various forms, such as natural-language documents, use cases, user
stories, or process specifications.
iv. Review and retrospective: Team members reflect on what happened
in the iteration and identifies actions for improvement going forward.
Requirements analysis is a team effort that demands a combination of hardware, software
and human factors engineering expertise as well as skills in dealing with people. Here are
the main activities involve in requirement analysis:

 Identify customer's needs.

 Evaluate system for feasibility.
 Perform economic and technical analysis.
 Allocate functions to system elements.
 Establish schedule and constraints.
 Create system definitions.

Software requirement specification:

A software requirements specification (SRS) is a document that captures complete

description about how the system is expected to perform. It is usually signed off at the
end of requirements engineering phase.

Qualities of SRS:

 Correct: User review is used to ensure the correctness of requirements stated in the
SRS.
 Unambiguous: Every requirement has exactly one interpretation.
  Complete: Completeness of SRS indicates every sense of completion including the
numbering of all the pages, resolving the problem to be determined parts to as much
extent as possible as well as covering all the functional and non-functional
requirements properly.

 Consistent: Requirements in SRS are said to be consistent if there are no conflicts

between any set of requirements. Examples of conflict include differences in
terminologies used at separate places, logical conflicts like time period of report
generation, etc.

 Ranked for importance and/or stability: There should a criterion to classify the
requirements as less or more important or more specifically as desirable or essential.
An identifier mark can be used with every requirement to indicate its rank or stability.

 Verifiable: A SRS is verifiable if there exists a specific technique to quantifiable

measure the extent to which every requirement is met by the system.

 Modifiable: SRS should be made as modifiable as possible and should be capable of

easily accepting changes to the system to some extent. Modifications should be
properly indexed and cross-referenced.

Traceable: One should be able to trace a requirement to design component and then to
code segment in the program.

SOFTWARE REQUIREMENT SPECIFICATION SHEET:

 INTRODUCTION

AI Diet consultant is an important application, that can be used to get a diet plan suggested to the
user, which is done by taking some personal data such as current weight and height and the target the user
wants to reach. This can be a revolutionary app since we are using AI.

 PURPOSE
 The purpose of this project, is to provide the user with a diet plan. This diet plan is
formulated with the inputs taken from the user. To ensure users convenience, we also made it
possible for the user to remake the plan according to his needs and availability. By following the
diet plan they can reach their ideal fitness level.

 PROJECT SCOPE

AI Diet consultant is an important application, that can be used to get a diet suggested to the user,
which is done by taking some personal data such as current weight and height and the target the
user wants to reach.
 INTENDED AUDIENCE

This application is for people who intend to get into a good shape and the best shape and
want to lead a healthy life eating healthy meals. This app makes it possible for them to become
healthy and fit.

 PRODUCT PERSPECTIVE

This system will use the input given by the user to prepare a meal plan. If the user like it he
can follow the plan given to him. Otherwise the user can remake the meal diet according to his
convenience, without jeopardizing the end goal

 MODULES
 Login
 Enter Details
 Calculation
 Result

1. Login : This project has a login page which allows only the registered user to login
and thereby preventing unauthorized access.

2. Enter Details: The user needs to enter its details such as body type, height, weight.
 3. Calculation: On the basis of details entered by the user, the system process it based on
some metrics
4. Result: After the processing, the result that is the diet plan is displayed to the user.

 FUNCTIONAL REQUIREMENTS
Login and the Enter details are the must fill requirements for the app to work. Without
those the user cannot get the meal plan.
 Software requirements
Windows XP, Windows 7(ultimate, enterprise), Windows 10

HTML, CSS, JS

Visual Studio 2010

 Hardware requirements
 Processor core i3
 Hard disk 5GB
 Memory 1GB

3. DESIGN:
Design document for AI Diet Consultant

OVERVIEW:
There are a lot of individuals who struggle to get on a proper diet and reach their goals in fitness.
They try different things but most of the times they don’t work out so well. The system we
created will help them get the desired diet and reach their fitness goal.

EXISTING SYSTEM:
Dietitians provide diets according to individual needs. For some it works, for some it doesn’t.
Some people may not feel comfortable visiting a dietitian, some may not be able to afford the
consulting fee. This makes the existing system not so reliable.
PROPOSED SYSTEM:
The proposed System will take the required details like height, weight calculate the current body
mass index(BMI) and asks for the users requirement, i.e. the goal weight, and BMI. The system
create a diet according to the users interest and gives him the result. If he want he can remake the
diet plan.

Requirements Modeling :

Analysis Model :

Design Diagrams:
 Use Case Diagram
 Data Model
 Class Model
 Activity Diagram
  SwimLane Diagram
Use Case Diagram For Online Survey System:
A UML use case diagram is the primary form of system /software requirements for
a new software program under developed. Use cases specify the expected behavior, and
not the exact method of making it happen. Use cases once specified can be denoted both
textual and visual representation. A key concept of use case modeling is that it helps us
design a system from the end user's perspective. It is an effective technique for
communicating system behavior in the user's terms by specifying all externally visible
system behavior. Use case diagrams are typically developed in the early stage of
development and people often apply use case modeling for the following purposes:

 Specify the context of a system

 Capture the requirements of a system
 Validate a systems architecture

.
Data Flow Diagram:
DFD graphically representing the functions, or processes, which capture, manipulate,
store, and distribute data between a system and its environment and between components
of a system. The visual representation makes it a good communication tool between User
and System designer. DFD describes the processes that are involved in a system to
transfer data from the input to the file storage and reports generation. Data flow diagrams
can be divided into logical and physical. The logical data flow diagram describes flow of
data through a system to perform certain functionality of a business. The physical data
flow diagram describes the implementation of the logical data flow. DFD has often been
used due to the following reasons:
 Logical information flow of the system
 Determination of physical system construction requirements
 Simplicity of notation
  Establishment of manual and automated systems requirement.

Study and usage of Design Phase Case Tool:

CASE TOOLS:

CASE stands for Computer Aided Software Engineering. It means , development and
maintenance of software projects with help of various automated software tools.
CASE tools are set of software application programs, which are used to automate SDLC
activities. CASE tools are used by software project managers, analysts and engineers to
develop software system.
There are number of CASE tools available to simplify various stages of Software
Development Life Cycle such as Analysis tools, Design tools, Project management tools,
Database Management tools, Documentation tools are to name a few.
Use of CASE tools accelerates the development of project to produce desired result and
helps to uncover flaws before moving ahead with next stage in software development.
Components of CASE Tools:
CASE tools can be broadly divided into the following parts based on their use at a
particular SDLC stage:

Central Repository - CASE tools require a central repository, which can serve as a source
of common, integrated and consistent information. Central repository is a central place of
storage where product specifications , requirement documents , related reports and diagrams
, other useful information regarding management is stored. Central repository also serves as
data dictionary.

 Upper Case Tools - Upper CASE tools are used in planning, analysis and
design stages of SDLC.
 Lower Case Tools - Lower CASE tools are used in implementation, testing
and maintenance.
 Integrated Case Tools - Integrated CASE tools are helpful in all the stages of
SDLC, from Requirement gathering to Testing and documentation.

CASE tools can be grouped together if they have similar functionality, process activities and
capability of getting integrated with other tools.
Scope of Case Tools:
The scope of CASE tools goes throughout the SDLC.
Case Tools Types:
Now we briefly go through various CASE tools

Diagram tools :
These tools are used to represent system components, data and control flow among various
software components and system structure in a graphical form. For example, Flow Chart
Maker tool for creating state-of-the-art flowcharts.

Process Modeling Tools :

Process modeling is method to create software process model, which is used to develop the
software. Process modeling tools help the managers to choose a process model or modify it
as per the requirement of software product. For example, EPF Composer

Project Management Tools :

These tools are used for project planning, cost and effort estimation, project scheduling and
resource planning. Managers have to strictly comply project execution with every
mentioned step in software project management. Project management tools help in storing
and sharing project information in real-time throughout the organization. For example,
Creative Pro Office, Trac Project, Basecamp.

Documentation Tools :
Documentation in a software project starts prior to the software process, goes throughout all
phases of SDLC and after the completion of the project.

Documentation tools generate documents for technical users and end users. Technical users
are mostly in-house professionals of the development team who refer to system manual,
reference manual, training manual, installation manuals etc. The end user documents
describe the functioning and how-to of the system such as user manual. For example,
Doxygen, DrExplain, Adobe RoboHelp for documentation.

Analysis Tools :
These tools help to gather requirements, automatically check for any inconsistency,
inaccuracy in the diagrams, data redundancies or erroneous omissions. For example, Accept
360, Accompa, Case Complete for requirement analysis, Visible Analyst for total analysis.
Design Tools :
These tools help software designers to design the block structure of the software, which
may further be broken down in smaller modules using refinement techniques. These tools
provide detailing of each module and interconnections among modules. For example,
Animated Software Design.

Configuration Management Tools :

An instance of software is released under one version. Configuration Management tools
deal with:

 Version and revision management

 Baseline configuration management
 Change control management

CASE tools help in this by automatic tracking, version management and release
management. For example , Fossil , Git , AccuREV.

Change control tool :

These tools are considered as a part of configuration management tools. They deal with
changes made to the software after its baseline is fixed or when the software is first
released. CASE tools automate change tracking, file management, code management and
more. It also helps in enforcing change policy of the organization.

Programming Tools :
These tools consist of programming environments like IDE (Integrated Development
Environment), in-built modules library and simulation tools. These tools provide
comprehensive aid in building software product and include features for simulation and
testing. For example, Scope to search code in C, Eclipse.

Prototyping Tools :
Software prototype is simulated version of the intended software product. Prototype
provides initial look and feel of the product and simulates few aspects of actual product.
Prototyping CASE tools essentially come with graphical libraries. They can create
hardware independent user interfaces and design. These tools help us to build rapid
prototypes based on existing information. In addition, they provide simulation of software
prototype. For example, Serena prototype composer, Mock-up Builder.

Web Development Tools :

These tools assist in designing web pages with all allied elements like forms, text, script,
graphic and so on. Web tools also provide live preview of what is being developed and how
will it look after completion. For example, Fontello, Adobe Edge Inspect, Foundation 3,
Brackets.

Quality Assurance Tools :

Quality assurance in a software organization is monitoring the engineering process and methods
adopted to develop the software product in order to ensure conformance of quality as per
organization standards. QA tools consist of configuration and change control tools and software
testing tools. For example, SoapTest, AppsWatch, JMeter.

3.TESTING:

TESTING PHASE RELATED DOCUMENTS FOR THE PROBLEMS:

Testing documentation involves the documentation of artefacts that should be developed

before or during the testing of Software.

Documentation for software testing helps in estimating the testing effort required, test
coverage, requirement tracking or tracing, etc. This section describes some of the
commonly used documented artifacts related to software testing such as:

 Test Plan
 Test Scenario
 Test Case
 Traceability Matrix

Test Plan :
A test plan outlines the strategy that will be used to test an application, the resources that
will be used, the test environment in which testing will be performed, and the limitations of
the testing and the schedule of testing activities. Typically, the Quality Assurance Team
Lead will be responsible for writing a Test Plan.
A test plan includes the following:

o Introduction to the Test Plan document

o Assumptions while testing the application
o List of test cases included in testing the application
o List of features to be tested
o What sort of approach to use while testing the software?
o List of deliverables that need to be tested
o The resources allocated for testing the application
o Any risks involved during the testing process
o A schedule of tasks and milestones to be achieved

Test Scenario :
It is a one-line statement that notifies what area in the application will be tested. Test
scenarios are used to ensure that all process flows are tested from end to end. A particular
area of an application can has as little as one test scenario to a few hundred scenarios
depending on the magnitude and complexity of the application.

The terms 'test scenario' and 'test cases' are used interchangeably, however a test scenario
has several steps, whereas a test case has a single step. Viewed from this perspective, test
scenarios are test cases, but they include several test cases and the sequence that they
should be executed. Apart from this, each test is dependent on the output from the previous
test.

Test Case :
Test cases involve a set of steps, conditions, and inputs that can be used while performing
testing tasks. The main intent of this activity is to ensure whether a software passes or fails
in terms of its functionality and other aspects. There are many types of test cases such as
functional, negative, error, logical test cases, physical test cases, UI test cases, etc.

Furthermore, test cases are written to keep track of the testing coverage of a software.
Generally, there are no formal templates that can be used during test case writing. However,
the following components are always available and included in every test case:

 Test case ID
 Product module
 Product version
 Revision history
 Purpose
 Assumptions
 Pre-conditions
 Steps
 Expected Outcome
 Actual Outcome
 Post-conditions

Many test cases can be derived from a single test scenario. In addition, sometimes multiple
test cases are written for a single software which are collectively known as test suites.

Traceability Matrix :
Traceability Matrix (also known as Requirement Traceability Matrix - RTM) is a table that
is used to trace the requirements during the Software Development Life Cycle. It can be
used for forward tracing (i.e. from Requirements to Design or Coding) or backward (i.e.
from Coding to Requirements). There are many user-defined templates for RTM.

Each requirement in the RTM document is linked with its associated test case so that testing
can be done as per the mentioned requirements. Furthermore, Bug ID is also included and
linked with its associated requirements and test case. The main goals for this matrix are:

 Make sure the software is developed as per the mentioned requirements.

 Helps in finding the root cause of any bug.
 Helps in tracing the developed documents during different phases of SDLC.

Unit testing and Integration testing:

UNIT TESTING:

Unit testing is a level of software testing where individual units/ components of a software
are tested. The purpose is to validate that each unit of the software performs as designed. A
unit is the smallest testable part of any software. It usually has one or a few inputs and
usually a single output. In procedural programming, a unit may be an individual program,
function, procedure, etc. In object-oriented programming, the smallest unit is a method,
which may belong to a base/ super class, abstract class or derived/ child class.(Some treat a
module of an application as a unit. This is to be discouraged as there will probably be many
individual units within that module.) Unit testing frameworks, drivers, stubs, and mock/
fake objects are used to assist in unit testing.
Unit Testing Benefits:

 Unit testing increases confidence in changing/ maintaining code. If good unit

tests are written and if they are run every time any code is changed, we
will be able to promptly catch any defects introduced due to the change. Also, if
codes are already made less interdependent to make unit testing possible, the
unintended impact of changes to any code is less.
 Codes are more reusable. In order to make unit testing possible, codes need to
be modular. This means that codes are easier to reuse.
 Development is faster. How? If you do not have unit testing in place, you write
your code and perform that fuzzy ‘developer test’ (You set some breakpoints, fire
 up the GUI, provide a few inputs that hopefully hit your code and hope that you
are all set.) But, if you have unit testing in place, you write the test, write the
code and run the test. Writing tests takes time but the time is compensated by
the less amount of time it takes to run the tests; You need not fire up the GUI and
provide all those inputs. And, of course, unit tests are more reliable than
‘developer tests’. Development is faster in the long run too. How? The effort
required to find and fix defects found during unit testing is very less in
comparison to the effort required to fix defects found during system testing or
acceptance testing.
 The cost of fixing a defect detected during unit testing is lesser in comparison to
that of defects detected at higher levels.
 Debugging is easy. When a test fails, only the latest changes need to be
debugged. With testing at higher levels, changes made over the span of several
days/weeks/months need to be scanned.
 Codes are more reliable. Why? I think there is no need to explain this to a sane
person.

Unit Testing Tips:

 Find a tool/framework for your language.

 Do not create test cases for everything. Instead, focus on the tests that impact
the behavior of the system.
 Isolate the development environment from the test environment.
 Use test data that is close to that of production.
 Before fixing a defect, write a test that exposes the defect. Why? First, you will
later be able to catch the defect if you do not fix it properly. Second, your test
suite is now more comprehensive. Third, you will most probably be too lazy to
write the test after you have already fixed the defect.
 Write test cases that are independent of each other. For example, if a class
depends on a database, do not write a case that interacts with the database to
test the class. Instead, create an abstract interface around that database
 connection and implement that interface with a mock object.
 Aim at covering all paths through the unit. Pay particular attention to loop conditions.
 Make sure you are using a version control system to keep track of your test scripts.
 In addition to writing cases to verify the behavior, write cases to ensure the
performance of the code.
 Perform unit tests continuously and frequently.

Unit Testing Techniques :

Code coverage techniques used in unit testing are listed below:

 Statement Coverage
 Decision Coverage
 Branch Coverage UNIT TESTING SCREENSHOTS:

SCREENSHOT OF MAIN PAGE:

INTEGRATION TESTING:

Integration testing is a level of software testing where individual units are combined and
tested as a group. The purpose of this level of testing is to expose faults in the interaction
between integrated units. Test drivers and test stubs are used to assist in Integration
Testing . Definition by ISTQB :

 integration testing: Testing performed to expose defects in the interfaces and in

the interactions between integrated components or systems. See also component
integration testing, system integration testing.
 component integration testing: Testing performed to expose defects in the
interfaces and interaction between integrated components.
 system integration testing: Testing the integration of systems and packages;
testing interfaces to external organizations (e.g. Electronic Data Interchange,
Internet).

ANALOGY:
During the process of manufacturing a ballpoint pen, the cap, the body, the tail and clip,
the ink cartridge and the ballpoint are produced separately and unit tested separately.
When two or more units are ready, they are assembled and Integration Testing is
performed. For example , whether the cap fits into the body or not.
METHOD:
Any of Black Box Testing , White Box Testing and Gray Box Testing methods can be
used. Normally, the method depends on your definition of ‘unit’.
TASKS :

 Integration Test Plan

o Prepare
o Review
o Rework
 Baseline Integration Test Cases/Scripts
o Prepare
o Review
o Baseline

Integration Testing is the second level of testing performed after Unit Testing and
before System Testing Developers themselves or independent testers perform Integration
Testing. Integration testing is a level of software testing where individual units are
combined and tested as a group. The purpose of this level of testing is to expose faults in
the interaction between integrated units. Test drivers and test stubs are used to assist in
integration testing. helps in better test coverage too and improves test gaps. Tests are more
reliable and easy to isolate the failures. Majorly helps to build real-time use cases during
the end to end testing
APPROACHES:

 Big Bang is an approach to Integration Testing where all or most of the units are
combined together and tested at one go. This approach is taken when the testing
team receives the entire software in a bundle. So what is the difference between
Big Bang Integration Testing and System Testing? Well, the former tests only the
interactions between the units while the latter tests the entire system.
 Top Down is an approach to Integration Testing where top-level units are tested
first and lower level units are tested step by step after that. This approach is taken
when top-down development approach is followed. Test Stubs are needed to
 simulate lower level units which may not be available during the initial phases.
 Bottom-up testing is an approach to integrated testing where the lowest level
components are tested first, then used to facilitate the testing of higher level
components. The process is repeated until the component at the top of the
hierarchy is tested. All the bottom or low-level modules, procedures or functions
are integrated and then tested. After the integration testing of lower level
integrated modules, the next level of modules will be formed and can be used for
integration testing. This approach is helpful only when all or most of the modules
of the same development level are ready. This method also helps to determine the
levels of software developed and makes it easier to report testing progress in the
form of a percentage.
 Sandwich/Hybrid is an approach to Integration Testing which is a combination of Top
Down and Bottom Up approaches.
TIPS:
 Ensure that you have a proper Detail Design document where interactions
between each unit are clearly defined. In fact, you will not be able to perform
Integration Testing without this information.
 Ensure that you have a robust Software Configuration Management system in
place. Or else, you will have a tough time tracking the right version of each unit,
especially if the number of units to be integrated is huge.
 Make sure that each unit is unit tested before you start Integration Testing.
 As far as possible, automate your tests, especially when you use the Top Down or
Bottom Up approach, since regression testing is important each time you integrate
a unit, and manual regression testing can be inefficient.
WHITE-BOX AND BLACK-BOX TESTING TECNIQUES :

White-Box Testing:

White-box tests are used to examine the procedural details. It checks the logical paths by
test case. It can also check the conditions, loops used in the software coding. It checks that
loops are working correctly on defined boundary value.

White-box testing sometimes called glass-box testing, is a test case design method that
users the control structure of the procedural design to drive the test case. Always we are
thinking that there is no necessary to execute or checks the loops and conditions. And so
large number of errors is uncovered . With using white-box testing methods, we have
checked that; all independent paths within a function have been executed at least once, all
logical decisions on their true and false side, A11 loops working correctly at their boundary
values and within their specified conditions.

In our coding we test that all the loops work truly in each module. The one technique of
white-box testing is basis path testing. It contains two parts; one is flow graph notation and
the second is cyclometer complexity. In flow graph notation we are checking logical control
of flow. By using cyclometer complexity, we find complexity of our project structure.

Levels Applicable To
White Box Testing method is applicable to the following levels of software testing:

 Unit Testing : For testing paths within a unit.

 Integration Testing : For testing paths between units.
 System Testing : For testing paths between subsystems.

Advantages:

 Testing can be commenced at an earlier stage. One need not wait for the GUI
to be available.
 Testing is more thorough, with the possibility of covering most paths.

Disadvantages :

 Since tests can be very complex, highly skilled resources are required,
with a thorough knowledge of programming and implementation.
 Test script maintenance can be a burden if the implementation changes too
frequently.
 Since this method of testing is closely tied to the application being tested,
tools to cater to every kind of implementation/platform may not be readily
available.

Black-Box Testing:

Black-box tests are used to demonstrate that software functions are operational, that input is
properly accepted and output is correctly produced, and that integrity of external
information is maintained.

Black-box testing focuses on the functional requirements of the software. That is black-box
testing enables the software engineer to drive sets of input conditions that will fully exercise
all functional Requirements for the program. Black-box testing is not an alternative to
white- box testing techniques. Rather, it is a complementary approach that is likely to
uncover a different class of errors than white-box methods.
We use in our coding to find errors in the following categories:

 Incorrect or missing functions

 Interface errors
 Errors in database
 Performance errors
 Initialization and termination errors.

Unlike white-box testing, which is performed earlier in the testing process, black-box
testing tends to be applied during later stages of testing. Because black-box testing
purposely disregards control structure, attention is focused on the information domain.

By applying black-box techniques, we derive a set of test cases that satisfy following
criteria test cases that reduce, by a count that is greater than one, the number of additional
test cases must be designed to achieve reasonable testing.

Level 1 - Build Acceptance Tests :

Other related test cases ensure that adopters received the proper Development Release
Document plus other build related information (drop point, etc.). The objective is to
determine if further testing is possible. If any Level 1 test case fails, the build is returned to
developers un-tested.

Level 2 - Smoke Tests:

The objective is to determine if further testing is possible. These test cases should
emphasize breadth more than depth. All components should be touched, and every major
feature should be tested briefly by the Smoke Test. If any Level 2 test case fails, the build is
returned to developers un-tested.

Level 2a - Bug Regression Testing :

Every bug that was “Open” during the previous build, but marked as “Fixed, Needs Re-
Testing” for the current build under test, will need to be regressed, or re-tested. Once the
smoke test is completed, all resolved bugs need to be regressed. It should take between 5
minutes to 1 hour to regress most bugs.

Level 3 - Critical Path Tests :

Critical Path test cases must pass by the end of every 2-3 Build Test Cycles. They do not
need to be tested every drop, but must be tested at least once per milestone. Thus, the
Critical Path test cases must all be executed at least once during the Iteration cycle, and
once during the Final Release cycle.

Level 4 - Standard Tests :

Test Cases that need to be run at least once during the entire test cycle for this release.
These cases are run once, not repeated as are the test cases in previous levels. Functional
Testing and Detailed Design Testing (Functional Spec and Design Spec Test Cases,
respectively).These can be tested multiple times for each Milestone Test Cycle. Standard
test cases usually include Installation, Data, GUI, and other test areas.

Level 5 - Suggested Test :

These are Test Cases that would be nice to execute, but may be omitted due to time
constraints

Bug Regression:
Bug Regression will be a central tenant throughout all testing phases. When a Severity one
bug fails regression, adopters testing team should also put out an immediate email to
development. The Test Lead will be responsible for tracking and reporting to development
and product management the status of regression testing.

Programmers think that Integration Testing will catch all errors and do not execute the unit
test. Once units are integrated, very simple errors which could have very easily found and
fixed in unit tested take a very long time to be traced and fixed.