ISTQB FOUNDATION 4.0 | Tutorial 20 | Retesting | Confirmation Testing | Regression Testing | CTFL

Summary

This tutorial delves into the ISTQB Foundation level certification, focusing on Chapter 2.2.3 about confirmation and regression testing. It explains that these tests are conducted as part of change-related testing, ensuring that defects are fixed and that no new issues arise from changes. Confirmation testing, often called retesting, verifies a defect fix, while regression testing checks for unintended consequences. The tutorial highlights the importance of impact analysis and the suitability of these tests for automation.

Takeaways

• 📚 The tutorial is focused on the ISTQB Foundation Level certification, specifically discussing testing throughout the SDLC in Chapter 2.
• 🔍 The segment 2.2.3 of the tutorial is about confirmation testing and regression testing, which are categorized as change-related testing due to their conduction upon application changes.
• 🔑 Confirmation testing, often known as retesting, is conducted to verify that a reported defect has been fixed. It's the first step after a developer returns the fixed code to the tester.
• 🌐 ISTQB uses the term 'confirmation testing' instead of 'retesting' to emphasize the purpose of testing, which is to confirm the resolution of a defect, not just repeating a test.
• 🛠️ Confirmation testing may involve rerunning previously failed test cases or adding new ones to cover changes made during the defect fix, adhering to the principle of the 'Pesticide Paradox'.
• ⏱️ In resource-constrained situations, confirmation testing could be limited to the steps that should reproduce the defect and verify its resolution.
• 🔄 Regression testing ensures that the original functionality of the application remains intact after changes have been made, such as fixing a defect.
• 💊 The analogy of visiting a doctor for regression testing is used to illustrate the importance of checking for any adverse side effects caused by changes or fixes in the application.
• 🔍 Regression testing is not limited to defect fixes but is also applicable during updates, upgrades, and migrations, emphasizing its broad scope in change-related testing.
• 🤖 Regression testing is a strong candidate for automation due to its repetitive nature and is often included in continuous integration (CI) pipelines in DevOps practices.
• 📈 Impact analysis is crucial for optimizing regression testing efforts by identifying which parts of the software could be affected by changes, thus reducing unnecessary testing.

Q & A

What is the main focus of Chapter 2 in the ISTQB Foundation Level certification tutorial?

The main focus of Chapter 2 is on testing throughout the SDLC, specifically discussing test levels and types, with a detailed look at confirmation testing and regression testing as part of change-related testing.

Why are confirmation testing and regression testing considered as change-related testing?

Confirmation testing and regression testing are considered change-related because they are conducted in response to changes made in an application, such as fixing a defect or making updates.

What is the primary purpose of confirmation testing?

The primary purpose of confirmation testing is to verify that a reported defect has been successfully fixed and is functioning as expected after the developer's modifications.

What is the difference between confirmation testing and retesting according to the ISTQB?

While many organizations use the term 'retesting' to refer to repeating a test, the ISTQB uses 'confirmation testing' to emphasize that the test is being repeated with a specific objective: to confirm the resolution of a reported defect.

What is the 'Pesticide Paradox' mentioned in the script?

The 'Pesticide Paradox' refers to the principle that fixing a defect may necessitate adding new test cases to improve the overall quality and test coverage, rather than just rerunning the failed test cases.

What are the different approaches to conducting confirmation testing?

Confirmation testing can involve executing all test cases that previously failed due to the defect, adding new test cases to cover any necessary changes made during the fix, or, when resources are limited, simply rerunning the steps that should reproduce the failure and checking that it no longer occurs.

What is the primary goal of regression testing?

The primary goal of regression testing is to ensure that all parts of the system that were working correctly before a change are still functioning properly after the change has been made.

Why is regression testing a strong candidate for automation?

Regression testing is a strong candidate for automation because it is often repeated to ensure that new code changes do not introduce issues, and automating these tests can save time and effort in the long run.

What is the role of impact analysis in the context of regression testing?

Impact analysis helps to identify which parts of the software could be affected by a change, allowing testers to optimize the extent of regression testing and focus on areas that are most likely to be impacted.

Can confirmation testing and regression testing be applied at all levels of testing?

Yes, confirmation testing and regression testing can be applied at all levels of testing, including static and dynamic testing, whenever a defect is fixed or a change is made.

What is the significance of conducting both confirmation and regression testing after a defect is fixed?

The significance lies in ensuring that not only is the original defect resolved, but also that no new issues or side effects have been introduced in other parts of the system as a result of the fix.

Outlines

00:00

🔍 Understanding Confirmation and Regression Testing

