ISTQB Foundation Phase
What is testing?
Software testing is a process to evaluate the functionality of a software under
test (SUT) with an intent to find whether the developed software met the
specified requirements or not, and to identify the defects to ensure that the
product is defect-free to produce the quality product.
Risk is the reason we test
2 Main areas that make up testing:
Validation: you design test cases, you run the test cases that exercise the
code to check that the code works as required this is known as dynamic
testing.
Verification: you review the requirements this known as static testing to
find defects in work products
Good testing involves both validation and verification
Objectives are influenced by:
Different lifestyles
Test Levels
The system / application being tested
Context of industries
Resource constraints such as time and cost
Learning Objective 1.1.2 (K2) Differentiate testing from debugging
Testing generates failures of the software that are caused by defects in the code.
This is basically what testers do when executing tests, you are finding the
failures. The developer then fixes that defect in the code (known as debugging).
Once the code is fixed, then the tester must run the test that generated the
failure to confirm that the code was fixed. This is not a rule that testers test and
developers fix, in some situations, such as Agile, the two collaborate and may be
sharing the roles.
Exercise:
In your own words write down the typical objectives of software testing.
Exercise:
Explain in your own words what is the difference between testing and debugging
1.2 Why is Testing Necessary?
The question I have is ... what would happen if you do NOT test? Will lives be
lost? Will financial transactions be lost? Will reputations be damaged on social
media?
Exercise:
,Read Section 1.2 of your Course Notes pdf (pg. 23 - 25)
Learning Objective 1.2.1 (K2) Give examples of why testing is
necessary.
There is a lot of complex software in the field. If this software fails to work, there
is a very real risk that the impact could result in the loss of life, damage
company reputation, cause financial risk or impact our environment negatively.
Not all defects and failures fall into these high-risk situations, you will find that
most failures you generate will have little to medium impact. To put this into
context, would you fly on an aircraft that has not had testing conducted because
it was a time-consuming activity, or stakeholders thought it was a waste of time?
I am sure you would not.
Apart from achieving the objectives listed in section 1.1.1, testing and testers
can contribute to the success of the project by reviewing requirements early or
being involved in story grooming sessions so that you are preventing these
defects from moving to code. You can contribute to success by asking questions
of designers, developers, product owners so that we get increased
understanding of what is need, how the system will work and how testing will
help.
I have found, in practice, the test design techniques that I choose appropriate to
the context, will mitigate risk. You need to use the techniques appropriate to the
risk, the functionality, expected usage of the app, the design … in plain English
… the context. By doing this you will reduce the likelihood of missing defects
and failures.
Learning Objective 1.2.2 (K2) Describe the relationship between testing
and quality assurance and give examples of how testing contributes to
higher quality
Testing is not Quality Assurance. I can see you looking at me with a few frowns.
Testing is a part of Quality Control which is a part of Quality Management, which
then ties this whole thing together. Just because you run some tests does not
give the software any quality.
If you run a test and generate a failure, caused by a defect in the code, you have
not improved the quality of the code itself. However, if there is a decision made
to fix the defect in the code, and your re-test the same test and it passes, then
the quality of the code has improved.
What testing can do for you, is measure the quality of the code or system.
I want you to bear in mind, that when it comes to measuring the quality of
software, you need to first measure the quality of testing. If the tests are
rubbish, then you are not proving anything, you are just running tests. Pointless
exercise.
You can also look at what was the expected level of detail required for a work
product and measure the product to see if it meets that level of detail or quality.
, By doing this we are helping downstream activities to be of a higher level of
quality.
Learning Objective 1.2.3 (K2) Distinguish between error, defect, and
failure
Humans make mistakes. Hey Tester! You too are human and make mistakes.
When you make a mistake, you call that an ERROR. When you in ERROR, the
result is a DEFECT in a work product (work product = User Story, requirement,
system design, architecture design, code, test design etc.). If the DEFECT is in
code and we run that code, it MAY result in a FAILURE. For the failure to
happen, you will need the exact inputs / situation in which the FAILURE may
happen. It is possible for code that has a DEFECT, not to FAIL. Let’s try this in
reverse … FAILURES are caused by DEFECTS in the code, that were done in
human ERROR.
By the way, DEFECTS are also known as FAULTS.
You will need to get this right … it will be in your exam.
Learning Objective 1.2.4 (K2) Distinguish between the root cause of a
defect and its effects
The reason we make mistakes is that we are fallible as humans. This is made
worse due to the following:
Misunderstandings (of system requirements and each other).
Complexity of systems.
Time pressure to get things done in the shortest time.
Technology that is constantly changing.
Teams that are too large with many relationships.
A ROOT CAUSE of a defect is why did that happen? What was the reason. If you
spend time studying root causes you will have good ideas of what needs
changing in processes. In general, I find that the processes we follow are the
root cause of problems.
The effect of a defect can have minimal impact or pose a serious risk to life,
finances and reputations of organizations.
Exercise:
Describe, in your own words, how defects are caused by processes that are
followed in business and IT.
1.3 Seven Testing Principles
In the exam you are not expected to know how many principles there are, or
what is number 5! You need to be able to understand why things happen in the
life cycle being used. Yup, you need to understand the context. These principles
are common to just about any testing context and project.
Learning Objective 1.3.1 (K2) Explain the seven testing principles
What is testing?
Software testing is a process to evaluate the functionality of a software under
test (SUT) with an intent to find whether the developed software met the
specified requirements or not, and to identify the defects to ensure that the
product is defect-free to produce the quality product.
Risk is the reason we test
2 Main areas that make up testing:
Validation: you design test cases, you run the test cases that exercise the
code to check that the code works as required this is known as dynamic
testing.
Verification: you review the requirements this known as static testing to
find defects in work products
Good testing involves both validation and verification
Objectives are influenced by:
Different lifestyles
Test Levels
The system / application being tested
Context of industries
Resource constraints such as time and cost
Learning Objective 1.1.2 (K2) Differentiate testing from debugging
Testing generates failures of the software that are caused by defects in the code.
This is basically what testers do when executing tests, you are finding the
failures. The developer then fixes that defect in the code (known as debugging).
Once the code is fixed, then the tester must run the test that generated the
failure to confirm that the code was fixed. This is not a rule that testers test and
developers fix, in some situations, such as Agile, the two collaborate and may be
sharing the roles.
Exercise:
In your own words write down the typical objectives of software testing.
Exercise:
Explain in your own words what is the difference between testing and debugging
1.2 Why is Testing Necessary?
The question I have is ... what would happen if you do NOT test? Will lives be
lost? Will financial transactions be lost? Will reputations be damaged on social
media?
Exercise:
,Read Section 1.2 of your Course Notes pdf (pg. 23 - 25)
Learning Objective 1.2.1 (K2) Give examples of why testing is
necessary.
There is a lot of complex software in the field. If this software fails to work, there
is a very real risk that the impact could result in the loss of life, damage
company reputation, cause financial risk or impact our environment negatively.
Not all defects and failures fall into these high-risk situations, you will find that
most failures you generate will have little to medium impact. To put this into
context, would you fly on an aircraft that has not had testing conducted because
it was a time-consuming activity, or stakeholders thought it was a waste of time?
I am sure you would not.
Apart from achieving the objectives listed in section 1.1.1, testing and testers
can contribute to the success of the project by reviewing requirements early or
being involved in story grooming sessions so that you are preventing these
defects from moving to code. You can contribute to success by asking questions
of designers, developers, product owners so that we get increased
understanding of what is need, how the system will work and how testing will
help.
I have found, in practice, the test design techniques that I choose appropriate to
the context, will mitigate risk. You need to use the techniques appropriate to the
risk, the functionality, expected usage of the app, the design … in plain English
… the context. By doing this you will reduce the likelihood of missing defects
and failures.
Learning Objective 1.2.2 (K2) Describe the relationship between testing
and quality assurance and give examples of how testing contributes to
higher quality
Testing is not Quality Assurance. I can see you looking at me with a few frowns.
Testing is a part of Quality Control which is a part of Quality Management, which
then ties this whole thing together. Just because you run some tests does not
give the software any quality.
If you run a test and generate a failure, caused by a defect in the code, you have
not improved the quality of the code itself. However, if there is a decision made
to fix the defect in the code, and your re-test the same test and it passes, then
the quality of the code has improved.
What testing can do for you, is measure the quality of the code or system.
I want you to bear in mind, that when it comes to measuring the quality of
software, you need to first measure the quality of testing. If the tests are
rubbish, then you are not proving anything, you are just running tests. Pointless
exercise.
You can also look at what was the expected level of detail required for a work
product and measure the product to see if it meets that level of detail or quality.
, By doing this we are helping downstream activities to be of a higher level of
quality.
Learning Objective 1.2.3 (K2) Distinguish between error, defect, and
failure
Humans make mistakes. Hey Tester! You too are human and make mistakes.
When you make a mistake, you call that an ERROR. When you in ERROR, the
result is a DEFECT in a work product (work product = User Story, requirement,
system design, architecture design, code, test design etc.). If the DEFECT is in
code and we run that code, it MAY result in a FAILURE. For the failure to
happen, you will need the exact inputs / situation in which the FAILURE may
happen. It is possible for code that has a DEFECT, not to FAIL. Let’s try this in
reverse … FAILURES are caused by DEFECTS in the code, that were done in
human ERROR.
By the way, DEFECTS are also known as FAULTS.
You will need to get this right … it will be in your exam.
Learning Objective 1.2.4 (K2) Distinguish between the root cause of a
defect and its effects
The reason we make mistakes is that we are fallible as humans. This is made
worse due to the following:
Misunderstandings (of system requirements and each other).
Complexity of systems.
Time pressure to get things done in the shortest time.
Technology that is constantly changing.
Teams that are too large with many relationships.
A ROOT CAUSE of a defect is why did that happen? What was the reason. If you
spend time studying root causes you will have good ideas of what needs
changing in processes. In general, I find that the processes we follow are the
root cause of problems.
The effect of a defect can have minimal impact or pose a serious risk to life,
finances and reputations of organizations.
Exercise:
Describe, in your own words, how defects are caused by processes that are
followed in business and IT.
1.3 Seven Testing Principles
In the exam you are not expected to know how many principles there are, or
what is number 5! You need to be able to understand why things happen in the
life cycle being used. Yup, you need to understand the context. These principles
are common to just about any testing context and project.
Learning Objective 1.3.1 (K2) Explain the seven testing principles
