0:02 Hello friends and greetings for the day
0:04 welcome back to another tutorial on
0:07 istqb Foundation level certification we
0:09 are getting started with chapter 3
0:11 talking about static testing and as a
0:12 part of this we'll be getting started
0:16 with our first segment that is 3.1
0:18 static testing Basics and it has several
0:21 other subtopics today we'll be covering
0:24 3.1 work products examined by Static
0:26 testing and
0:29 3.1.2 the value of static testing so as
0:31 a part this tutorial we'll be
0:33 introducing you to how we can prevent
0:44 [Music]
0:46 testing to get started of course we are
0:48 talking about a quick introduction to
0:50 what is static testing all about so we
0:52 have indeed discussed this in our
0:55 earlier tutorials static testing is all
0:57 about reviewing the work products and
0:59 different work products do exist in our
1:02 entire zlc model and certainly they are
1:04 a good candidate of static testing that
1:06 means they must be reviewed for any kind
1:09 of anomalies inconsistencies
1:11 contradictions omissions Etc and being
1:14 reported right as in when they are
1:16 created it's it's very simple to
1:17 understand by correlating it to
1:19 principle number three that is early
1:21 testing saves time and money and at the
1:22 same time one of the objective of
1:24 testing is also to prevented effect
1:26 testing is just not limited to writing
1:28 and executing test cases as we learned
1:31 from chapter one we want to let you know
1:33 that in more detail that how static
1:35 testing can be conducted and what could
1:38 be the best possible benefits of having
1:40 static testing being conducted early in
1:42 the life cycle so let's quickly have a
1:44 look what exactly the introduction is
1:45 trying to say and there are different
1:47 terminologies what we are trying to look
1:50 forward to so when it comes to static
1:53 testing in contrast to Dynamic testing
1:55 in testing that is static testing the
1:57 soft Ender test does not need to be
1:59 executed it's more of like statically
2:01 review in the work products rather than
2:05 executing the product or the test cases
2:07 the code process specification system
2:10 architecture specification or any other
2:13 work products are generally evaluated
2:15 through manual examinations which are
2:17 conducted with two different ways of
2:18 course if you're doing it manually by
2:20 reading the documentation it's called as
2:23 review or with help of tools that is
2:26 static analysis so right here if I am
2:28 talking about a document like test case
2:31 requirement Etc which I have to go
2:33 through myself read it and find the
2:35 anomalies related to that I call it as a
2:38 review process which is static testing
2:40 however when it comes to the other part
2:42 of it for example things like control
2:45 flow diagram business models or code
2:47 especially then code is not certainly
2:49 something which I can read and find the
2:51 anomalies in it could be any number of
2:52 lines of code which could be sometime
2:55 very complicated to go through line by
2:57 line and actually identify the anomalies
3:00 so I need to take the help of tools and
3:03 such tools or such approach of reviewing
3:06 is called as static analysis so just a
3:08 simple difference when you do it
3:09 yourself by reading the documentation
3:12 you call it as review but you do the
3:14 same review with help of the tools you
3:16 call it as static analysis further to
3:18 add of course when it comes to static
3:20 testing the test objectives include
3:22 improving quality detecting defects and
3:24 assessing characteristics right
3:26 readability completeness correctness
3:28 testability and consistency static
3:30 testing can be applied for both
3:32 verification and validation that means
3:34 it's just not limited to only the work
3:36 products which we create initially in
3:39 the life cycle it also works when it
3:42 comes to the dynamic analysis or things
3:44 like you know reviewing the execution
3:48 report defect report Etc so uh testers
3:50 business representative and developers
3:52 both work together during example
3:55 mapping collaborating user story writing
3:57 and backlog refinement sessions to
3:59 ensure that user stories and related
4:01 work work products meet defined criteria
4:04 for an example definition of ready so in
4:05 simple words of course when it talks
4:07 about agile all the collaborative
4:09 activities do take place and it's just
4:11 not a one person responsibility to
4:13 review the work product we may invite
4:16 multiple cross functional stakeholders
4:18 to come and join us in order to find the
4:22 best possible defects in the static
4:24 documentations itself or the work
4:27 products also to add uh review
4:29 techniques can be applied to ensure user
4:32 stor are complete understandable and
4:35 include testable acceptance criteria by
4:37 asking the right questions testers
4:39 explore challenge and help improve the
4:42 proposed user stories so put together we
4:44 do have different types of techniques
4:45 which can be made use of in order to
4:48 make the most out of the existing part
4:50 of the process and that certainly brings
4:52 out a lot of value to us also to add
4:55 further we do have static analysis being
4:57 defined further so static analysis can
4:59 identify problems prior to Dynamic
5:01 testing in while often requiring less
5:04 effort since no test cases are required
5:06 and tools are typically used static
5:09 analysis is often incorporated into CI
5:12 Frameworks while largely used to detect
5:15 specific code defects static analysis
5:17 also used to evaluate maintainability
5:20 and security spelling Checkers and
5:23 readability tools are other examples of
5:25 static analysis tool however we do have
5:27 more specialized tools available to deal
5:29 with different languages but a generate
5:31 static analysis tool would help you to
5:33 analyze the code and find anomalies
5:36 related to coding standard deviations or
5:38 some mistakes like unreachable code the
5:40 dead code the infinite Loop or the
5:42 variables which are declared but never
5:45 used or the variables which are used but
5:47 never declared so all these kind of
5:49 anomalies can be easily found by having
5:51 use of this particular tool so put
5:53 together introduction to static testing
5:55 says that we have two different ways to
5:58 do it that is reviews and static
6:01 analysis to talk further of course we
6:02 are talking about what kind of work
6:05 products are good candidate of static
6:08 testing that means is there any specific
6:10 list of documentation or work product
6:14 which are used or referred or reviewed
6:16 using static testing but in simple words
6:19 I would like to say that any such work
6:21 product which you create as a part of
6:24 sdlc including business work product the
6:26 development work product or testing work
6:29 products are by default a candidate of
6:32 review be about a requirement be about a
6:34 code beat about a test case test plan
6:37 project plan any such document must be
6:39 reviewed for a normaly because we just
6:42 accepted and understood in chapter one
6:44 as per the human psychology human is
6:47 eror prone a human can go wrong anywhere
6:48 no matter what they are doing and that
6:51 mistake should be found before we
6:54 further interpret it in other activities
6:57 like design and development so when it
6:59 comes to the work products which we must
7:01 be making use of so almost any work
7:03 product can be examined using static
7:05 testing examples includes requirement
7:08 specification document Source Code test
7:11 plan test cases product backlog items
7:14 test Charters project documentation
7:16 contracts and models that means every
7:18 single thing it's just not that there
7:21 are some specific items which we review
7:23 every single thing maybe of course uh
7:25 not formally but informally you can
7:28 certainly review them also to add uh any
7:30 work product that can can be read and
7:33 understood can be subject of a review
7:36 however the static analysis work
7:38 products need to structure against which
7:40 they can be checked so not everything
7:43 can certainly be just read and you know
7:45 tested but uh things like code and
7:47 control flow diagram data flow diagram
7:49 or business models can be done with the
7:50 help of the
7:53 Tool Work products that are not
7:55 appropriate for static testing include
7:57 those that are difficult to interpret by
7:59 human beings and that should not be
8:02 analyzed by the tools so here basically
8:05 the third party ex executable code due
8:08 to legal reasons so we must be uh kind
8:10 of like restricting ourself to that of
8:13 those things which I must review before
8:16 going into action but not getting into a
8:18 legal sanction also our third segment is
8:20 talking about what is the key value of
8:22 having static testing being conducted as
8:24 a part of the process because it's very
8:26 important for one to know that how
8:28 important and beneficial it could be
8:30 when it comes to static testing however
8:33 static testing is not something new it
8:34 has been being conducted from a long
8:37 time but being brought into attention
8:39 recently for a few years that means
8:41 people were not giving value to static
8:43 testing at all thinking that it is a
8:45 waste of time come on who does read the
8:47 document we look forward to find the
8:49 bugs but today people are talking about
8:51 prevention of bugs which indeed was
8:54 there from a long time because istqb did
8:57 not write this for the first time it was
8:59 written 20 years ago but it's just that
9:01 the people who ignore a few things for
9:04 some time but later realize that oh it
9:06 was worthy enough to do and today we are
9:08 talking about shift left you're talking
9:10 about prevention my question is where
9:12 were you 20 years
9:15 ago anyway so I'm not here to have a
9:18 dispute and controversial talks but uh
9:20 let's have a word quickly to understand
9:21 what is the value of static testing
9:24 being conducted so static testing
9:26 certainly can detect defects in an
9:28 earliest phase of the sdlc fulfilling
9:30 the princi principle of early testing
9:32 that is testing saves cost and time that
9:35 is early testing saves cost and time it
9:37 can also identify defects which cannot
9:39 be detected by Dynamic testing for
9:41 example things like unreachable code
9:43 design patterns not implemented as
9:46 desired defects in non-executable work
9:48 product also static testing provides the
9:51 ability to evaluate the quality of and
9:53 to build confidence in the work product
9:56 by verifying the documented requirements
9:59 the stakeholders can also make sure that
10:01 these requirements describes their
10:03 actual needs see again the point being
10:05 made here is why would I go through a
10:07 requirement altogether number one to
10:10 find anomalies made by human mistakes
10:12 second if the requirements are unclear
10:15 incomplete inconsistent ambiguous vague
10:17 that means cannot be achieved I can go
10:19 and point this out and make sure that we
10:21 have a very clear set of requirement
10:23 with us because starting to implement
10:25 and then realizing that this is not
10:27 something we can achieve this is not
10:29 something we can test is actually not
10:31 correct because you'll be stuck or
10:32 probably you would have wasted a lot of
10:34 your time so in that context it is very
10:36 important that you should look forward
10:38 to review them in advance before you
10:41 start working on them also
10:44 Communications will uh be improved
10:46 between the involved stakeholders for
10:48 this reason it is recommended to involve
10:50 a wide variety of stakeholder in static
10:53 testing so indeed uh static testing
10:55 brings multiple stakeholders together in
10:57 order to review the provoked product
10:59 commonly and in that context context we
11:02 do have a better communication
11:04 established among the team member and
11:06 healthy relationship so static testing
11:08 do claim that by doing static testing in
11:10 your organization you can have healthier
11:13 relationship among the team member the
11:15 other point I think I missed since
11:16 static testing can be performed early in
11:19 the sdlc a shared understanding can be
11:21 created among the involved stakeholders
11:23 see uh sometime we do find that there
11:26 are a lot of defects which are just
11:28 created due to misunderstanding of the
11:29 same piece of information inform between
11:32 two different stakeholders for example
11:34 there's a requirement I understand it as
11:37 X and developers understand it as a why
11:39 so until unless we both sit together and
11:41 have a discussion on to we know we will
11:44 not have a very common understanding at
11:46 all so we will always be conflicting or
11:48 probably misunderstanding things that
11:50 what it should
11:53 be talking about other point that is
11:55 even though review can be costly to
11:57 implement the overall project costs are
11:59 usually much lower
12:02 than when no reviews are performed
12:04 because less time and effort needs to be
12:07 spent on fixing defects later in the
12:09 project so all you're trying to say that
12:12 we may think that unnecessary cost has
12:14 been involved by conducting reviews
12:17 before doing Dynamic testing but if you
12:19 find a defect in Dynamic testing which
12:21 is related to misunderstanding of
12:24 requirement you're actually putting that
12:28 time of you know uh usage into a waste
12:30 other around right so conducting static
12:32 testing in the beginning certainly can
12:35 save your overall cost of doing your
12:38 work more effectively efficiently and on
12:40 time by just having static testing in
12:42 place so it's not that it is actually
12:45 expensive it's just that we may feel it
12:46 but over a long period of time or if you
12:49 consider the whole project it is cheaper
12:52 enough also to add uh the code defects
12:54 can be detected using static analysis
12:56 more efficiently than in Dynamic testing
12:59 usually resulting in both fewer code
13:02 defects and a lower lower overall
13:04 development effort so certainly static
13:06 analysis has reduced a lot of our
13:10 productivity cost and the overall time
13:12 taken to do that so it certainly brings
13:14 a lot of value by having static testing
13:17 in place and in practice so put together
13:19 that's all from this particular tutorial
13:20 team should you have anything else feel
13:22 free to comment below I'm always there
13:24 to address your queries and answer them
13:25 well till then keep learning keep
13:27 exploring keep understanding the context
13:29 thanks for watching the video Beauty and happy
13:40 [Music] learning
