Hello friends and greetings for the day welcome back to another tutorial on istqb Foundation level certifications we are getting started with chapter 2 where we are talking about testing throughout the software development life cycle and today as a part of this discussion we are getting into the first segment which is the title itself that is testing in the context of software development life cycle and as a part of this tutorial we'll be getting into two different segments of it trying to understand number one that how does software development life cycle impacts testing and at the same time the second one that is software development life cycle and good testing practices so as this topic is slightly longer we are thinking of building it on bits and pieces so that it is easy for you to adopt them learn them and understand them so to get started the first one and most most important thing is Introduction to sdlc of course sdlc stands for software development life cycle indeed this is the entire life cycle which establishes and builds the product in a particular life cycle so we start with lot of major phases very common understanding which talks about the life cycle of a development of a product and certainly has major faces like requirement the design the development testing and the maintenance or release before that right so a very common understanding which talks about the overall journey of development process talks about the requirement Gathering where someone like business analyst or product owner in case of aile is responsible to gather all the information what a team needs in order to perform the required work of implementing a product but certainly these requirements has to be reviewed gathered and understood in terms of processing further so once the requirement Gathering phase is done or almost like going on probably in the case of agile that could be differently defined because it's a continuous process but when it comes to Waterfall of V model the phase completes and then moves to the next one also if we talk about the next phase that is designed so once the requirements have been gathered or we have some handful information with us we start building the design of the product which is more of like architecture the back end which will be you know the backbone of the system and then once the design is over we look forward to start implement menting where developers start writing the code which will be then tested by the testing team as per the independent testing concept that separate team called as testing genius other than developers will be responsible to test the system and once that testing is complete we release the product to the market and after that the product gets into a journey of Maintenance which is more of like update upgrade migration and retirement so most of these things we'll be covering in this entire chapter and uh the very first topic we are going to talk about is understanding how sdlc contributes in in influencing the test process if you quickly go back in the very first chapter when we talk about 1.4 the test process we indeed have discussed about the same thing that one of the factor influencing the test process is sdlc it totally depends on your software development life cycle that what will be your test process the effort and the period of testing in a development model for example if I'm talking about waterfall model here the waterfall model testing happens once for all after implementation but if I'm talking about aile methodology I do testing every single day because new or uh the existing one has to be tested continuously because every single day a developer is checking some code into the main branch and those main branches are certainly going to get side effects maybe not necessarily always but sometime they do get side effects and I just have to run regression tests to make sure the existing are still working fine in that context let's understand a little deeper that how exactly sdlc can contribute or influence the test process so when we talk about this we have testing which certainly gets influenced by the sdlc and has a major contribution in order to succeed so some of the choices of the sdlc impacts on the testing include scope and timing of the test activities like majorly involved based on the sdlc like how exact ly these activities of test will be organized and conducted in waterfall or traditional models it may happen later also that's fine but because things may not be ready by then and however we just close one phase then we move to the next phase that's the protocol of that is DC model but if I talk about agile all the activities begin parall that means the designer will start designing the architect developer will start building the algorithms or writing some flowcharts and testers will start preparing or understanding their test cases with respect to the requirement writing test conditions writing test cases so it's not that like people wait for something to get over but parallely you get started so that's one of the major aspect and other one here is that level of detail of the test documentation depending on waterfall you can say that the documentations are very detailed but when you talk about aile the documentation are very brief third Point choice of the test technique and test approaches certainly the time matters a lot if in case your test approach are supposed to be used whether it is applicable in a particular development model or not is very important to be discussed and similarly on the other side if I talk about the test techniques it may not be possible that you really have that good time or that requirement in detail fashion that you can make use of a technique at any point of time so in agile we do have these constraints pretty much that requirements are very high level and just because they are high level some of the black pox Tech techniques are little restricted and we make use of experience-based techniques like exploratory a lot and that's just because of this Factor also to add the point number four here extent of test automation again in traditional automation could be limited but when we talk about agile we look forward to have maximum automation because the time crunch the time is limited and certainly I need to do as much things as possible in the given timeline to us but last not the least role of and responsibility of a tester certainly if I compare again the traditional and agile I would say in traditional model testers are just limited to testing and they have no other responsibilities but when it comes to Agile they may have cross functional abilities at the same time responsibilities and role also certainly varies a tester may be required to participate in the release planning meeting or even in the iteration plan meetings but when it comes to traditional I it might be just limited to test lead or test manag manager so there are many such factors which do influence the test process based on the sdlc and that totally makes sense that why it should be taken into consideration when we talk about software development life cycle right here we also trying to quickly convey on a high level that yes the sequential development model has a different perspective alog together so we just discussed the same thing so quickly let me read out that so in the initial phases in sequential development models which is waterfall and V model uh typically testers participate in requirement reviews test analysis and test design the executable code is usually created in the later phases so typically Dynamic testing cannot be performed early in the life cycle that means until unless the code is developed a tester doesn't have anything to execute or perform so in waterfall or traditional models that is sequential models you will have to wait a long distance in order to start testing whereas on the other hand if I talk about AEL that would be very quick so that's what is in the next thing we have here in some iterative and incremental models uh it is assumed that each iteration delivers a working prototype or product increment and this implies that in each iteration both static and dynamic testing may be performed at all levels frequent deliveries of increments requires fast feedback and extensive regression testing so in this particular context we are referring to things like Spiral model and prototype model which were there earlier and these models used to only generate the prototypes and give it to the customer for a confirmation and as far as the customer confirms it we used to move to the next level right and that's where it was slightly different than that of the sequential models on the other hand if I talk about agile agile certainly has a complete look and feel so Agile development assumes that change may occur throughout the project therefore lightweight product documentations and extensive test automation to make regression testing easier are favored in the agile projects also most of the manual testing tends to be done using experience based test technique and do not require extensive prior test analysis and design so this could be very very dynamic as when it is available we just go through that start writing test cases and even execute right in the same sprint so in that context we see a pretty much good difference between the different sdlc model that how testing effort practices May VAR in the same line the next topic we talking about is what are those good practices of software testing which should be followed in any development model so it is not restricted to any particular development model many people do create this assumption that the factors what we are talking about are limited to V model or sequential models but if I have to talk about it in particular these are just general good characteristics of testing which should be followed in any development model and they're very very very straightforward and easy to understand the very first thing here we talking about is that good testing practices independent of chosen sdlc model should include the following and that is for every software development activity there is a corresponding testing activity so that all development activities are subjected to Quality Control now that's very simple that if I'm talking about Gathering requirements then testing team can parall join them right at the beginning and start reviewing One Way You Are condu ing your test analysis as one of the phases of testing but at the same time you are having a corresponding testing activity to that of the development activity now here many people start thinking that aren't we talking about the development of the code no this is a general word of development or general meaning development which means developing any sort of artifact be it about requirement the design the workflows the codes or whatsoever so when it comes to business requirement acceptance test team is required to co coordinate when it comes to system requirement system testing team is required to participate and same way when it comes to architectural design which is high level design the integration team is required to participate here and same way for detailed design that is lowlevel design and code we do unit testing so correspondingly the testing team aligns their activity to that of the development activities on the Left Right similarly if I talk about the next one that is different test levels have specific and different test objectives which allows for testing to be appropriately comprehensive while avoiding redundancy so it's very very important also to say that one of the good practice is to keep two different levels unique that means if I just walk into your floor and I and just ask you that hey is that what you are doing right now called as testing or something in particular then you can go ahead and tell me that hey NE this is called as integration testing uh this is called as system testing this is called as performance testing so every single level what you conduct must have an objective specific to that level and should not be just like I'm doing testing which doesn't make any sense you must be able to classify your activities under each level and each level must have a unique objective rather than being collaboratively written in a way that you are just making a statement that we doing testing and which doesn't make any sense so make sure that whatever you conduct is well classified into to a particular level and that level must have a unique objective and must not match with any other levels what you're doing so that's where unit integration system acceptance performance security portability interoperability all these levels have a unique objective and unique goal let's look at the third Point here quickly the third point is talking about test analysis and design for a given test level begins during the corresponding development phase of the sdlc so that testing can adhere to the principles of early testing testing I think this particular thing is just now explored you in the point number one that when you say there must be a corresponding testing activity the what is that activity I can get started with so first is of course the test analysis which you can begin parall with that of the respective development activity and uh the second one would be the preparation of the test cases so certainly you can start preparing your test cases at the same time and then look forward to uh execute them when the level comes into picture last but not the least the point number four it says that testers are involved in reviewing work products as soon as drafts of this documentation are available so that this early testing and defect detection can support the shift left strategy now we will be talking about what is shift left strategy in a moment like next tutorials but before that how exactly I can get involved the question is how early should I be involved in the life cycle the answer is as soon as the first draft of the document is available let that document be anything could be a requirement could be a design could be an algorithm but as the first draft is prepared a tester is requested to participate in order to start reviewing them and raise any concerns any doubts clarifications omissions contradictions related to that and that's what we refer to as static testing which certainly could be very very you know important and very effective at this point of time so put together these are some good characteristics good practices of testing which should be applied to any development model irrespective of what it is right 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 learning [Music]