ISTQB Chapter 1 Fundamentals of Testing

ISTQB Chapter- 1
Fundamentals of Testing

What is Software Testing?
Software testing is a process of executing a program or application with the intent of ﬁnding the software
bugs.
It can also be stated as the process of validating and verifying that a software program or application or
product:
Meets the business and technical requirements that guided it’s design and development
● Works as expected
● Can be implemented with the same characteristic.

What is Software Testing?
Let’s break the deﬁnition of Software testing into the following parts:
1) Process: Testing is a process rather than a single activity.
2) All Life Cycle Activities: Testing is a process that’s take place throughout the Software Development
Life Cycle (SDLC).
● The process of designing tests early in the life cycle can help to prevent defects from being
introduced in the code. Sometimes it’s referred as “verifying the test basis via the test design”.
● The test basis includes documents such as the requirements and design.

Why is software testing necessary?
Software Testing is necessary because we all make mistakes. Some of those mistakes are unimportant,
but some of them are expensive or dangerous. We need to check everything and anything we produce
because things can always go wrong.
Since we assume that our work may have mistakes, hence we all need to check our own work. However
some mistakes come from bad assumptions and blind spots, so we might make the same mistakes when
we check our own work as we made when we did it. So we may not notice the ﬂaws in what we have done.
Ideally, we should get someone else to check our work because another person is more likely to spot the
ﬂaws.
There are several reasons which clearly tells us as why Software Testing is important and what are the
major things that we should consider while testing of any product or application.

All Life Cycle Activities
All Life Cycle Activities: Testing is a process that’s take place throughout the Software Development
Life Cycle (SDLC).
● The process of designing tests early in the life cycle can help to prevent defects from being
introduced in the code. Sometimes it’s referred as “verifying the test basis via the test design”.
● The test basis includes documents such as the requirements and design speciﬁcations.

Software testing is very important because of
the following reasons:
Software testing is very important because of the following reasons:
1. Software testing is really required to point out the defects and errors that were made during the
development phases.
2. It’s essential since it makes sure of the Customer’s reliability and their satisfaction in the
application.
3. It is very important to ensure the Quality of the product. Quality product delivered to the
customers helps in gaining their conﬁdence. (Know more about Software Quality)

Software testing is very important because of
the following reasons:
4. Testing is necessary in order to provide the facilities to the customers like the delivery of high
quality product or software application which requires lower maintenance cost and hence results
into more accurate, consistent and reliable results.
5. Testing is required for an effective performance of software application or product.
6. It’s important to ensure that the application should not result into any failures because it can be
very expensive in the future or in the later stages of the development.
7. It’s required to stay in the business.

What are software testing objectives and
purpose?
Software Testing has different goals and objectives.The major objectives of Software testing are as
follows:
● Finding defects which may get created by the programmer while developing the software.
● Gaining confidence in and providing information about the level of quality.
● To prevent defects.
● To make sure that the end result meets the business and user requirements.
● To ensure that it satisfies the BRS that is Business Requirement Specification and SRS that is
System Requirement Specifications.
● To gain the confidence of the customers by providing them a quality product.

purpose?
Software testing helps in finalizing the software application or product against business and user
requirements. It is very important to have good test coverage in order to test the software application
completely and make it sure that it’s performing well and as per the specifications.
While determining the test coverage the test cases should be designed well with maximum possibilities of
finding the errors or bugs. The test cases should be very effective. This objective can be measured by the
number of defects reported per test cases. Higher the number of the defects reported the more effective
are the test cases. Once the delivery is made to the end users or the customers they should be able to
operate it without any complaints.

purpose?
To satisfy the customers, testers should know as how the customers are going to use this product and
accordingly they should write down the test scenarios and design the test cases.
Software testing makes sure that the testing is being done properly and hence the system is ready for
use. Good coverage means that the testing has been done to cover the various areas like functionality of
the application, compatibility of the application with the OS, hardware and different types of browsers,
performance testing to test the performance of the application and load testing to make sure that the
system is reliable and should not crash or there should not be any blocking issues. It also determines that
the application can be deployed easily to the machine and without any resistance. Hence the application
is easy to install, learn and use.

Defect or bugs or faults in software testing?
Definition: A defect is an error or a bug, in the application which is created. A programmer while
designing and building the software can make mistakes or error. These mistakes or errors mean that
there are flaws in the software. These are called defects.
● When actual result deviates from the expected result while testing a software application or
product then it results into a defect. Hence, any deviation from the specification mentioned in the
product functional specification document is a defect. In different organizations it’s called
differently like bug, issue, incidents or problem.

