STQA

(SOFTWARE TESTING AND QUALITY ASSURANCE)

Assignment

Submitted to- Submitted by-

Dr. Deepak panwar Abhay Pratap singh tomar
B.Tech CSE
Sec- A
VIII SEM
A20405216082
Q. Explain the requirement analysis phase of you final year project
(Disease prognostication).
Sol. Software specification or requirements engineering is the process of understanding
and defining what services are required from the system and identifying the constraints
on the system’s operation and development. Requirements engineering is a particularly
critical stage of the software process as errors at this stage unavoidably lead to later
problems in the system design and implementation. The requirements engineering
process aims to produce an agreed requirements document that specifies a system
requirements.
There are four main activities in the requirements engineering process:
1. Feasibility study: An estimate is made of whether the identified user needs may be
satisfied using current software and hardware technologies. The study considers
whether the proposed system will be cost-effective from a business point of view and if
it can be developed within existing budgetary constraints. A feasibility study should be
relatively cheap and quick. The result should inform the decision of whether or not to
go ahead with a more.
a.Technical feasibility- Under this feasibility, we study whether the technical
requirements for the working of the proposed system are okay or not. The hardware and
the software required for the operating of the system is available or not. This project is
basically designed for android operating system which is Linux based .So it can run on
mobiles, tablets and PC’s. The user just need to have android Operating system.
b. Economic feasibility- Under this section, we study the economic feasibility of the
system. Whether the proposed system is economical to be developed and used in
comparison to the previously used systems? If any up gradation in the hardware is
required to be done for the running of the system, whether it is feasible to spend more
money on the up gradation of the hardware or the software. The developed tool is open
source. Thus, the tool is very economical to be implemented at any place. In addition,
this tool will help in reducing the efforts required to serve the same purpose using any
other application.
c. Operational feasibility- In the operational feasibility study, we check whether the
proposed system will work according to the policies and estimates of the end user, after
the implementation or not. The operational feasibility of the composed system also
depends upon the training of the end user to the complexity of the system. This
application is very user friendly; the user can use it by just clicking over the options and
navigate throughout the application easily.
d. Social feasibility- Survey of the feasibility is the most important part of the Feasibility
Study. It is most commonly seen that the end users resist adopting new software. So
their option must be known. This application is also social feasible .The person only
need to have an android phone and it is an offline app thus users don’t need to have an
active internet connection. Internet is required only for students.
2. Requirements elicitation and analysis: This is the process of deriving the system
requirements through observation of existing systems, discussions with potential users
and buyer, task analysis. This may involve the development of one or more system
models and prototypes. These help the system developer understand the system to be
specified.
3. Requirements specification: Requirements specification is the activity of translating
the information gathered during the analysis activity into a document that defines a set
of requirements. Two types of requirements may be included in this document. User
requirements are abstract statements of the system requirements for the customer and
end-user of the system; System requirements are a more detailed description of the
functionality to be provided.
4. Requirements validation: This activity checks the requirements for realism,
consistency, and completeness. During this process, errors in the requirements
document are inevitably discovered. It must then be modified to correct these problems.
Most software interacts with other software systems. These include the operating
system, database, middleware, and other application systems. These construct the
‘software platform’, the environment in which the software will execute. Information
about this platform is an essential input to the design process, as designers must decide
how best to integrate it with the software’s environment. The requirements specification
is a description of the functionality the software must provide and its performance and
dependability requirements. If the system is to process existing data, then the
description of that data may be included in the platform specification; otherwise, the
data description must be an input to the design process.
There are four activities that may be part of the design process for information
systems as shown in the previous figure:
1. Architectural design, where the software engineer identifies the overall structure of
the system, the principal components (sometimes called sub-systems or modules), their
relationships, and how they are distributed.
2. Interface design, where the software engineer defines the interfaces between system
components. This interface specification must be unambiguous. Once interface
specifications are agreed, the components can be designed and developed concurrently.
3. Component design, where the software engineer takes each system component and
design how it will operate. This may be a simple statement of the expected functionality
to be implemented, with the specific design left to the programmer. Alternatively, it
may be a list of changes to be made to a reusable component or a detailed design model
4. Database design, where the software engineer designs the system data structures and
how A general model of the design process these are to be represented in a database.
The work here depends on whether an existing database is to be reused or a new
database is to be created.
Q. Discuss Black Box testing according to the requirements of final
year project.
Sol. The black box is a powerful technique to check the application under test from the
user’s perspective. Black box testing is used to test the system against external factors
responsible for software failures. This testing approach focuses on the input that goes
into the software, and the output that is produced. The testing team does not cover the
inside details such as code, server logic, and development method.

