ISTQB FOUNDATION 4.0 | Tutorial 12 | Shift Left Approach | Retrospective and Process Improvement

Summary

This tutorial delves into the ISTQB Foundation's Chapter 2, focusing on testing within the SDLC. It introduces the 'Shift Left' approach, emphasizing early testing activities like reviewing specifications and writing test cases before code implementation. The script also covers the benefits of retrospectives for process improvement, highlighting the importance of team collaboration, continuous learning, and the integration of CI/CD for faster feedback. The tutorial aims to enhance test effectiveness, efficiency, and quality through proactive measures and regular process reviews.

Takeaways

• 😀 The 'Shift Left Approach' is a new topic in the ISTQB Foundation syllabus, emphasizing the importance of moving testing activities earlier in the software development life cycle.
• 🔍 Shift Left involves reviewing specifications for potential defects such as ambiguities, incompleteness, and inconsistencies to prevent issues early on.
• 📝 Writing test cases before code is written, and using a test harness during code implementation, is a key practice in achieving a Shift Left in testing.
• 🔄 Continuous Integration (CI) and Continuous Deployment (CD) are essential for providing fast feedback and automating component tests when source code is submitted.
• 🔍 Static analysis of source code should be completed prior to dynamic testing as part of the automated test process within CI/CD pipelines.
• 🚀 Performing non-functional testing at the component level is a form of Shift Left that can help identify issues early, preventing late-stage surprises.
• 💡 Shift Left can incur additional training and cost upfront but is expected to save effort and cost in the long run.
• 🤝 Stakeholder buy-in is crucial for the successful implementation of the Shift Left approach, requiring training and understanding of the initial investment.
• 🔧 Retrospectives are meetings held among team members and stakeholders to discuss what could be improved and how to prevent past mistakes in future projects.
• 📈 Retrospectives are critical for process improvement and should result in actionable recommendations that are followed up on.
• 👥 The benefits of conducting retrospectives include increased test effectiveness, better quality of testware, team bonding, improved test base quality, and enhanced cooperation between development and testing teams.

Q & A

What is the shift left approach in software testing?

The shift left approach in software testing involves moving testing activities earlier in the software development life cycle. This means conducting testing tasks such as reviewing specifications and writing test cases before the code is written to identify defects as early as possible.

Why is early testing important in the shift left approach?

Early testing is important in the shift left approach because it helps identify and fix defects sooner, which is cheaper and more efficient than fixing them later in the development process. This leads to better quality and more reliable software.

What are some practices to achieve a shift left in testing?

Some practices to achieve a shift left in testing include reviewing specifications from a testing perspective, writing test cases before code is written, using continuous integration (CI) and continuous delivery (CD) pipelines, and performing static analysis and non-functional testing early in the development process.

What is the role of CI/CD in the shift left approach?

In the shift left approach, CI/CD plays a crucial role by automating testing and integration processes. This ensures that tests are run automatically whenever code is checked into a repository, providing fast feedback and enabling early detection of defects.

How does static analysis fit into the shift left approach?

Static analysis involves examining the source code for potential defects without executing it. In the shift left approach, static analysis is performed early in the development process to identify issues such as code quality problems and security vulnerabilities before they can cause problems later.

What is the purpose of performing non-functional testing early in the development process?

Performing non-functional testing early helps identify performance, security, and other non-functional issues at the component level. This ensures that the system is more stable and has fewer issues when it reaches later stages of testing.

What are retrospectives and how do they contribute to process improvement?

Retrospectives are meetings held to review and discuss what was successful, what was not, and how to improve in future iterations. They involve team members and stakeholders discussing ways to enhance the process, leading to continuous improvement and better project outcomes.

What are the typical benefits of conducting retrospectives?

The typical benefits of conducting retrospectives include increased test effectiveness and efficiency, improved quality of testware, enhanced team bonding and learning, better cooperation between development and testing teams, and higher overall quality of the test bases.

When are retrospectives usually conducted?

Retrospectives can be conducted at the end of a project, an iteration, a release milestone, or as needed. In agile methodologies, they are often held at the end of each sprint or release.

What are the key questions discussed during retrospectives?

During retrospectives, the team typically discusses three key questions: What was successful and should be retained? What was not successful and can be improved? How to incorporate the improvements and retain the successes in the future?