Defect or bugs or faults in software testing?
● When the result of the software application or product does not meet with the end user
expectations or the software requirements then it results into a Bug or Defect. These defects or
bugs occur because of an error in logic or in coding which results into the failure or unpredicted or
unanticipated results.

Additional Information about Defects / Bugs
While testing a software application or product if large number of defects are found then it’s called
Buggy.
When a tester ﬁnds a bug or defect it’s required to convey the same to the developers. Thus they report
bugs with the detail steps and are called as Bug Reports, issue report, problem report, etc.
This Defect report or Bug report consists of the following information:
● Defect ID – Every bug or defect has it’s unique identiﬁcation number
● Defect Description – This includes the abstract of the issue.
● Product Version – This includes the product version of the application in which the defect is found.

● Detail Steps – This includes the detailed steps of the issue with the screenshots attached so that
developers can recreate it.
● Date Raised – This includes the Date when the bug is reported
● Reported By – This includes the details of the tester who reported the bug like Name and ID
● Status – This field includes the Status of the defect like New, Assigned, Open, Retest, Verification,
Closed, Failed, Deferred, etc.
● Fixed by – This field includes the details of the developer who fixed it like Name and ID

● Date Closed – This includes the Date when the bug is closed
● Severity – Based on the severity (Critical, Major or Minor) it tells us about impact of the defect or
bug in the software application
● Priority – Based on the Priority set (High/Medium/Low) the order of ﬁxing the defect can be made.
(Know more about Severity and Priority)

Failure in software testing?
If under certain environment and situation defects in the application or product get executed then the
system will produce the wrong results causing a failure.
Not all defects result in failures, some may stay inactive in the code and we may never notice them.
Example: Defects in dead code will never result in failures.
It is not just defects that give rise to failure. Failures can also be caused because of the other reasons also
like:
● Because of the environmental conditions as well like a radiation burst, a strong magnetic field,
electric field or pollution could cause faults in hardware or firmware. Those faults might prevent or
change the execution of software.

Failure in software testing?
● Failures may also arise because of human error in interacting with the software, perhaps a wrong
input value being entered or an output being misinterpreted.
● Finally failures may also be caused by someone deliberately trying to cause a failure in the system

Diﬀerence between Error, Fault, Incident,
Defect and Failure in software testing:
Error : The mistakes made by programmer is known as an ‘Error’. This could happen because of the
following reasons:
– Because of some confusion in understanding the functionality of the software
– Because of some miscalculation of the values
– Because of misinterpretation of any value, etc.

Incident: When tester is executing a test he/she may observe some difference in the behavior of the
feature or functionality, but this occurs not only because of the failure. This may happen because of the
wrong test data entered, tester may not be aware of the feature or functionality or because of the bad
environment. Because of these reasons incidents are reported. They are known as incident report. The
condition or situation which requires further analysis or clariﬁcation is known as incident. To deal with
the incidents the programmer need to to the analysis that whether this incident has occurred because of
the failure or not.
Defect or Bug: The bugs introduced by tester/programmer inside the code are known as a defect. This
can happen because of some programmatically mistakes.

Failure: If under certain circumstances these defects get executed by the final user then it results into the
failure which is known as software failure.
Few points that are important to know:
● It’s not necessary that defects or bugs introduced in the product are only by the software. To
understand it further let’s take an example. A bug or defect can also be introduced by a business
analyst. Defects present in the specifications like requirements specification and design
specifications can be detected during the reviews. When the defect or bug is caught during the
review cannot result into failure because the software has not yet been executed.
● These defects or bugs are reported not to blame the developers or any people but to judge the
quality of the product. The quality of product is of utmost importance. To gain the confidence of the
customers it’s very important to deliver the quality product on time.

From where do defects and failures in software
testing arise?
● Errors in the speciﬁcation, design and implementation of the software and system
● Errors in use of the system
● Environmental conditions
● Intentional damage
● Potential consequences of earlier errors

Errors in the specification and design of the
software:
Specification is basically a written document which describes the functional and non – functional aspects
of the software by using prose and pictures. For testing specifications there is no need of having code.
Without having code we can test the specifications. About 55% of all the bugs present in the product are
because of the mistakes present in the specification. Hence testing the specifications can lots of time and
the cost in future or in later stages of the product.

