Static testing is a crucial early-stage software development practice that involves reviewing work products to detect and prevent defects before execution, ultimately saving time, money, and improving overall quality.
Mind Map
Clique para expandir
Clique para explorar o mapa mental interativo completo
Hello friends and greetings for the day
welcome back to another tutorial on
istqb Foundation level certification we
are getting started with chapter 3
talking about static testing and as a
part of this we'll be getting started
with our first segment that is 3.1
static testing Basics and it has several
other subtopics today we'll be covering
3.1 work products examined by Static
testing and
3.1.2 the value of static testing so as
a part this tutorial we'll be
introducing you to how we can prevent
[Music]
testing to get started of course we are
talking about a quick introduction to
what is static testing all about so we
have indeed discussed this in our
earlier tutorials static testing is all
about reviewing the work products and
different work products do exist in our
entire zlc model and certainly they are
a good candidate of static testing that
means they must be reviewed for any kind
of anomalies inconsistencies
contradictions omissions Etc and being
reported right as in when they are
created it's it's very simple to
understand by correlating it to
principle number three that is early
testing saves time and money and at the
same time one of the objective of
testing is also to prevented effect
testing is just not limited to writing
and executing test cases as we learned
from chapter one we want to let you know
that in more detail that how static
testing can be conducted and what could
be the best possible benefits of having
static testing being conducted early in
the life cycle so let's quickly have a
look what exactly the introduction is
trying to say and there are different
terminologies what we are trying to look
forward to so when it comes to static
testing in contrast to Dynamic testing
in testing that is static testing the
soft Ender test does not need to be
executed it's more of like statically
review in the work products rather than
executing the product or the test cases
the code process specification system
architecture specification or any other
work products are generally evaluated
through manual examinations which are
conducted with two different ways of
course if you're doing it manually by
reading the documentation it's called as
review or with help of tools that is
static analysis so right here if I am
talking about a document like test case
requirement Etc which I have to go
through myself read it and find the
anomalies related to that I call it as a
review process which is static testing
however when it comes to the other part
of it for example things like control
flow diagram business models or code
especially then code is not certainly
something which I can read and find the
anomalies in it could be any number of
lines of code which could be sometime
very complicated to go through line by
line and actually identify the anomalies
so I need to take the help of tools and
such tools or such approach of reviewing
is called as static analysis so just a
simple difference when you do it
yourself by reading the documentation
you call it as review but you do the
same review with help of the tools you
call it as static analysis further to
add of course when it comes to static
testing the test objectives include
improving quality detecting defects and
assessing characteristics right
readability completeness correctness
testability and consistency static
testing can be applied for both
verification and validation that means
it's just not limited to only the work
products which we create initially in
the life cycle it also works when it
comes to the dynamic analysis or things
like you know reviewing the execution
report defect report Etc so uh testers
business representative and developers
both work together during example
mapping collaborating user story writing
and backlog refinement sessions to
ensure that user stories and related
work work products meet defined criteria
for an example definition of ready so in
simple words of course when it talks
about agile all the collaborative
activities do take place and it's just
not a one person responsibility to
review the work product we may invite
multiple cross functional stakeholders
to come and join us in order to find the
best possible defects in the static
documentations itself or the work
products also to add uh review
techniques can be applied to ensure user
stor are complete understandable and
include testable acceptance criteria by
asking the right questions testers
explore challenge and help improve the
proposed user stories so put together we
do have different types of techniques
which can be made use of in order to
make the most out of the existing part
of the process and that certainly brings
out a lot of value to us also to add
further we do have static analysis being
defined further so static analysis can
identify problems prior to Dynamic
testing in while often requiring less
effort since no test cases are required
and tools are typically used static
analysis is often incorporated into CI
Frameworks while largely used to detect
specific code defects static analysis
also used to evaluate maintainability
and security spelling Checkers and
readability tools are other examples of
static analysis tool however we do have
more specialized tools available to deal
with different languages but a generate
static analysis tool would help you to
analyze the code and find anomalies
related to coding standard deviations or
some mistakes like unreachable code the
dead code the infinite Loop or the
variables which are declared but never
used or the variables which are used but
never declared so all these kind of
anomalies can be easily found by having
use of this particular tool so put
together introduction to static testing
says that we have two different ways to
do it that is reviews and static
analysis to talk further of course we
are talking about what kind of work
products are good candidate of static
testing that means is there any specific
list of documentation or work product
which are used or referred or reviewed
using static testing but in simple words
I would like to say that any such work
product which you create as a part of
sdlc including business work product the
development work product or testing work
products are by default a candidate of
review be about a requirement be about a
code beat about a test case test plan
project plan any such document must be
reviewed for a normaly because we just
accepted and understood in chapter one
as per the human psychology human is
eror prone a human can go wrong anywhere
no matter what they are doing and that
mistake should be found before we
further interpret it in other activities
like design and development so when it
comes to the work products which we must
be making use of so almost any work
product can be examined using static
testing examples includes requirement
specification document Source Code test
plan test cases product backlog items
test Charters project documentation
contracts and models that means every
single thing it's just not that there
are some specific items which we review
every single thing maybe of course uh
not formally but informally you can
certainly review them also to add uh any
work product that can can be read and
understood can be subject of a review
however the static analysis work
products need to structure against which
they can be checked so not everything
can certainly be just read and you know
tested but uh things like code and
control flow diagram data flow diagram
or business models can be done with the
help of the
Tool Work products that are not
appropriate for static testing include
those that are difficult to interpret by
human beings and that should not be
analyzed by the tools so here basically
the third party ex executable code due
to legal reasons so we must be uh kind
of like restricting ourself to that of
those things which I must review before
going into action but not getting into a
legal sanction also our third segment is
talking about what is the key value of
having static testing being conducted as
a part of the process because it's very
important for one to know that how
important and beneficial it could be
when it comes to static testing however
static testing is not something new it
has been being conducted from a long
time but being brought into attention
recently for a few years that means
people were not giving value to static
testing at all thinking that it is a
waste of time come on who does read the
document we look forward to find the
bugs but today people are talking about
prevention of bugs which indeed was
there from a long time because istqb did
not write this for the first time it was
written 20 years ago but it's just that
the people who ignore a few things for
some time but later realize that oh it
was worthy enough to do and today we are
talking about shift left you're talking
about prevention my question is where
were you 20 years
ago anyway so I'm not here to have a
dispute and controversial talks but uh
let's have a word quickly to understand
what is the value of static testing
being conducted so static testing
certainly can detect defects in an
earliest phase of the sdlc fulfilling
the princi principle of early testing
that is testing saves cost and time that
is early testing saves cost and time it
can also identify defects which cannot
be detected by Dynamic testing for
example things like unreachable code
design patterns not implemented as
desired defects in non-executable work
product also static testing provides the
ability to evaluate the quality of and
to build confidence in the work product
by verifying the documented requirements
the stakeholders can also make sure that
these requirements describes their
actual needs see again the point being
made here is why would I go through a
requirement altogether number one to
find anomalies made by human mistakes
second if the requirements are unclear
incomplete inconsistent ambiguous vague
that means cannot be achieved I can go
and point this out and make sure that we
have a very clear set of requirement
with us because starting to implement
and then realizing that this is not
something we can achieve this is not
something we can test is actually not
correct because you'll be stuck or
probably you would have wasted a lot of
your time so in that context it is very
important that you should look forward
to review them in advance before you
start working on them also
Communications will uh be improved
between the involved stakeholders for
this reason it is recommended to involve
a wide variety of stakeholder in static
testing so indeed uh static testing
brings multiple stakeholders together in
order to review the provoked product
commonly and in that context context we
do have a better communication
established among the team member and
healthy relationship so static testing
do claim that by doing static testing in
your organization you can have healthier
relationship among the team member the
other point I think I missed since
static testing can be performed early in
the sdlc a shared understanding can be
created among the involved stakeholders
see uh sometime we do find that there
are a lot of defects which are just
created due to misunderstanding of the
same piece of information inform between
two different stakeholders for example
there's a requirement I understand it as
X and developers understand it as a why
so until unless we both sit together and
have a discussion on to we know we will
not have a very common understanding at
all so we will always be conflicting or
probably misunderstanding things that
what it should
be talking about other point that is
even though review can be costly to
implement the overall project costs are
usually much lower
than when no reviews are performed
because less time and effort needs to be
spent on fixing defects later in the
project so all you're trying to say that
we may think that unnecessary cost has
been involved by conducting reviews
before doing Dynamic testing but if you
find a defect in Dynamic testing which
is related to misunderstanding of
requirement you're actually putting that
time of you know uh usage into a waste
other around right so conducting static
testing in the beginning certainly can
save your overall cost of doing your
work more effectively efficiently and on
time by just having static testing in
place so it's not that it is actually
expensive it's just that we may feel it
but over a long period of time or if you
consider the whole project it is cheaper
enough also to add uh the code defects
can be detected using static analysis
more efficiently than in Dynamic testing
usually resulting in both fewer code
defects and a lower lower overall
development effort so certainly static
analysis has reduced a lot of our
productivity cost and the overall time
taken to do that so it certainly brings
a lot of value by having static testing
in place and in practice so put together
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 Beauty and happy
[Music] learning
Clique em qualquer texto ou marcação de tempo para ir diretamente àquele momento do vídeo
Compartilhar:
A maioria das transcrições fica pronta em menos de 5 segundos
Cópia com um cliqueMais de 125 idiomasPesquisar no conteúdoIr para marcações de tempo
Cole a URL do YouTube
Insira o link de qualquer vídeo do YouTube para obter a transcrição completa
Formulário de extração de transcrição
A maioria das transcrições fica pronta em menos de 5 segundos
Instale nossa extensão para Chrome
Obtenha transcrições na hora sem sair do YouTube. Instale nossa extensão para Chrome e acesse com um clique a transcrição de qualquer vídeo direto na página de reprodução.