This paragraph introduces the concepts of confirmation testing and regression testing in the context of ISTQB Foundation Level certification. Confirmation testing, also known as retesting, is conducted after a defect has been reported and supposedly fixed by developers. The purpose is to verify that the fix is effective and the defect no longer exists. The paragraph explains the ISTQB's naming convention and the rationale behind it, emphasizing the objective nature of confirmation testing. It also touches on the 'Pesticide Paradox,' suggesting the addition of new test cases to improve quality coverage. The summary highlights the importance of executing the same test cases that previously failed or adding new ones to ensure the defect has been resolved, especially when time and resources are limited.

05:02

🔧 The Importance of Regression Testing in Software Development

The second paragraph delves into the purpose and process of regression testing, which is designed to ensure that changes made to an application have not adversely affected other parts of the system that were previously functioning correctly. It uses the analogy of a phone repair to illustrate the concept, explaining that after a defect is fixed, it's crucial to check that no other functionalities have been impacted. The paragraph discusses the potential ripple effects of changes in the code and the necessity of impact analysis to optimize regression testing efforts. It also mentions that regression testing is a strong candidate for automation, particularly in environments that employ continuous integration practices, and that it can be conducted at various testing levels, not just after defect fixes.

10:02

🛠️ Applying Confirmation and Regression Testing Across Testing Levels

The final paragraph emphasizes the applicability of both confirmation and regression testing across all levels of software testing, including static and dynamic testing. It stresses that these testing types are essential whenever changes are made to the system, whether it's a defect fix, an update, or a migration. The paragraph also suggests that regression testing is a continuous process, with the number of test cases potentially increasing with each release iteration. It concludes by reiterating the importance of understanding these testing methodologies in the broader context of software testing and encourages continuous learning and exploration in the field.

Keywords

💡ISTQB Foundation Level Certification

The ISTQB Foundation Level Certification is an entry-level qualification for software testers, focusing on the fundamental concepts and practices of software testing. In the video, this certification serves as the educational context for discussing testing methodologies, particularly the focus on change-related testing.

💡SDLC

SDLC stands for Software Development Life Cycle, which is a process that describes the stages involved in producing a software product. The video script mentions SDLC to frame the discussion of testing throughout the various stages of software development, emphasizing the importance of testing in each phase.

💡Confirmation Testing

Confirmation testing, also known as retesting, is the process of re-running tests to verify that a reported defect has been fixed. The script explains that this type of testing is conducted after a defect is reported and the developer has made the necessary fixes, ensuring the issue is resolved. The example of a cell phone being fixed for audio issues and then tested again to confirm the repair illustrates this concept.

💡Regression Testing

Regression testing is the process of ensuring that changes made to the code have not adversely affected the existing functionality of the software. The video script discusses this as a critical step following confirmation testing to make sure that while fixing one issue, other parts of the application are still functioning as intended.

💡Change-Related Testing

Change-related testing is a category of testing that includes confirmation and regression testing, conducted specifically when changes are made to an application. The script explains that these tests are essential to verify that changes have not introduced new issues or affected the existing functionality.

💡Defect

A defect in the context of software testing refers to a flaw or error in the software that causes it to behave incorrectly or not as intended. The script uses the term to describe the issues that testers identify and report to developers for resolution, which then leads to the need for confirmation testing.

💡Pesticide Paradox

The Pesticide Paradox is a principle mentioned in the script that suggests the potential downside of fixing a defect without adding new test cases. It implies that over-relying on the same test cases can lead to missing new defects, hence the importance of adding new tests to improve quality coverage after a defect is fixed.

💡Impact Analysis

Impact analysis is the process of evaluating the potential effects of a change on various parts of the software system. The script highlights its importance in optimizing the scope of regression testing by identifying which components might be affected by a change, thus helping testers to focus their efforts.

💡Automation

Automation in the context of software testing refers to the use of software to execute tests without human intervention. The script suggests that regression testing is a strong candidate for automation, especially in environments where continuous integration is practiced, such as in DevOps.

💡Continuous Integration (CI)

Continuous Integration is a development practice where developers frequently merge their code changes into a central repository, which triggers automated builds and tests. The script mentions CI as a scenario where automated regression testing is particularly useful to ensure that new code changes do not break existing functionality.

💡Maintenance Testing

Maintenance testing is the process of testing software after it has been released, typically to ensure that updates, bug fixes, or enhancements do not disrupt existing functionality. The script refers to maintenance testing as a broader context in which concepts like impact analysis and regression testing are applied.

Highlights

Introduction to Chapter 2.2.3 on confirmation testing and regression testing within the ISTQB Foundation level certification.