Outlines

00:00

📚 Introduction to Shift Left Approach and Retrospectives

This paragraph introduces the concept of the 'Shift Left Approach' in the context of software development and testing. It explains that the approach involves moving testing activities earlier in the software development life cycle (SDLC) to find and fix defects as early as possible, which is more cost-effective. The paragraph also mentions the importance of retrospectives, which are meetings held to discuss what went well and what can be improved in the testing process. It emphasizes the benefits of early testing, such as preventing defects and improving the overall quality of the software.

05:02

🛠 Best Practices for Achieving Shift Left in Testing

The second paragraph delves into best practices for implementing the Shift Left Approach. It suggests reviewing specifications from a testing perspective to identify ambiguities and inconsistencies, writing test cases before code implementation, and utilizing continuous integration (CI) and continuous delivery (CD) for automated testing. The paragraph also highlights the importance of static analysis and non-functional testing at the component level to ensure system stability and performance. It acknowledges that while the Shift Left Approach may require additional effort and cost initially, it is expected to save resources in the long run.

10:03

🤝 The Importance of Stakeholder Buy-in and Training for Shift Left

This paragraph discusses the challenges and considerations for organizations adopting the Shift Left Approach. It stresses the need for stakeholders to understand and support the concept, as well as the necessity for training teams to adapt to the new process. The paragraph addresses potential concerns about the timing of reviews and the clarity of requirements, suggesting that reviews should begin once business analysts or product owners have provided a final version of the requirements. It also emphasizes the importance of starting the review process early to identify and resolve issues before they become more costly to fix.

🔄 The Role of Retrospectives in Continuous Improvement

The final paragraph focuses on the role of retrospectives in improving the testing process. It describes retrospectives as meetings where team members discuss successes, areas for improvement, and how to incorporate changes for future projects. The paragraph outlines the typical structure of a retrospective, including the questions asked and the collaborative approach to identifying and implementing improvements. It also highlights the benefits of retrospectives, such as increased test effectiveness, improved testware quality, team bonding, and better cooperation between development and testing teams. The paragraph concludes by emphasizing the importance of documenting and following up on the outcomes of retrospectives to ensure continuous improvement.

Keywords

💡SDLC

SDLC stands for Software Development Life Cycle, which is a process used by developers to plan, create, test, and deploy an information system. In the video, SDLC is discussed in the context of where testing fits within this cycle, emphasizing the importance of testing throughout the entire development process to ensure quality and prevent defects.

💡Shift Left Approach

The 'Shift Left Approach' is a strategy in software development that involves moving certain activities, such as testing, earlier in the SDLC to find and fix defects sooner. The video explains this concept as a way to improve efficiency and reduce costs by addressing issues at the earliest possible stage, using examples like reviewing specifications and writing test cases before code implementation.

💡Retrospective

A retrospective is a meeting held at the end of a project or iteration where team members reflect on what went well and what could be improved. In the video, retrospectives are discussed as a tool for continuous improvement, with the team discussing successes, areas for improvement, and changes to be made in future projects, which aligns with the theme of enhancing the development process.

💡Testing in Context

The term 'Testing in Context' refers to the consideration of various factors and stages within the SDLC when planning and conducting tests. The video script discusses this in relation to the shift left approach, emphasizing that testing should be integrated and considered from the early stages of the development cycle.

💡CI/CD

CI/CD stands for Continuous Integration/Continuous Deployment, which are practices in software development that aim to improve the process by automating the integration and deployment of code changes. The video mentions CI/CD in the context of the shift left approach, highlighting the use of automated tests and static analysis as part of the development pipeline to provide fast feedback and improve code quality.

💡Static Testing

Static testing involves reviewing and analyzing software without executing it, typically to find defects in the requirements or design phase. The video script refers to static testing as a part of the shift left approach, where reviewing specifications can identify ambiguities and inconsistencies before the code is even written.

💡Dynamic Testing

Dynamic testing is the process of executing software to validate its behavior and ensure it meets the requirements. The video contrasts dynamic testing with static testing, mentioning that while static analysis can be done early in the process, dynamic testing is usually conducted later, but the shift left approach encourages earlier consideration of non-functional testing.