software:
Errors in use of the system:
Errors in use of the system or product or application may arise because of the following reasons:
● Inadequate knowledge of the product or the software to the tester. The tester may not be aware of
the functionalities of the product and hence while testing the product there might be some defects
or failures.
● Lack of the understanding of the functionalities by the developer. It may also happen that the
developers may not have understood the functionalities of the product or application properly.
Based on their understanding the feature they will develop may not match with the speciﬁcations.
Hence this may result into the defect or failure.

software:
Environmental conditions:
Because of the wrong setup of the testing environment testers may report the defects or failures. As per
the recent surveys it has been observed that about 40% of the tester’s time is consumed because of the
environment issues and this has a great impact on quality and productivity. Hence proper test
environments are required for quality and on time delivery of the product to the customers.
Intentional damage:
The defects and failures reported by the testers while testing the product or the application may arise
because of the intentional damage.

software:
Potential consequences of earlier errors:
Errors found in the earlier stages of the development reduce our cost of production. Hence it’s very
important to find the error at the earlier stage. This could be done by reviewing the specification
documents or by walkthrough. The downward flow of the defect will increase the cost of production

When do defects in software testing arise?
The person using the software application or product may not have enough knowledge of the product.
● Maybe the software is used in the wrong way which leads to the defects or failures.
● The developers may have coded incorrectly and there can be defects present in the design.
● Incorrect setup of the testing environments.

Cost of defects in software testing?
The cost of defects can be measured by the impact of the defects and when we find them. Earlier the
defect is found lesser is the cost of defect. For example if error is found in the requirement specifications
then it is somewhat cheap to fix it. The correction to the requirement specification can be done and then
it can be re-issued. In the same way when defect or error is found in the design then the design can be
corrected and it can be re-issued. But if the error is not caught in the specifications and is not found till
the user acceptance then the cost to fix those errors or defects will be way too expensive.
If the error is made and the consequent defect is detected in the requirements phase then it is relatively
cheap to fix it.

Defect/Bug Life Cycle in software testing?
Defect life cycle is a cycle which a defect goes through during its lifetime. It starts when defect is found
and ends when a defect is closed, after ensuring it’s not reproduced. Defect life cycle is related to the bug
found during testing.

Bug or defect life cycle includes following
steps or status
Bug or defect life cycle includes following steps or status:
1. New: When a defect is logged and posted for the ﬁrst time. It’s state is given as new.
2. Assigned: After the tester has posted the bug, the lead of the tester approves that the bug is
genuine and he assigns the bug to corresponding developer and the developer team. It’s state
given as assigned.
3. Open: At this state the developer has started analyzing and working on the defect ﬁx.

steps or status
4. Fixed: When developer makes necessary code changes and verifies the changes then he/she can
make bug status as ‘Fixed’ and the bug is passed to testing team.
5. Pending retest: After fixing the defect the developer has given that particular code for retesting
to the tester. Here the testing is pending on the testers end. Hence its status is pending retest.
6. Retest: At this stage the tester do the retesting of the changed code which developer has given to
him to check whether the defect got fixed or not.
7. Verified: The tester tests the bug again after it got fixed by the developer. If the bug is not
present in the software, he approves that the bug is fixed and changes the status to “verified”.

steps or status
8. Reopen: If the bug still exists even after the bug is fixed by the developer, the tester changes the
status to “reopened”. The bug goes through the life cycle once again.
9. Closed: Once the bug is fixed, it is tested by the tester. If the tester feels that the bug no longer
exists in the software, he changes the status of the bug to “closed”. This state means that the bug
is fixed, tested and approved.
10. Duplicate: If the bug is repeated twice or the two bugs mention the same concept of the bug, then
one bug status is changed to “duplicate“.
11. Rejected: If the developer feels that the bug is not genuine, he rejects the bug. Then the state of
the bug is changed to “rejected”.

steps or status
12. Deferred: The bug, changed to deferred state means the bug is expected to be ﬁxed in next
releases. The reasons for changing the bug to this state have many factors. Some of them are
priority of the bug may be low, lack of time for the release or the bug may not have major effect
on the software.
13. Not a bug: The state given as “Not a bug” if there is no change in the functionality of the
application. For an example: If customer asks for some change in the look and ﬁeld of the
application like change of colour of some text then it is not a bug but just some change in the
looks of the application"