A simple login screen of software or a web application will be tested for seamless user
login. The login screen has two fields, username and password as an input and the
output will be to enable access to the system.
A black box testing will not consider the specifications of the code, and it will test the
valid username and password to login to the right account.
This form of testing technique will check the input and output.
• A user logged in when inputs a present username and correct password
• A user receives an error message when enters username and incorrect
password
The black box testing is also known as an opaque, closed box, function-centric testing.
It emphasizes on the behaviour of the software. Black box testing checks scenarios
where the system can break.

Here are the generic steps followed to carry out any type of Black Box Testing.
• Initially requirements and specifications of the system are examined.
• Tester chooses valid inputs (positive test scenario) to check whether SUT processes
them correctly. Also some invalid inputs (negative test scenario) are chosen to verify
that the SUT is able to detect them.
• Tester determines expected outputs for all those inputs.
• Software tester constructs test cases with the selected inputs.
• The test cases are executed.
• Software tester compares the actual outputs with the expected outputs.
• Defects if any are fixed and re-tested.

Types of Black Box Testing

There are many types of Black Box Testing but following are the prominent ones –
• Functional testing - This black box testing type is related to functional requirements
of a system; it is done by software testers.
• Non-functional testing - This type of black box testing is not related to testing of a
specific functionality , but non-functional requirements such as performance,
scalability, usability.
• Regression testing - Regression testing is done after code fixes , upgrades or any other
system maintenance to check the new code has not affected the existing code.
Q. Discuss White Box testing with the help of module of final year
project.
Sol. As the project is on a big , large scale, we always need testing to make it
successful. If each component works properly in all respects and gives desired output
for all kinds of inputs then the project is said to be successful. So the conclusion is-to
make the project successful, it needs to be tested.

In order to uncover the errors present in different phases we have done white box
testing.
White-box testing is a method of software testing that tests internal structures or
workings of an application, as opposed to its functionality. White box testing includes
unit testing and integration testing. And in our project we have used this concept of
level testing.
The steps involved in Testing are:

1.Unit Testing

Unit testing focuses verification efforts on the smallest unit of the software design, the
module. This is also known as “Module Testing”. The modules are tested separately.
This testing was carried out during the programming stage itself. In this testing each
module is found to be working satisfactorily as regards to the expected output from
the module.

2.Integration Testing
Data can be grossed across an interface; one module can have adverse efforts on
another. Integration testing is systematic testing for construction of the program
structure while at the same time conducting tests to uncover errors associated with the
interface. The objective is to take unit tested modules and build a program structure.
All the modules are combined and tested as a whole. Here correction is difficult
because the isolation of cause is complicated by the vast expense of the entire
program. Thus in the integration testing stop, all the errors uncovered are corrected for
the text testing steps.

White Box Testing is coverage of the specification in the code:

1. Code coverage
2. Segment coverage
3. Branch Coverage or Node Testing
4. Compound Condition Coverage
5. Basis Path Testing
6. Data Flow Testing (DFT)
7. Path Testing
8. Loop Testing

Dynamic White Box Testing vs. Debugging:- Dynamic white box testing and debugging
are two techniques which appear similar, since they deal with the code and the bugs in
software. They do overlap when bugs are found. However, they are different in their
goals. Dynamic white box testing finds the bugs in the software while debugging deals
with the process of fixing the bugs that have been found during the testing phase. As a
software tester, you are required to emphasize on the test cases that demonstrate a bug.
In white box testing, you narrow down to the information pertaining to the number of
lines of code which look erroneous. The programmers debug the erroneous lines of code
which are reported to them. They find the reason for the cause of bug and fix it.