Confirmation testing is also known as retesting and is conducted after a defect is reported and fixed.

The distinction between confirmation testing and retesting, with ISTQB using the term 'confirmation testing' for clarity and specificity.

Confirmation testing's objective is to confirm the resolution of a reported defect.

The importance of adding new test cases post-fix to improve quality, referencing the 'Pesticide Paradox'.

When resources are limited, confirmation testing may be restricted to the reproduction steps of the defect.

Regression testing ensures that previously working functionalities are unaffected by recent changes.

The concept of 'ripple effects' or side effects in a system due to changes, which regression testing aims to identify.

Regression testing is applicable in various scenarios including code updates, migrations, and product environment changes.

Regression testing as a strong candidate for automation, especially in continuous integration practices.

The role of impact analysis in optimizing the scope of regression testing by identifying affected software areas.

Regression test suites often increase with each release iteration, emphasizing the value of automation.

Confirmation and regression testing are applicable at all test levels where changes or defect fixes occur.

The tutorial's aim to clarify the concepts of confirmation and regression testing for better understanding.

Encouragement for viewers to comment with queries for further discussion and learning.

Closing remarks, emphasizing continuous learning and exploration in the field of software testing.

Transcripts

Hello friends and greetings for the day

welcome back to another tutorial on

istqb Foundation level certification we

are in Chapter 2 talking about testing

throughout the sdlc and continuing with

our 2.2 that is test levels and test

types and as a part of this tutorial we

are stepping into the next segment of

this part that is

2.2.3 confirmation testing and

regression testing and as a part of this

we will understand what are those two

things which we can conduct when it

comes to change related testing

[Music]

when it comes to confirmation and

regression testing these two are

generally considered as a separate

category altoe and called as change

related testing why change related

testing because these two testing are

only conducted when it comes to the

changes performed in an application so

let's understand step by step that what

these two levels are or these two test

types are all about and why do we call

them as change related testing the

number one is confirmation testing which

is very much commonly known as retesting

as well and this is generally conducted

when we report a defect so the story

goes something like this when it comes

to a tester testing a particular module

or a functionality and one of the test

case fails resulting into reporting a

defect to the developer in order to get

that fixed of course the developer will

work on it fix it and return back the

tester with those fixes now of course a

very first Common intention says that

you will rerun the same activity what

resulted into a defect but this time to

confirm if the defect has been fixed and

that's what the name is all about

confirmation testing now what is the

twist between confirmation and retesting

most of the organization prefer calling

this as retesting while when it comes to

istqb they have a standard naming

convention called as confirmation

testing why because istqb has to deal

with the entire world but not limited to

one particular organization where some

of the organization did claim that hey

retesting is a generic English word

which means repeating a test with reason

without a reason I just repeat a test I

call it as retesting but confirmation

testing is not without a reason it's

particularly with an objective to

confirm that the report of defect has

been resolved and it is working fine now

so as it comes with an objective we just

it as confirmation testing but again a

lot of industry in fact many Industries

in the world prefer calling this as

retesting so no conflicts it's just that

istqb prefers to call it as confirmation

testing but not retesting so keep that

in mind and that would help you so as we

all understood that it is very simple to

say when you report a problem and

somebody says we have resolved the issue

the very first thing which you will do

when you get the gadget back is to

confirm the fix and that's what you do

so simple like for example my cell phone

was not playing a song and I go to a

particular support center and of course

the support center says that hey I think

there's a hardare issue you can you know

we can fix it back and give it to you

and when you get the phone back the very

first thing you will do is play the song

because the audio was not working fine

right and that's what is confirmation

testing so let's quickly check up that

what exactly the syllabus wants to

convey us so that we are even addressing

and adhering to the cabus content so

when it comes to confirmation testing

confirmation testing confirms that an

original defect has been successfully

fixed depending on the risk one can test

the fixed version of the software uh in

several ways including executing all

test cases that previously have failed

due to the defect or also by adding new

test to cover any changes that were

needed to fix the defect so I think this

particular part is very very clearly

also trying to remind you that we have a

principle called as pesticide Paradox if

you think just as a result of fix ing a

defect you need to add some more new

test cases to make the value of quality

a little more better and have a better

coverage then you can certainly do so so

it's not restricted only to one

particular test you can certainly add

more test if required but most important

intention and objective is to confirm

the fix they also want to add here that

however when time or money is short when

fixing defects confirmation testing

might be restricted to Simply exercising

the steps that should reproduce the

failure caused by the defect and

checking that the failure does not occur

so which is pretty much the

straightforward definition to