Diﬀerence between Severity and Priority?
1) Severity:
It is the extent to which the defect can affect the software. In other words it deﬁnes the impact that a
given defect has on the system. For example: If an application or web page crashes when a remote link is
clicked, in this case clicking the remote link by an user is rare but the impact of application crashing is
severe. So the severity is high but priority is low.
Severity can be of following types:
Critical: The defect that results in the termination of the complete system or one or more
component of the system and causes extensive corruption of the data.

The failed function is unusable and there is no acceptable alternative method to achieve the required
results then the severity will be stated as critical.
● Major: The defect that results in the termination of the complete system or one or more
component of the system and causes extensive corruption of the data. The failed function is
unusable but there exists an acceptable alternative method to achieve the required results then the
severity will be stated as major. Example the website works on computer but not mobile
● Moderate: The defect that does not result in the termination, but causes the system to produce
incorrect, incomplete or inconsistent results then the severity will be stated as moderate.

● Minor: The defect that does not result in the termination and does not damage the usability of the
system and the desired results can be easily obtained by working around the defects then the
severity is stated as minor. Tab key is not working to move to next element but still mouse is
working.
● Cosmetic: The defect that is related to the enhancement of the system where the changes are
related to the look and ﬁeld of the application then the severity is stated as cosmetic.

2) Priority:
Priority defines the order in which we should resolve a defect. Should we fix it now, or can it wait? This
priority status is set by the tester to the developer mentioning the time frame to fix the defect. If high
priority is mentioned then the developer has to fix it at the earliest. The priority status is set based on the
customer requirements.
For example: If the company name is misspelled in the home page of the website, then the priority is
high and severity is low to fix it.
Priority can be of following types:
● Low: The defect is an irritant which should be repaired, but repair can be deferred until after
more serious defect have been fixed.

● Medium: The defect should be resolved in the normal course of development activities. It can
wait until a new build or version is created.
● High: The defect must be resolved as soon as possible because the defect is affecting the
application or the product severely. The system cannot be used until the repair has been done.

Principles of testing?
Principles of Testing – There are 7 principles of testing. They are as follows:
1) Testing shows presence of defects: Testing can show the defects are present, but cannot prove that
there are no defects. Even after testing the application or product thoroughly we cannot say that the
product is 100% defect free. Testing always reduces the number of undiscovered defects remaining in the
software but even if no defects are found, it is not a proof of correctness.
2) Exhaustive testing is impossible: Testing everything including all combinations of inputs and
preconditions is not possible. So, instead of doing the exhaustive testing we can use risks and priorities to
focus testing efforts.

For example: In an application in one screen there are 15 input ﬁelds, each having 5
possible values, then to test all the valid combinations you would need 30 517 578 125 (515) tests. This
is very unlikely that the project timescales would allow for this number of tests. So, accessing and
managing risk is one of the most important activities and reason for testing in any project.
3) Early testing: In the software development life cycle testing activities should start as early as possible
and should be focused on deﬁned objectives.
4) Defect clustering: A small number of modules contains most of the defects discovered during
pre-release testing or shows the most operational failures.

5) Pesticide paradox: If the same kinds of tests are repeated again and again, eventually the same set of
test cases will no longer be able to find any new bugs. To overcome this “Pesticide Paradox”, it is really
very important to review the test cases regularly and new and different tests need to be written to
exercise
different parts of the software or system to potentially find more defects.
6) Testing is context dependent: Testing is basically context dependent. Different kinds of sites are
tested differently. For example, safety – critical software is tested differently from an e-commerce site.
7) Absence – of – errors fallacy: If the system built is unusable and does not fulfil the user’s needs and
expectations then finding and fixing defects does not help.

Fundamental test process in software testing?
Testing is a process rather than a single activity. This process starts from test planning then designing test
cases, preparing for execution and evaluating status till the test closure. So, we can divide the activities
within the fundamental test process into the following basic steps:
1) Planning and Control
2) Analysis and Design
3) Implementation and Execution
4) Evaluating exit criteria and Reporting
5) Test Closure activities

1) Planning and Control:
Test planning has following major tasks:
● To determine the scope and risks and identify the objectives of testing.
● To determine the test approach
● To implement the test policy and/or the test strategy. (Test strategy is an outline that describes the
testing portion of the software development cycle. It is created to inform PM, testers and
developers about some key issues of the testing process. This includes the testing objectives,
method of testing, total time and resources required for the project and the testing environments.).

