Hello friends and greetings for the day welcome back to another tutorial on istqb Foundation level certification we are in Chapter 2 talking about testing throughout the sdlc and continuing ahead with 2.1 which is testing in context of software development life cycle as this is a big topic we have the second segment which we are covering today that is 2.1.3 testing as a driver for software development and 2.1.4 that is devops and testing indeed these two topics are those two topics which are newly added to our syllabus so let's look at them in more detail well the first thing coming into our discussion today is of course talking about some of the test approaches from the agile methodology as this is a new addition to the syllabus certainly we are discussing this as a part of foundation level for the first time however this topic is already included in the next level which is agile certification of istqb so if in case you are moving to the next level you will learn this topic once again so at this point of time we are just talking on a very high level as an introductory topic that what are tdd bdd and atdd in terms of applying testing approaches to that of the agile methodology in a very short and simple way we are talking about that these three techniques are basic basically a similar development approaches or B basically testing approaches the reason we have a Twist in this terminology whether it is a development approach or it is a testing approach is because the development is driven by the testing that means the test cases are written first or automation test scripts actually are written first and then the development will be done so it's right opposite to that of what happens in our general life cycles and in these approaches it is right opposite to that so let's exactly look what the content is trying to convey us here so so of course these are very similar to each other but here the similarity is that the tests are defined as means of directing the development process altoe each of these approaches implements the principle of early testing and follow a shift left approach however shift left approach is coming in our next discussion but shift left approach is more of like shifting something in the left hand side on the life cycle so as we all know testing happens later in the life cycle which is on the right hand side is moving before something which is used to happen before that so development is a before um an activity which happens prior to test executions but now the test cases are written before development can even kick off so how exactly this basically cats the need of the agile methodology and in this case of course the test cases are written or tests are defined before the code is written the support they support an iterative development model that means more of like aile methodologies only and these approaches are generally characterized as follows the very first one here is tdd on a very high level test driven development approach is going to help you with directs the coding through the test cases instead of extensive software design and then test are written first then the code is written to satisfy the test and then the test are test and code are refactored so these are very very high level information what they're trying to give you but does not make any kind of detailed explanation so let me just add few more lines on top of this which is beyond the syllabus that test driven development is an approach where the unit test cases are written prior to the unit codes that means simple programs when they are written we make use of test cases being written first so how does this principle even work in reality so if you deep dive into the process you understand that a code will be validated by set of test cases as far as the test passes the code is appropriate create or meeting the requirements if in case the code has anomaly the test cases will fail or test cases will identify the defect and the developer has to fix it in order to meet the requirements but when we realized that the tests are something which finally validate the code not anything else like design and other things then why don't we write those test cases prior to development and give those test to the developer that hey now you go in a repeated tight Loop of cycles of writing code in order to make this test pass that makes sense right so a tester will write test cases and give it to developer and then the developer will start writing code in order to make that test pass as in when they run the test if the test fails that means code has something wrong and I'm reducing a lot of time in reporting a defect reporting or following up or tracking the defect foreclosure talking about all those collaborations making other people understand now the developer himself or herself understands that where my code is wrong why my test is is not passing right and that reduces a lot of human effort in fact very proficient and faster when compared to our understanding of the life cycle so in that context we tried this out and here the tests were written before the development happens and these test are basically technically written that's the reason this is only applicable at the unit level yes you can say that a developer one will be writing the test cases here for units and developer two will be writing the code and once the test passes we groom the code we write more additional steps and make this code applicable to the rest of the body similarly the next one we have is called as atdd which stands for acceptance test driven development and here we do have uh options like derived test from acceptance criteria that's something unique as a part of the system design process and then tests are written before the part of the application is developed to satisfy the test the only difference here is the tests are not technically written that means they are not driven by the technical programs or the expectation rather the test cases are derived from the acceptance criteria so in aile it is very important that for a user story to be called as done or completed it should meet the defined acceptance criteria so as acceptance criteria is something which are satisfactory criterias of a user story then deriving test cases from them would make a lot of sense indeed these tests are also useful for uat that is more driven from a customer perspective Ive or business facing thus these test cases which are written are very helpful in uat as well that is user acceptance testing so the only hairline difference between this approach is the test cases derived from our acceptance criteria and in the same line if I go with the third one that is behavior driven development this expresses the desired behavior of an application with test cases written in a simple form of natural language which is easy to understand by any stakeholder usually using the format that is given when then and test cases are then automatically translated into executable test so again if you talk about the behavior driven development again the difference here is that the test cases are derived from the requirement the behavior of the system so one is technical facing second is business facing and third is requirement facing that is user perspective so here we do have a very a very common language called as Garin and that kin language stands for given when then where things are written in three steps given certain expectations or prerequisites when a user performs these steps then this is what you should expect to happen so if you just write this language we can translate this into a programmable executable test scripts and that will be further executed and then the development will happen on top of it so put together these are some very very specific and Niche approaches used in agile methodology but as today most of the organizations are very much driven by aile methodology it certainly adds a lot of value for anyone to understand at Foundation level that what are these introductory test approaches the next important topic we're talking about is devops and testing again this is one of the new topics being added to the syllabus for the first time and here we just trying to compare and understand that how devops and testing are going to work in today's scenario and here we are also introducing you to understanding of the devops keyword that many people at this point of time should know that what is devops altogether so devops is basically an organizational approach aiming to create Synergy by getting development which is including testing and operations to work together to achieve a set of common goals now if I talk about the devops as a word It's a combination of development and operations so development of course is the coding and implementation phase and operation is when it goes life or get into the environment that is targeted environment and it can run there so that is more of like uh production or maybe you know we talk about the uat where finally it goes into the target environment and we check whether it is working and operational or not so we are talking about eliminating the stage of testing but does that mean we are not talking about testing at all no devops is trying to say that hey devops means Dev part will include an embedded testing as a part of it and uh along with development parallel testing will take place and then it will directly go to the operational environments rather than having a dedicated phas for testing in between Dev and operations so they are skipping that particular phase combining it together with Dev and then trying to move directly to operations and that's another one of the trending thing so let's see what exactly the Deep dive of devops is and how this could be applied to the organization so devops when it comes to uh the understanding of the real time of course the when the team works together they will be able to do every time a new code is checked in every time a new piece of code has been merged with the existing part of the application or existing codes it would certainly allow us to trigger an automated test which would help us to check the build verification and the regression as well so automation test scripts can be written pretty well and that could even go in line with our automated confirmations of all the tests what you really need to do devops requires a culture shift within an organization to bridge the gaps between development which again includes testing and operational operations while treating their function with equal value right also devops promotes test autonomy fast feedback integrated tool chains and Technical practices like continuous integration and continuous delivery I think this is what I was trying to elaborate just a moment ago that when it comes to devops it's more about every time a developer is trying to write a code and check into the repository every single check-in should trigger a build verification test and many other activities like static analysis unit test cases or regression test Suite to be triggered automatically step by step to make sure that the new unit is working fine at the same time when integrated with existing piece of a code it should not break that that means even the regressions are not introduced so in that context continuous integration can be achieved and continuous delivery can be done so we also have the terminology as cicd very commonly known and called as continuous integration continuous deployment so we have dedicated tool support for these kind of activities but again we should spend some time to Deep dive into each of these that how exactly it can be achieved in reality another important thing here is this enables the team to build the test and release high quality code faster through devop delivery pipelines indeed why not if I follow the discussion what we just had for the last few minutes we understand that if such things can be automated or could be integrated as a part of a pipeline where the new code is checked in and all the other tests are triggered then a lot of effort and time being consumed traditionally can be reduced finally at the end we would like to talk also about some of the quick benefits and limitations of having devops in an organization I think keeping it very straightforward at this point of time we don't want to Deep dive and correlate to that of the real-time Industries or how these practices actually become advantages or drawbacks of having devops but on a high level we'll give you a quick outline that what does this even mean so talking about the first advantages of devops so from the testing perspective some of the benefits of devops are that is fast feedback on the code quality and whether changes adversely affect existing code I think that's very straightforward what we have been talking so far that you will get a quick response because as in when the code is checked in you'll have a quick response right there right you don't have to wait for deployments then run your test cases a deleter phase and so on you'll get a quick response and second important thing is that is the adverse side effect which is regressions also to talk about CI promotes a shift LIF approach in testing by encouraging developers to submit high quality code accompanied by component tests and static analysis so I told you some of the activities which we look forward to automate as a part of our CI pipeline includes the static analysis code sorry static analysis investigation and uh we do talk about unit test cases we do talk about the regression test suite and many other things which are actually a part of this pipeline additionally it promotes automated process like cicd that facilitates establishing stable test environments also increases the view on non-functional code quality characteristics which are certainly going to be evaluated then and there itself as we do understand we try to prioritize our performance and security and many other non-functional test to early stages like unit testing the reason is if I could identify the anomalies in the code which is written for a simple piece of program then I would be able to detect the memory leaks then and there and reduce my limitations of performance issues so in that context we also can very well uh have one of the advantages that some of the quality characteristics like performance and security can be even pre ped or shifted left to an early phase additionally uh if I talk about automation through a delivery pipeline reduces the need for repeative manual testing of course the more we talk about automation the less the manual repeative effort will be and the more we look at automations the faster the process will be so in that context we look forward to have more and more automations in place when it comes to devops or especially processes like agile all we have another Point here to talk about is the risk in regression is also minimized due to the scale and range of automated regression test so the more frequently the Direction test cases takes place the less the risk of failure will be that means the later the often we do or the less we do regression testing the chances of regressions being missed are very high but given that in devops we are very tightly working between the code and the test executions we certainly have a very good reduction in the risk of regressions so we'll identify them as soon as possible but nothing comes without a cost so of course there are certain challenges what we have to deal with when it comes to devops and some of them are listed here that is devops is not without its risk and challenges and that includes the devops delivery pipeline must be defined and established someone in your organization for the first time should introduce this people should be well knowledgeable on that if the team is not aware of what is devops and how do we make use of it how do we automate things how do we trigger it and connect different tools to one item that is C pipeline we will not be able to achieve that so someone has to introduce it someone has to establish it with the right set of knowledge so we need a devops guy for sure so there will be some dependency and maybe the expertise also matters there it's just not that someone with the basic knowledge of devops can really achieve that on the other hand we do have cicd tools must be introduced and maintained that means a new headache will be a part of your journey the tools and how exactly you will be maintaining that over a period of time and the last but not the least we have the test automation requires additional resources and may be difficult to establish and maintain them so you would need more resources like the test data the art artifacts the environment and lot many other things which contributes to the setup of the automation for this devops process so put together there were some interesting Concepts to discuss today and we had learned them pretty well from the syllabus point of view and a little Beyond as promised always so 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 [Music] learning [Music]