ISTQB FOUNDATION 4.0 | Tutorial 12 | Shift Left Approach | Retrospective and Process Improvement
Summary
TLDRThis 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
📚 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.
🛠 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.
🤝 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.
Mindmap
Keywords
💡SDLC
💡Shift Left Approach
💡Retrospective
💡Testing in Context
💡CI/CD
💡Static Testing
💡Dynamic Testing
💡Test Harness
💡Non-functional Testing
💡Process Improvement
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]
Ver Más Videos Relacionados
ISTQB FOUNDATION 4.0 | Tutorial 11 | TDD, BDD, ATDD | DevOps and Testing | CTFL | TM SQUARE
ISTQB FOUNDATION 4.0 | Tutorial 22 | Sample Questions on Chapter 2 | ISTQB Foundation Mock Questions
ISTQB FOUNDATION 4.0 | Tutorial 57 | Tool Support for Testing | Test Tools | ISTQB Tutorials
ISTQB FOUNDATION 4.0 | Tutorial 3 | 1.2 Why Testing is Necessary | ISTQB Tutorials | TM SQUARE
ISTQB FOUNDATION 4.0 | Tutorial 5 | 1.4 Test Activities, Testware & Test Roles (Part-1) | CTFL
ISTQB FOUNDATION 4.0 | Tutorial 14 | Test Levels | Component Integration Testing | CTFL Tutorials
5.0 / 5 (0 votes)