● To determine the required test resources like people, test environments, PCs, etc.
● To schedule test analysis and design tasks, test implementation, execution and evaluation.
● To determine the Exit criteria we need to set criteria such as Coverage criteria. (Coverage criteria
are the percentage of statements in the software that must be executed during testing. This will
help us track whether we are completing test activities correctly. They will show us which tasks
and checks we must complete for a particular level of testing before we can say that testing is
ﬁnished.)

Psychology of testing?
In this section we will discuss:
● The comparison of the mindset of the tester and the developer.
● The balance between self-testing and independent testing.
● There should be clear and courteous communication and feedback on defects between tester and
Developer.
Comparison of the mindset of the tester and developer:
Developer mindset is how to make system work, tester mindset is how to break the system and ﬁnd
defect. The testing and reviewing of the applications are different from the analysing and developing of it.

Psychology of testing?
By this we mean to say that if we are building or developing applications we are working positively to
solve the problems during the development process and to make the product according to the user
speciﬁcation. However while testing or reviewing a product we are looking for the defects or failures in
the product. Thus building the software requires a different mindset from testing the software.

The balance between self-testing and
independent testing
The comparison made on the mindset of the tester and the developer in the above article is just to
compare the two different perspectives. It does not mean that the tester cannot be the programmer, or
that the programmer cannot be the tester, although they often are separate roles.
In fact programmers are the testers. They always test their component which they built. While testing
their own code they ﬁnd many problems so the programmers, architect and the developers always test
their own code before giving it to anyone, that we call is unit testing.

The balance between self-testing and
independent testing
However we all know that it is difﬁcult to ﬁnd our own mistakes. So, programmers, architect, business
analyst depend on others to help test their work. This other person might be some other developer from
the same team or the Testing specialists or professional testers. Giving applications to the testing
specialists or professional testers allows an independent test of the system

Software Quality?
Quality software is reasonably bug or defect free, delivered on time and within budget, meets
requirements and/or expectations, and is maintainable.
ISO 8402-1986 standard deﬁnes quality as “the totality of features and characteristics of a product or
service that bears its ability to satisfy stated or implied needs.”
Key aspects of quality for the customer include:
● Good design – looks and style
● Good functionality – it does the job well
● Reliable – acceptable level of breakdowns or failure

Software Quality?
● Consistency
● Durable – lasts as long as it should
● Good after sales service
● Value for money
Good design – looks and style:
It is very important to have a good design. The application or product should meet all the requirement
speciﬁcations and at the same time it should be user friendly. The customers are basically attracted by
the good looks and style of the application. The right color combinations, font size and the styling of the
texts and buttons are very important.

Software Quality?
Good functionality – it does the job well:
Along with the good looks of the application or the product it’s very important that the functionality
should be intact. All the features and their functionality should work as expected. There should not be
any deviation in the actual result and the expected result.
Reliable – acceptable level of breakdowns or failure:
After we have tested for all the features and their functionalities it also very important that the
application or product should be reliable. For example: There is an application of saving the student's
records. This application should save all the students records and should not fail after entering 100
records. This is called reliability.

Software Quality?
Consistency:
The software should have consistency across the application or product. Single software can be multi
dimensional. It is very important that all the different dimensions should behave in a consistent manner.
Example application on mobile, desktop, web based should provide same service.
Durable – lasts as long as it should:
The software should be durable. For example if software is being used for a year and the number of data
has exceed 5000 records then it should not fail if number of records increases. The software product or
application should continue to behave in the same way without any functional breaks.

Software Quality?
Good after sales service: easy to maintain and should be done whenever is needed.
Once the product is shipped to the customers then maintenance comes into the picture. It is very
important to provide good sales services to keep the customers happy and satisﬁed. For example if after
using the product for six months the customer realizes to make some changes to the application then
those changes should be done as fast as possible and should be delivered to the customers on time with
quality.

Software Quality?
Value for money:
It’s always important to deliver the product to the customers which have value for money. The product
should meet the requirement speciﬁcations. It should work as expected, should be user friendly. We
should provide good services to the customers. Other than the features mentioned in the requirement
speciﬁcations some additional functionality could be given to the customers which they might not have
thought of. These additional functionalities should make their product more user friendly and easy to use.
This also adds value for money.

ISTQB Chapter 1 Fundamentals of Testing

More Related Content

Similar to ISTQB Chapter 1 Fundamentals of Testing (20)

Recently uploaded (20)

ISTQB Chapter 1 Fundamentals of Testing