💡Test Harness

A test harness is a set of software and tools that allows for the testing of other software components. In the video, the concept of a test harness is introduced as part of the shift left approach, where code is run in a test harness during the code implementation phase to ensure early detection of issues.

💡Non-functional Testing

Non-functional testing focuses on aspects of software performance that are not related to its functionality, such as security, performance, and usability. The video script discusses the importance of starting non-functional testing at the component level as part of the shift left approach, to identify and address issues like leaks or misused data types early in the development process.

💡Process Improvement

Process improvement refers to the ongoing efforts to enhance the efficiency and effectiveness of a process. In the video, process improvement is discussed in the context of retrospectives, where the team identifies what they could have done better and how to prevent similar issues in the future, aligning with the overarching theme of improving the software development lifecycle.

Highlights

Introduction to the shift left approach in the context of software development life cycle.

Shift left approach defined as moving testing activities earlier in the life cycle to find and fix defects sooner.

Importance of reviewing specifications for potential defects such as ambiguities, incompleteness, and inconsistencies.

Writing test cases before code implementation and the concept of Test-Driven Development (TDD), Behavior-Driven Development (BDD), and Acceptance Test-Driven Development (ATDD).

Utilizing Continuous Integration (CI) and Continuous Deployment (CD) for automated testing and feedback.

Incorporating static analysis and automated component tests in the CI pipeline.

Performing non-functional testing at the component level to identify issues early in the development process.

The potential extra cost and training effort required for the shift left approach, with expected long-term savings.

The necessity for stakeholders to understand and support the shift left concept for successful implementation.

The role of retrospectives in process improvement, including their definition and purpose.

Retrospectives as a team meeting to discuss what went well and what can be improved, without blaming individuals.

The timing and organization of retrospectives depending on the SDLC model being followed.

The three key questions discussed during retrospectives: what to start, continue, and stop doing.

Documentation of retrospective outcomes as part of the test completion report and meeting minutes.

The importance of following up on retrospective recommendations for continuous improvement.

Benefits of conducting retrospectives, such as increased test effectiveness, improved quality of testware, and better cooperation between development and testing teams.

The tutorial's conclusion emphasizing the importance of learning, exploring, and understanding the context of testing methodologies.

Transcripts

Hello friends and greetings for the day

welcome back to another tutorial on

istqb Foundation we are in Chapter 2

talking about testing throughout the

sdlc and continuing ahead with our 2.1

which is testing in context of software

development life cycle and as a part of

this particular segment we are moving on

to the last two segments of this segment

that is

2.1.5 shift left approach and

retrospective and process Improvement so

let's have a look quick that what shift

left approach is all about and how

retrospectives have helped team to

improve the

process the very first thing we are

talking about a shift left approach

indeed this is one of the new topic

added to the new syllabus and uh of

course that does not make a difference

because people who are Learning

Foundation they don't even know what

syllabus we had earlier but it is a new

topic from from this particular syllabus

or this version 4.0 in general words

shift left approach certainly means that

something which was happening later in

the life cycle is now happening a bit

earlier compared to that of the earlier

so in that context the things have been

moved or preponed in the life cycle and

being conducted right from the early

stages of the life cycle and that's what

we basically call it as a shift left

approach that simply means preponing the

activities to that of what it was

actually

so let's deep dive into this and try to

understand how exactly this would make

more sense and what are those shift left

approaches and activities we are

referring to so to talk about that of

course uh there are some good practices

that illustrates how to achieve a shift

left in testing some of them include

number one reviewing the specification

from the perspective of testing and

these review activities on specification

often find potential defects such as

ambiguities incomp incompleteness and

inconsistencies I think this is one of

the very common things what we have been

talking right from the chapter one we

told you that one of the objective of

testing is to prevent defects and at the

same time we told you that principle

number three is all about early testing

so shift left is nothing new but

certainly we have been doing it by

preponing some of our testing activities

to that of the life cycle and trying to

find defects as soon as possible so that

it is cheaper to fix and makes us more

comp comp able to do better testing

related to the dynamic failures compared

to that of requirement misunderstanding

so of course we'll have a dedicated

chapter on this that what is static

testing how does it help us find defects

and what exactly the whole approach of

