Chapter-1Introduction_to_Software-Testing
Chapter-1Introduction_to_Software-Testing
The software is set of programs developed for specific purpose. The internet banking
software, flight reservation system, mobile applications, operating systems, antivirus and so
on are examples of the software. Software is used by people of all age group and professions.
Software is used in every organisation and business. It would not be wrong to say software is
omnipresent. The software needs a thorough testing before it is released to users. The basics
of software testing should be understood by every software tester.
Since the software has become integral part of every business and organisation, failure of the
software can lead to loss of business, reputation, time, money, and sometimes even the life of
people.
To understand the basics of software testing, the below terminologies are to be understood.
Error:
The error is a human mistake. The errors can be committed by anyone in the IT team
during the different phases of software development. The BA (Business analyst) may have
misunderstood or misinterpreted the requirements. The client may have provided insufficient
or incorrect information. The architect may have the flaw in the software design. The
developers may have done the logical errors in the programs. The people in team make
mistakes due to lethargy, time pressure, unclear or insufficient requirements, assumptions,
complexity of requirements and various other reasons.
Defect:
A defect is a result of the error. The defect is also termed as a fault. Sometimes defect is a
synonym of bug. Though the clear different between the two terms in not made. The bug
usually refers to the fault in development environment and defect refers to the fault in test
environment. A defect occurs when behaviour of actual software developed by developer is
not same as expectation of the client.
Failure:
A failure is a consequence of defect. The software is said to be a failure when it fails to
perform in the real environment. The failure is also caused due to faults in the hardware
system. The environment conditions in which the software is expected to perform can cause
the failure. The environment condition can include magnetism, electronic fields, radiations,
pollutions, chemical effects and so on.
The errors lead to defects and defects lead to failure of the software. Software testing
evaluates the quality of the software.
Principles of testing
Testing and debugging
Testing metrics and measurements
The test engineer will test the application to make sure that the application is bug or defects
free. While doing testing, we can only identify that the application or software has any errors.
The primary purpose of doing testing is to identify the numbers of unknown bugs with the
help of various methods and testing techniques because the entire test should be traceable to
the customer requirement, which means that to find any defects that might cause the product
failure to meet the client's needs.
By doing testing on any application, we can decrease the number of bugs, which does not
mean that the application is defect-free because sometimes the software seems to be bug-free
while performing multiple types of testing on it. But at the time of deployment in the
production server, if the end-user encounters those bugs which are not found in the testing
process.
Sometimes it seems to be very hard to test all the modules and their features with effective
and non- effective combinations of the inputs data throughout the actual testing process.
Hence, instead of performing the exhaustive testing as it takes boundless determinations and
most of the hard work is unsuccessful. So we can complete this type of variations according
to the importance of the modules because the product timelines will not permit us to perform
such type of testing scenarios.
Early Testing
Here early testing means that all the testing activities should start in the early stages of the
software development life cycle's requirement analysis stage to identify the defects because
if we find the bugs at an early stage, it will be fixed in the initial stage itself, which may cost
us very less as compared to those which are identified in the future phase of the testing
process.
To perform testing, we will require the requirement specification documents; therefore, if the
requirements are defined incorrectly, then it can be fixed directly rather than fixing them in
another stage, which could be the development phase.
Defect clustering
The defect clustering defined that throughout the testing process, we can detect the numbers
of bugs which are correlated to a small number of modules. We have various reasons for this,
such as the modules could be complicated; the coding part may be complex, and so on.
These types of software or the application will follow the Pareto Principle, which states that
we can identify that approx. Eighty percent of the complication is present in 20 percent of the
modules. With the help of this, we can find the uncertain modules, but this method has its
difficulties if the same tests are performing regularly, hence the same test will not able to
identify the new defects.
Pesticide paradox
This principle defined that if we are executing the same set of test cases again and again over
a particular time, then these kinds of the test will not be able to find the new bugs in the
software or the application. To get over these pesticide paradoxes, it is very significant to
review all the test cases frequently. And the new and different tests are necessary to be
written for the implementation of multiple parts of the application or the software, which
helps us to find more bugs.
Testing is context-dependent
Once the application is completely tested and there are no bugs identified before the release,
so we can say that the application is 99 percent bug-free. But there is the chance when the
application is tested beside the incorrect requirements, identified the flaws, and fixed them on
a given period would not help as testing is done on the wrong specification, which does not
apply to the client's requirements. The absence of error fallacy means identifying and fixing
the bugs would not help if the application is impractical and not able to accomplish the
client's requirements and needs.
In this section, we are going to understand the difference between Testing and Debugging.
Both the terminologies are the integral parts of SDLC as both are used at the different phase
of Software Development Life Cycle and gives distinct types of outcomes.
At the time of development and after the outcome of any application or the software product
established in any programming language, both Testing and Debugging play a vital role in
finding and removing mistakes.
hey have quite an equivalent function, but they are diverse in terms of designs,
requirements, benefits, and performance.
Before we see the difference between testing and debugging, we will discuss the in-
detail evaluation of testing and debugging, which will help us distinguish both of them
appropriately.
Software testing
Each software or application needs to be tested before delivering to the clients and checks
whether the particular software or the application is working fine as per the given
requirements.
What is Debugging?
As opposed to Testing, Debugging is the action where the development team or a developer
implements after receiving the test report related to the bugs in the software from the testing
team.
In the software development process, debugging includes detecting and modifying code
errors in a software program.
In debugging process, the developer needs to identify the reason behind the particular bug
The developer changes the code and then rechecks whether the defect has been deleted
whenever the bug or error is found.
In the below table, we have listed some of the significant difference between testing and
debugging:
4. The test engineers perform manual and The developers will find, evaluates,
automated test cases on the application, and removes the software errors.
and if they detect any bug or error, they
can report back to the development team
for fixing.
6. Once the coding phase is done, we After the implementation of the test
proceed with the testing process. case, we can start the Debugging
process.
10. Software testing is the vital phase of It is not a part of SDLC because it
SDLC (Software Development Life occurs as a subset of testing.
Cycle).
12. Software testing contains various type of Debugging involves a various type of
testing methods, which are as follow: approaches, which are as follows:
o Black-box testing o Induction
o White-box testing o Brute Force
o Grey-box testing o Deduction
13. The testing team can subcontract to the Debugging cannot be subcontracted
outside team as well. to an outside team because the inside
development team only does it.
14. We can plan, design, and implement the As compared to the testing process,
testing process. the debugging process cannot be
forced
Software Testing Life Cycle (STLC)
The procedure of software testing is also known as STLC (Software Testing Life Cycle)
which includes phases of the testing process. The testing process is executed in a well-
planned and systematic manner. All activities are done to improve the quality of the software
product.
Requirement Analysis
Environment setup
Defect Logging
Requirement Analysis:
The first step of the manual testing procedure is requirement analysis. In this phase, tester
analyses requirement document of SDLC (Software Development Life Cycle) to examine
requirements stated by the client. After examining the requirements, the tester makes a test
plan to check whether the software is meeting the requirements or not.
Entry Criteria Activities Deliverable
For the planning of test plan Prepare the list of all List of all the
requirement specification, requirements and queries, and necessary tests for the
application architecture get resolved from Technical testable requirements
document and well-defined Manager/Lead, System and Test environment
acceptance criteria should be Architecture, Business Analyst details
available. and Client.
Make a list of all types of tests
(Performance, Functional and
security) to be performed.
Make a list of test environment
details, which should contain all
the necessary tools to execute
test cases.
Test plan creation is the crucial phase of STLC where all the testing strategies are defined.
Tester determines the estimated effort and cost of the entire project. This phase takes place
after the successful completion of the Requirement Analysis Phase. Testing strategy and
effort estimation documents provided by this phase. Test case execution can be started after
the successful completion of Test Plan Creation.
Setup of the test environment is an independent activity and can be started along with Test
Case Development. This is an essential part of the manual testing procedure as without
environment testing is not possible. Environment setup requires a group of essential software
and hardware to create a test environment. The testing team is not involved in setting up the
testing environment, its senior developers who create it.
Test strategy and Prepare the list of software and hardware by Execution
test plan analysing requirement specification. report.
document. After the setup of the test environment, execute the Defect
Test case smoke test cases to check the readiness of the test report.
document. environment.
Testing data.
Test case Execution takes place after the successful completion of test planning. In this phase,
the testing team starts case development and execution activity. The testing team writes down
the detailed test cases, also prepares the test data if required. The prepared test cases are
reviewed by peer members of the team or Quality Assurance leader.
Defect Logging:
Testers and developers evaluate the completion criteria of the software based on test
coverage, quality, time consumption, cost, and critical business objectives. This phase
determines the characteristics and drawbacks of the software. Test cases and bug reports are
analysed in depth to detect the type of defect and its severity.
Defect logging analysis mainly works to find out defect distribution depending upon severity
and types. If any defect is detected, then the software is returned to the development team to
fix the defect, then the software is re-tested on all aspects of the testing.
Once the test cycle is fully completed then test closure report, and test metrics are prepared.
Test case It evaluates the completion criteria of the software based on Closure
execution test coverage, quality, time consumption, cost, and critical report
report. business objectives. Test metrics
Defect Defect logging analysis finds out defect distribution by
report categorizing in types and severity.
The test cycle closure report includes all the documentation related to software design,
development, testing results, and defect reports.
His phase evaluates the strategy of development, testing procedure, possible defects in order
to use these practices in the future if there is a software with the same specification.
All document and Evaluates the strategy of development, testing Test closure
reports related to procedure, possible defects to use these practices in report
software. the future if there is a software with the same
specification