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]