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 defects when it comes to [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
