TESTING
Testing is a process of executing a program to ensure that defined input will produce
actual results that agree with required outputs. In developing a software project, error can be
initiated at any stage during the development. For each phase of the software development cycle
there are different techniques for detecting and elimination errors that originate in that phase.
However some errors will reflect in the code. Testing performs a very crucial role for quality
assurance and for ensuring the reliabilities of the software. The quality of the system depends on
its design, development, testing and implementation. Weaknesses in any of these areas will
seriously affect the quality and therefore value of the system to its users. Once the code has been
generated, testing of the modules begins implementation ends with formal tests.
Early Testing: Conducting testing as soon as possible in development life cycle to find defects
at early stages is called early testing. Early testing is helpful to reduce the cost of fixing defects.
Why does software have defects?
Incorrect requirements
Wrong design
Poor coding
Complex business logic
Complex technology
Work pressure
Frequently changing requirements.
Errors: Any incorrect human action that produces a problem in the system is caller error.
Defect: Deviation between expected behaviors to actual behavior of the system is called
defect.
Failure: The deviation identified by end-user while using a system is called a failure.
WHITE BOX TESTING
White Boxes focuses on the program control structure. Test cases are derived to ensure
that all statements in the program have executed at level once during, testing and that all logical
conditions implying that this test is typically applied to small program components. The system
has been tested once and that too the expected manner. All topics and transaction path from
origin to destination was tested to identify and correct the possible error.
White Box Testing is the test case design method that uses the control structure of the
procedural design to derive test cases. White Box testing methods were used to check whether
the loop executed properly, different methods were applied at the boundaries and the execution
was examined to be perfect. All typical conditions were tried and the correct results were
obtained.
BLACK BOX TESTING
Black Box Testing focuses on the functional requirements of the software; it enables to
derive set of input conditions that fully exercise all functional requirements for a program. Black
Box Testing tends to find out errors in data structure or external access, performance errors and
initialization error.
1.1 Purpose of Testing:
Testing accomplishes a variety of things, but most importantly it measures the quality of
the software we are developing. This view presupposes there are defects in the software waiting
to be discovered and this view is rarely disproved or even disputed.
Several factors contribute to the importance of making testing a high priority of any
software development effort. These include:
Reducing the cost of developing the program.
Ensuring that the application behaves exactly as we explain to the user for the vast
majority of programs, unpredictability is the least desirable consequences of using an
application.
Reducing the total cost of ownership. By providing software that looks and behaves as
shown in the documentation, the customers require fewer hours of training and less
support from product experts.
Developing customer loyalty and word-of-mouth market share.
1.2 Different Types of Testing:
1.2.1 Unit Testing:
Unit testing focuses verification on the smallest unit of software design, the software
component or module. Using the component level design description as a guide, important
control paths are tested to uncover errors within the boundary of the module. The unit testing is
a white box oriented testing.
First of all the module interface is tested to ensure that the information properly flows
into and out of the program until under test. Then the local data structure is tested to ensure the
data stored temporarily maintains its integrity during all steps in an execution. Boundary
conditions are tested to ensure that the module operates properly at boundaries established to
limit or restrict processing. All independent paths through the control structure are exercised to
ensure that all statements in a module have been executed at least once. And finally, all errors
handling paths are tested. In this project the testing is done according to bottom-up approach.
Starting with smallest and lowest level modules and processing one at a time. For each module a
driver and corresponding stubs were also written. If any errors found they were corrected
immediately and the unit was tested again.
1.2.2 Regression Testing:
Any time we modify an implementation within a program, we should also do regression
testing. We can do so by retuning existing tests against the modified code to determine whether
the changes break anything that worked prior to the change and by writing new tests where
necessary.
Some strategies and factors considered during this process include the following:
Test fixed bugs promptly.
Watch for side effects of fixes. The bug itself might be fixed but the fix might create
other bugs.
Regression test is written for each bug fixed.
If two or more tests are similar, determine which is less effective and get rid of it.
Identify tests that the program consistently passes and archive them.
Focus on functional issues, not those related to design.
Make changes (small and large) to data and find any resulting corruption.
Trace the effects of the changes on program memory.
1.2.3 Stress Testing:
Stress testing, which is specialized form of performance testing, is similar to destructive
testing in other field of engineering. The goal of stress testing is to crash the application by
increasing the processing load past performance degradation until the application begins to fail
due to saturation of resources or the occurrence of errors. Stress testing helps to reveal subtle
bugs that would otherwise go undetected until the application was deployed. Since such bugs are
typically the result of design flaws, stress testing should begin early in the development phase on
each area of the application. Fix these subtle bugs at their source instead of fixing symptomatic
bugs that may occur elsewhere in the application if these bugs were ignored.
1.2.4 Integration Testing:
Integration testing is a logical extension of unit testing. In its simplest form, two units
that have already been tested are combined into a component and the interface between them is
tested. A component, in this sense, refers to an integrated aggregate of more than one unit. The
idea is to test combinations of pieces and eventually expand the process to test your modules
with those of other groups. Eventually all the modules making up a process are tested together.
Any errors discovered when combining units are likely related to the interface between units.
This method reduces the number of possibilities to a far simpler level of analysis.
In this software, the bottom-up integration testing approached has been used, starting
with the smallest and lowest level modules and proceeding one at a time. For each module the
tests were conducted and the results were noted down.
1.2.5 User Testing:
User Testing is nothing but the test of the software by the users themselves with live data
being fed to the system. This helps in building really robust system. User testing in this system
has been done extensively ascertain the results.
Walkthroughs, Reviews and Demos:
Sometimes known as the informal peer group review, walkthroughs are one of a handful
of techniques that make a big difference to the chances of success in a software project.
The aim of a walkthrough is to improve the quality of a piece of work by discovering
potential problems. A walkthrough, when done properly, is seen as a positive contribution to the
producer and his or her work; it is not seen as criticism or a negative activity or a threat.
Plenty of “Reviews, Walkthroughs or Demos to the Managers and client are done
regularly in various meetings”. This helped ascertaining the work being done, whether it is
going in a correct way or not, and it also helped in lot of it continues improvement in the features
of the system.
1.2.6 Automation Testing:
"Automated Testing" is automating the manual testing process currently in use. This
requires that a formalized "manual testing process", currently exists in the company or
organization. Automation is the use of strategies, tools and artifacts that augment or reduce the
need of manual or human involvement or interaction in unskilled, repetitive or redundant tasks.
Minimally, such a process includes:
Detailed test cases, including predictable "expected results", which have been developed
from Business Functional Specifications and Design documentation.
A standalone Test Environment, including a Test Database that is restorable to a known
constant, such that the test cases are able to be repeated each time there are modifications
made to the application.
1.2.6.1The following types of testing can be automated:
Functional - testing that operations perform as expected.
Regression - testing that the behavior of the system has not changed.
Exception or Negative - forcing error conditions in the system.
Stress - determining the absolute capacities of the application and operational
infrastructure.
Performance - providing assurance that the performance of the system will be adequate
for both batch runs and online transactions in relation to business projections and
requirements.
Load - determining the points at which the capacity and performance of the system
become degraded to the situation that hardware or software upgrades would be required.
[Link] Benefits of Automated Testing:
Reliable: Tests perform precisely the same operations each time they are run, thereby
eliminating human error
Repeatable: You can test how the software reacts under repeated execution of the same
operations.
Programmable: You can program sophisticated tests that bring out hidden information
from the application.
Comprehensive: You can build a suite of tests that covers every feature in your
application.
Reusable: You can reuse tests on different versions of an application, even if the user
interfaces changes.
Better Quality Software: Because you can run more tests in less time with fewer
resources
Fast: Automated Tools run tests significantly faster than human users.
Cost Reduction: As the number of resources for regression test are reduced.
[Link] Automated testing gets the following benefits:
Concise: As simple as possible and no simpler.
Self-Checking: Test reports its own results; needs no human interpretation.
Repeatable: Test can be run many times in a row without human intervention.
Robust: Test produces same result now and forever. Tests are not affected by changes in
the external environment.
Sufficient: Tests verify all the requirements of the software being tested.
Necessary: Everything in each test contributes to the specification of desired behavior.
Clear: Every statement is easy to understand.
Efficient: Tests run in a reasonable amount of time.
Specific: Each test failure points to a specific piece of broken functionality; unit test
failures provide "defect triangulation".
Independent: Each test can be run by itself or in a suite with an arbitrary set of other
tests in any order.
Maintainable: Tests should be easy to understand and modify and extend.
Traceable: To and from the code it tests and to and from the requirements.
1.3 Test Cases:
Status of
Expected Actual Result
TC# Description Execution
Result
Pass/Fail
Application should
run without any Application is
TC01 Execute/run the application Pass
interrupts executing properly
Entered User Name
Enter User Name and Password are
Verification of and Password. It successfully
TC02 Pass
Login Page should verify with verifying with
database. database.
Admin User Name &
If Admin Login Password is valid
Name & Password then successfully Pass
is valid then it navigating respective
should navigate to home page.
Verification of Admin Page
respective Admin If User Name &
TC03 input User Name and
home page. If Password is not valid
password
invalid then show or wrong input then
message that Input message box shown
Username & that User Name &
Password is wrong. Password wrong.
member inputs id
and password and
User will input userid
clicks on submit
and password and
Verification of member button, if login is
clicks on login button Pass
TC04 Login successful redirect
and user redirected to
user to home page
home page
or else display
message login failed
Admin will enter
Admin adds member
name and other
name and other
details of member
details and clicks on
Admin Add members and clicks on submit Pass
TC05 submit button and
button, details
details added
should be added into
successfully
database
When Admin
clicks on View
Members link , Admin clicks on
Members link, all
all registered
View Members members fetched Pass
TC06 members should
from database and
be displayed displayed in GUI
using dynamic
table
Admin enters
Admin inputted old
old password,
password, new
New password
password and
and confirm confirm password
TC07 Admin Update Password password and and clicks on submit Pass
clicks on submit button, id old
password is correct ,
button, new
new password will be
password should
updated
be updated
Member clicks
on the datasets
Member click on the
link, training
link and training
TC08 Datasets Module datasets should Pass
datasets loaded and
be loaded on displayed on GUI
displayed on
GUI
Member clicks
on prediction
button, testing
Member clicks on the
datasets inputted
prediction button and
TC09 Malnutrition Prediction to the algorithm Pass
system generates
and algorithm outputs
gets executed
and results
predicted
Member click on
Member click on
anemia
anemia prediction
TC10 Anemia Prediction prediction Pass
button, results
button, anemia generated.
testing datasets
inputted and
algorithm gets
executed and
results predicted