confirmation so we may not do any

additional thing that is adding a new

test case or repeating other defect

related test cases but we just do it so

again I think we just trying to add more

value to it but keeping it very short

and simple confirmation testing or

retesting is just limited to repeating

that test case which revealed the

problem once again to confirm the fix

okay so let's not get confused here

because in realtime industry we do

beyond the single test similarly when it

comes to the next one that is regression

testing regression testing is basically

to make sure that everything what was

working fine earlier is still working

fine taking the quick example what we

just took say for example you reported

the phone that my phone is playing an

audio but I'm not able to hear anything

uh that is like speakers are not working

so when you go to the sports and they

fixed it the very first thing what you

will do is confirmation testing or

retesting to confirm whether the

reported effect has been fixed but at

the same time you realize that this

gentleman or person attending you has

fixed something in your phone that is

Hardware replacing the speaker so it

might be possible that he might have

Disturbed something else or this new

speaker may not be compatible with other

parts of the phone and thus we do cross

check by making a call trying to take a

cellone Fe that is like checking your

cameras front camera rear camera signal

strength and lot many other things right

or whether the file and force file and

folders are exactly the same or

something got deleted so what what do we

call this after confirmation testing and

that what we refer it to as regression

so regression mainly means that as a

step what we take in order to fix

something or add something or even just

modify something for any other reason a

change may not be just complying with

everything what is already existing and

this change May create adverse side

effects is as simple as that like you

give go to a doctor and doctor gives you

some medicine and ask you to visit again

that's mainly for regression testing

just to make sure that the medicines are

working fine with you you do not have

any side effects of these medicines and

this works absolutely okay and same way

regression testing is mainly conducted

that okay the defect got fixed but post

that the other things which we working

fine has been any kind of side effects

or not right because there are

possibilities not mandatory but there

are possibilities a change in the code

may have Ripple effects or side effects

to the existing part of the system which

was working fine Al now regression

testing is something which is not

conducted every time just the defect is

fixed they are even applicable when you

add a line of code or you remove a line

of code or even if you migrate a product

from one environment to another per

environment so regression is applicable

when the defects are fixed when the

updates happen when the upgrades happen

migrations takes place so all these

examples we'll be discussing in more

detail in our next topic 2.4 maintenance

testing but on a high level regressions

are just not limited that whenever a

defect is fixed I do conduct regression

it can be done in many other cases also

and that's where we say that change

related testing that means whenever a

change takes place and change can be

anything it can be an addition of line

can be removal of a line or it can be

editing of an existing line of code and

that change invites you to conduct

regression regressions are always seen

as good candidate of automation because

quite often we keep doing regressions to

make sure that things are working

absolutely fine whenever you check in a

new piece of code so let's quickly see

what exactly the syllabus is trying to

convey you when it comes to regression

testing it is basically to confirm that

no adverse consequences have been caused

by a change including a fix that has

already been confirmed confirmation

tested these adverse consequences could

cause affect the same component where

the change was made other components in

the same system or even other connected

systems that means the white the ripple

effect can be seen at multiple levels

not just limited to the place where the

changes were made regression testing may

not be restricted to the test object

itself but can also be related to enir

it is advisable first to perform the

impact analysis to optimize the extent

of regression testing impact analysis

shows which part of the software could

be affected so highly important to

remind you again that impact analysis is

a part of Maintenance testing and we'll

be covering that there in more detail

but for now impact analysis is a study

which helps you understand what areas

will be impacted by the change it is

actually helpful in reducing your effort

on regression testing let's add further

we talk about regression test Suites are

run many times and generally the number

of regression test cases will increase

with each iteration on release so

regression testing is a strong candidate

of automation also automation of these

tests should start early in the project

where CI which is continuous integration

is used such as in devops it is good

practice to also includ automated test

into the pipeline depending on the

situations this may include regression

test on different levels that means

confirmation testing and regression

testing are not something which is

limited to a particular level that means

it can be conducted in static testing

Dynamic testing all the levels like unit

integration system performance usability

wherever we have a change involved we

need to make sure that this change

doesn't have a side effect on the other

existing part of the system which were

working fine earlier further adding up U

confirmation testing and regression

testing for the test object are needed

on all test level if defects are fixed

and or changes are made on these test

levels so I think that was all just I

made so I think that makes it very clear

and understandable to anyone that what's

a confirmation or retesting all about

and regression testing is so that's all

from this particular tutorial team

should you have anything else feel free

to comment below I'm always there to

address your queries and answer them

well till then keep learning keep

exploring keep understanding the context

thanks for watching the video team and

happy

learning

[Music]