reviewing is all about but for that we

will have to come to chapter 3 let's

look at the next Point here the next

Point here talking about writing test

cases before the code is written and

have the code run in a test harness

during the code implementation I think

we gave you a quick Outlook of what is

TD DD bdd and atdd and in these context

we very well know now that we write test

cases prior to writing the code or

writing the implementations so of course

that's the pre pointment again and

that's one of the other activity of

testing which is being looked forward to

have a shiftleft approach the next one

here is using CI and even better CD as

it comes to the fast feedback and

automated component test to accompany

the source code when it is submitted to

the code Repository

now in this context I think it's very

straightforward that if I have some test

created in a pipeline of cicd then

certainly the executions will be taking

place as in when a code is checked in so

I don't have to have a manual inter

intervention or wait for someone to go

ahead and run those test rather all

these tests can be embedded as a part of

the pipeline and as in when a code is

checked into a branch the branch will

execute all other required test cases or

executions of unit testing Etc static

analysis which we covered in our

previous tutorial and that's all can be

done much ahead of before we come into

the dynamic testing phase also to add

here we do have completing static

analysis of source code prior to Dynamic

testing or as a part of automated test

process so of course as a part of cicd

we already told you that it's not just

one thing which happens automatically as

a part of the pipeline we do take care

of many other things like static

analysis unit testing and few set of

feature test or regression test these

all can be embedded as a part of the

automated CI pipeline the next one and

the last one here to talk about is

performing nonfunctional testing

starting right at the component test

level where possible now this is a form

of shift leftt as these non-functional

test types tend to be performed after or

later in the sdlc when a complete system

and a representative test environment is

available indeed I think uh again when

the test levels going down the line we

will talk about it but on a high level

we all know that in order to conduct any

non-functional testing I need a very

stabilized system so generally

non-functional tests are conducted after

system testing has passed but just

because I cannot come and tell you the

minor issues after system testing

because that's too late for us to let

you know that hey this particular

variable is declared but not killed or

not you know closed at the end of the

program which is creating a leak right I

cannot talk about while pointers I

cannot talk about some of the data types

which are misused at the system level or

after system level so it's always

recommended right from the beginning

that performance testing team is

requested to join right from the

component test levels so that they can

even review the code and raise these

anomalies so that at system level you

will have a very stabilized system and

less performance issues or less security

issues or less interoperability issues

and all other non-functional s which can

be done pretty smoothly compared to that

of later without any intervention okay

so we always recommend indeed we have

been doing that it's nothing new but

it's just that many organizations were

unaware of that and we would like to let

them know about it also to add here of

course a shift left approach might

result in extra tuning uh extra training

effort and or cost earlier in the

process but is expected to save a lot of

effort and or cost later in the process

also for for the shift left approach it

is important that the stakeholders are

convinced and bought into this concept

that means of course it's not an easy

job for any organization to just blindly

start rolling out these kind of changes

into their process the most important

thing is the team has to be trained and

the management has to understand the

required budget to perform these

activities at an initial level sometimes

from the realtime perspective we do get

these questions from the team that how

is it even possible to start reviewing

when the business analyst themselves do

not have the clarity on the requirement

answer is absolutely true right because

even ba says that I have not getting all

the clear requirements from the business

so why are you reporting all these

defects or what's the point of reviewing

the requirement at this point of time

the question is at some point of time

business analyst will have a Clarity on

the requirement let's begin that okay or

let's begin at that point of time when

the business analyst says that hey this

is something final from my side and you

can go ahead and start preparing right

or start working on it now that's the

point we are talking about that shift

left that is you can start reviewing the

requirement and say okay hold on before

I start implementing on this let me just

ask you some questions because I have

some clarity issues okay so we are not

talking about that early when business

analyst or po doesn't even know what is

the requirement we are talking about the

early point when the business analyst or

PO says we have it complete now you can

go ahead okay but we should start with

reviewing so that we can find anomalies

well another important thing here we

talking about is what is retrospective

of course many of us learning this

tutorial would already be aware of that

but as a part of the syllabus we will

have to discuss that what is

retrospective and how does it help the

entire process to improve over a period

of time the most important thing here is

retrospective is basically a meeting

held between the team members along with

the other respective uh stakeholders

like Po and scrum master and here we

bring out every individual of the team

member brings out their way of you know

answering certain questions like you

know what we could have done better or

what we should have not done how we can

prevent these things in future and we

just point out everything as a team not

on individuals of course we don't point

the finger on the individual from the

basic skills we should know that from

the chapter one also we have discussed

psychology of testing so we don't point

out any finger on an individual rather

everything on the process that hey

writing this particular document is unne

necessary and we are wasting our time

why don't we stop doing that

recommendation let the team agree to

that and it is always a whole team

approach so remember you don't make a

decision alone and you don't point out a

finger on someone particularly so

retrospective is that meeting which will

help you understand uh Define how you

can improvise yourself or your process

over a period of time and this certainly

brings back to the overall process

Improvement alog together so let's

quickly see what exactly this topic is

trying to say and what do we need to

remember from here number one

retrospective which is also known as

post project meetings and project

retrospectives are often held at the end

of the project or an iteration or at the

release Milestones or can be held when

needed that means there are no specific

timelines depending on different sdlc

models for example if you are in

traditional models we do it once at the

end of the project but if you are in an

aile methodology like scrum or canbin

you may even do it at the end of each

Sprint or releases right where a project

can be combination of multiple releases

or to certain extent today you can say

that you can have weekly retrospective

if your process or project is very

critical and you just don't want to take

any chances so in that context we can

even conduct you know retrospectives to

you know improve it at any point of time

so generally we do conduct it at the end

of iterations or releases or at the end

of the project but it's up to you how

exactly you want to improve your process

and how serious you are about it okay so

the timing and organization of

retrospective depends on the particular

sdlc model being followed now in these

meetings the particulars participants

not only testers but also developers

architect product owners business

analyst will generally discuss three

important points or three different

important questions that what was

successful and what should be retained

what was not successful and can be

improved and what to incorpor orate how

to incorporate the improvements and

retain the successes in the future I

think that's making it very very

straightforward the retrospectives are

all about what we should start doing

what we should continue doing and what

we should stop doing and simple word

start doing is an innovation is an idea

which you can bring up to the

process continue doing means you have

been doing it and you would love to

continue that because that's something

as a helpful activity or supporting or

good practices and third is stop doing

his bad practices which you can say that

hey we just kind of like we tried it out

and didn't work out so let's not do it

again right so three important questions

which all the team members gather

together and look forward to improve in

the overall process given that we have

this information with us we will be able

to Define good process altogether to

achieve our goals on time and with

complete efficiency further to add on

the retrospective we are talking about

the outcome of the retrospectives of

course the results should be recorded

and are normally part of the test

completion report which should be a part

of our like documentation and a minutes

of meeting having information from

everyone being gathered should be

documented so that if required it can be

referred right from the next print next

release or next project as well so it's

very common practice to document the

retrospective inputs and the practices

what we gain from there and

retrospectives are generally critical

for the successful implementation of

continuous Improvement and its important

uh that recommendation improvements are

followup so no matter whatever the

recommendations or suggestions what you

get from the team it is just not for

documenting and conducting for the name

of uh just conducting it so on the sake

of name so we just wanted to let you

know that it's just not about conducting

the event capturing the decoded list of

documentations but also supposed to be

followed up in order to make sure that

you apply them back otherwise there are

many organizations who are practicing

this but still their process is very

poor because they fail fa fail to follow

up on those uh inputs what they gather

the next thing here to talk about is of

course the typical benefits of uh

benefits of conducting retrospective for

the testing includes number one in

increase test Effectiveness and

efficiency that is by implementing

suggestions from the process Improvement

increased quality of testware that is by

jointly reviewing the test processes and

uh different test artifacts the team

bonding and learning which is as a

result of the opportunity to raise

issues and propose Improvement points

every frequent interval of time and then

improved quality of the test bases

example the deficiencies in the extent

and quality of the requirements could be

addressed and solved also better

cooperation between development and

testing team which is as a collaboration

is reviewed and optimized regularly so

indeed it's a very common practice that

retrospectives do help you to bring up a

lot of best within you and within the

team what you have so mingling up

collaborating and working together will

result into the best process all

together at any point of time so that's

certainly all what we want to convey you

from

retrospectives well 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]