So to begin with, what we will do on day one is, we've already done with my introduction. So what we'll do is we will talk about kind of orientation about the entire course. So we'll like, you know, do that for about five to 10 minutes, we'll keep it short. And then we'll talk about exactly how each day's class is going to proceed. So going with, you know, the roadmap of the entire course, we have the, you know, kind of topic-wise training plan right here on my screen. But if you're looking for like detailed topic-by-topic listing of everything that we're going to talk about in the course, then the best place to check it would be on softwaretestinghelp.org. Right there we have a detailed syllabus with every minute aspect of it. But right here on my screen, what you're seeing is like, you know, a high-level topic-by-topic, you know, kind of pointers on what we are going to do and in what order. Now we don't always strictly follow this order, but we will try to do that as long as it feels organic and as long as it makes sense to what we are going to discuss. Another important thing is we will make sure that the class is on mute most of the time. The reason for that is we have a lot of students participating from all around the world who probably cannot make it to the live class always. So as you all know, we provide a recording of every day session as soon as the class is done. Again, about in about two hours after the class is done. So I'll tell you exactly about that as well. So there are a lot of people who follow the session through the recording and also, you know, recordings are great for us to go back and review the content of the class, which is a major plus of this program. So to make sure that we have a clean recording and we have a noise free class, we, you know, conduct the session usually in the muted format. But that doesn't mean that we are going to like, you know, follow the pattern of a monologue or anything. My intent is to actually have this program in the way of a workshop. So please feel free to participate and just because we are on mute, that doesn't mean we cannot hear each other, talk to each other. Please use the chat window as long as it is convenient. But if there's anything that you want to share with the class or me, just let me know through the chat again and I will unmute you and we can have like, you know, one by one conversation if needed, you know, so I really encourage you all to participate to the maximum extent.  So you can do that as well to get my attention. So you can use one of these ways to actually, you know, let me know that you have something to share with the class and I can make that happen. But otherwise we can use the chat window and all your messages are visible to everybody else. So that's a great thing as well. All right, so coming back to the training plan. So as you all know, this program is the duration of the entire program is five weeks. And we are very, very prompt with the time, I must say. So we will finish the class in the five weeks. I mean, as opposed to many other, you know, training programs where they say by five weeks, but it goes longer and longer and, you know, each day's class is not very content dense. So that's not how it is with us. We will finish the class in five weeks. We will make sure that the two hours that you spend per day, three times a week with us is worth your while and that, you know, every class is content dense. We will not waste any time. We will make sure that, you know, we are making the, because we are all busy and, you know, so we'll make sure that in the five weeks time, we will finish the course content and we will, you know, give everything the necessary importance that it deserves. So just give me a second. One of our participants has trouble with you listening. Okay. So in the five weeks, what we will do is, so there are like, you know, three or four categories into which I would like to break down these five weeks. So week one would be the developmental life cycles. So when I say development life cycles, what we are trying to do is now first things first QA is a part of IT projects, IT projects, meaning software projects. So when you are a part of, you know, an IT industry, it's not just enough that we understand what happens in a QA project. So what happens in a software testing project? So it's a good idea to understand what are the other teams within the IT projects? What are their roles and responsibilities? How do they interact with us? If they need something from us, what is it that they would probably be looking for? And what kind of inputs as testers do we require from the other teams? So these are some important logistics that we all have to understand in order to be successful in our day-to-day, you know, careers. So what we would do is, we would try and take a look at the entire perspective of how project development happens, what are the different ways in which project development happens, so on and so forth. So the first weeks topics are completely dedicated to the development life cycles. Having said that, wherever possible, we'll try and focus more and more on the software testing activities in each of these development life cycle methods. Now software development is one activity. There might be many ways that you can accomplish that. So the very common ways in which software development happens or, you know, the very common methods that are used. One is the waterfall model, which we will be talking about in today's class. The second one would be V-Model and the third is Agile model. Now these three are the ones that are most common, most prevalent and, you know, the ones that we probably need to have a good understanding to be able to perform, you know, successfully in our jobs. There are other models as well. So there's prototyping, there is spiral models and all, but all of those models to a certain extent are obsolete in the current day's market and are no longer used. So if you have an academic interest, please read up and if you have any questions, you're welcome to bring them to the class. And these are the three models that we will be discussing in the program. So we will start with the software development life cycle, which is the waterfall traditional model, V-Model, we'll discuss the Agile. And then we'll start the discussion slightly on the software testing life cycle, the different types of testing and things like that. Now, as I said, software development life cycle is a topic that has a wide span, wide range. It's more about, you know, everything in general, testing in particular. But starting week two and week three, what we would do is we would, like, you know, de-scope our focus to just software testing life cycle. So we are going to focus just on testing projects and all the testing activities. But here we are going to take a microscopic view of every small aspect, every small topic of software testing life cycle and try to discuss that with examples followed by assignments, so on and so forth. So for the period of next two weeks, we'll be spending on understanding the testing projects end to end. So again, all of these topics, as you can see. Now starting week four, we would move into a completely different category of learning and that is tools. Now what are these tools, right? So here's an example that I would like to give. I mean, very, very simple, probably lame. So when we are going for, say, grocery shopping or when you want to, like, run errands, what do we do for maximum productivity? We just probably take a note pad and note down the things that we want to do, isn't it? So what are we doing here? Is the note writing actually grocery shopping? Not. It's not that, isn't it? It has no way, it is no way in relation to the actual activity, which is the grocery shopping. But why are we writing the list? Because we are trying to manage the activity, which is the grocery shopping. So as much as it is important for us to do the actual work, it is also important for us to do it right, do it well, do it efficiently. So to do so, what are we doing here? We are managing our list. We are putting everything on paper, estimating, like, you know, how much time it will take us, probably think about which store is the best one.  So there are many types of activities in a software development project and software testing project. So to make things easier for us, there are also that many work management software or tools available for us. So there are three categories of work management that is very important for testers to understand. One is managing defects. So defects are pretty much, you know, where our day begins and ends as testers. So finding defects is one thing, managing defects is another. And managing defects is actually much more tedious and much more harder and much more important than, you know, I mean, of course, finding defects is important as well. But this is something that will also need a certain level of efficiency to bring into the process. So managing defects is called defect management and there are many defect management softwares that help us make this easy. So as testers, it is important for us to know, to have a working knowledge of at least one defect management software to be successful real time. And the defect management software that we are going to look at is Buxila. So Buxila is like, you know, the pioneers in the defect management category. It is one of the earliest tools to be there in the market. So it's, I don't know when it came into existence, but it's been there since I have been in the QF field and it's still very, very popularly used. So what we will do is we will take a look at Buxila. So when I say we'll take a look at what we will do is, so this will be like a guided tour, like a tutorial. I will take you through the process of setting it up to using it and, you know, how do you practice more on it? What are the areas that you should focus on? So I'll give you like an end to end tour of these tools. And the second thing that we will do in week four is we will look at test management software, which is QTest. This is a QS-infinite test management software. Also very, very, you know, I would say this is something that is recent, but at the same time something that's gaining momentum at a very, very hard, you know, fast pace. So definitely a great tool. And another tool that we will use is Jira. So Jira is also one of the premium choices for many, premium choice for many companies when it comes to project management and incident management. So we are going to look at three genres or, you know, three categories of tools, project management, test management, defect management. By the end of this, by the end of the day, all of these are work management softwares. Now you might be wondering why it is important to learn this. It's because, as I said earlier, it's not just important to do work, but it is important to do it effectively and efficiently. So work management softwares help you achieve that. So those are the three tools that we will take a look at in week four, and we will also go into automation testing. And the extent of automation testing as part of this program is to give you an idea of what it is, how it works, when should we use automation? If you are trying to learn automation, how do you go about it? So here's, let me put it this way. At the end of this program, you will have an orientation towards automation, but you would by no means learn automation. So this is not an attempt to teach you automation because that's a different discipline, something that takes like, you know, it's a kind of specialization and QA. So it takes separate time, effort, and, you know, also interest, aptitude. So we're not gonna trust automation on everybody here, but we will orient you. And to do so, we are going to use QTP, or UFT for that matter. And in week five, we will focus on career. Resumes, mock interview. So we will have one session on resumes. We'll talk about, where we'll talk about how to create an effective resume.  So we will not really talk about those details.  I'm sure already in your minds, there are a lot of questions. So if you are somebody who's making a shift from a different field, or if you are somebody who's new to IT, or if you are someone who's had a break in a career, all of these are nagging questions in our minds. How do I compensate for that? How do I make sure that, you know, my resume shows my skills in the best positive light? Those are the very few practical tips and tricks that we will talk about in the resume session. We'll also have one such session on interviews. Again, this will not be a list of interview questions that I'll give you and ask you to read. We respect you more than that, to be completely honest. So instead, what we will try to do in the interview garden session is, we'll try to talk about, you know, how you can put your best foot forward, you know, professionals, so all of those things we'll talk about. And then there are a lot of certification programs available for, you know, beginner-level software testers. So we will do a comparative analysis of all the choices available, and we'll also talk about things like, why certification is important? Do you want to go for it or not? Should you go for it or not? If you want to go for it, what are the choices? So on and so forth. So those are the things that we will defer for week five. And then also in week five, there's a little bit of a buffer, just in case if we don't finish any of the topics on time, this is where we can take it up. So this is the entire five weeks calendar charted down for you. In addition to this, we have daily assignments. My take on assignments is they are not mandatory. So let me explain that for a second. When I say there are assignments at the end of every program, so end of every day, every class, this is like a small activity. Now, it's nothing major, it's nothing like, you know, that's going to be tedious or anything like that. It's a simple activity that we have at the end of every program, every day, so that you can practice the concept that we learn in that day's class. So there are a lot of people who just joined this class to understand concepts. So by no means, assignment is mandatory. But if you really want to work through everything, you're welcome to do the assignments. In addition to that, there's a lot of bonus material. I'm coming to that. So the bonus material will be sent in two parts. So part one, I'll send it to you at the end of today's session. Part two, you'll get it on the last day. Okay, so you will receive an email with all the instructions on how to download the material. So that you should get it in about two to four hours after the class is done. Every day session is recorded. And we also keep running notes of what we discuss in the class. Both of this content will be sent to you in an email from me in about two to four hours after the class is done. So I'll explain why we need two to four hours. Now, while the recording is happening, it records in a go-to meeting format. After that, it has to remove the codec and make it ready so it can play in any device. So all that technical processing and then uploading it into a place where you can all view it, this takes a little bit of time. So but within two to four hours, you should have an email from me with the link and instructions on how you can access the recorded session and the notes to the class. We also have a live application. So this is like an in-house project that we have that you all can use for practicing your testing concepts. So that's another bonus. Yeah, so I think that's about all the details that I had to give about the program. Any questions so far, team? Anything that you would like to know? Just a second, team. One of our team members is having a problem. So I just wanna make sure we help her. Oh, all right. So I just hope her issues get resolved and she's able to come back to the class. So regarding interview preparation, is it going to be one-on-one session? See, here's the deal. See, one-on-one sessions, we have done them in the past, but only when the other person has had an interview or when they're ready. So again, when we get to the week five, we can discuss more on this because, but then the software testing helps philosophy on interview preparation is not that, it's not like a question-and-answer session. It's not going to be an interrogation. Interview is more about having a professional conversation. So if you have an interview in hand, if you wanna prepare for it and if you want one-on-one session, you can get in touch with us and we will probably arrange for a session for you, Vijay can actually do that. We can do that. But otherwise, it's a different philosophy altogether and we can discuss that in week five again. When can I talk about other course other than which is suited with my skills before the fifth week? Fifth week would be the best time and where to download the material. We talked about that already. I will send you an email with the instructions. Okay, so let's get started with what we are going to do today, team. So QC is not covered. We have HPQ, we have Q test instead, okay? So the, what I was going to say is today's class. So we have, every day's class is two hours. So this is Monday, Wednesday and Friday in United States. Sorry, where did that come from? One day Tuesday and Wednesday. Sorry about that. So in this two hours, what we will do is we will, our class is broken down into three parts. One is the vocabulary. So we will try and talk about a few, you know, IT, QA terms that are commonly used. So it's like a jargon sort of a thing. And then what we will do is we will discuss one main topic. Followed by that, we will discuss. So we will leave that with a practical concept or assignment to be much more precise. So this is the format of every day session. You're free to ask the question. So I don't like to actually, you know, bundle up all the questions and ask them at the end. So as in when you have a question, feel free to post it. But again, you know, try to keep it relevant to the topic that we're discussing. For example, when I'm talking about like software testing lifecycle or software development lifecycle, try not to ask a question that has to do with QTP or VB testing. So as long as we are in the context, you're welcome to post the questions as and when you have them. And I'll take them, you know, when we take a logical, you know, break point in the discussion. So let's get started. And you know, we can take further questions in a little bit. So today we are going to start with the basic vocabulary, which is software, project, domain, technology, platform and testing. I'm sure most of you know this already, but please humor me. This is just to make sure that we start at the absolute zero. So what is software? So let's make this interactive. What do you think is software team? Use the chat window to respond to me. What is the software? Anything that comes to your mind. All right, I'll start this one. We'll build as we go.  Thank you, Gayathri. And it is created to achieve a certain functionality. So a code that does a task, right? Is that correct? Now when we think about why this task needs to be done, this task needs to be done because this is a solution to a particular problem. Am I correct in saying so? Now let's look at this scenario. Let's assume there is a company that has offices in like three or four time zones, time zone one, two and three. And all of these people need to have a conference where they can transmit content like visually they should be connected and they also should be connected in terms that they can hear each other and talk to each other. So they need audio and video conferencing combined together. Probably they also want to record this. Now they have a problem that they cannot conduct this kind of a conference. Now a software that comes as a solution for this is something like go to training or go to meeting that we are using right now to convene in a meeting together, isn't it? So every software is basically code. At its core it's just code but it's very important to remember that this code is not just any random programming language based statements. It's basically a code that is targeted at something. It is targeted to solve a certain problem. And this is very important. The reason why I'm emphasizing on that it is very important for testers to understand what that problem is and how does this software solve it. Because otherwise we can always test a software say that it does not have a bug but we will never be able to say whether it is fit to use. Being fit to use is an important characteristic of a software and when that does not satisfy that we have essentially run into a defect. So a software is nothing but a piece of code that is designed in order to provide a solution for a particular problem. So let's move on to the next one. What is a project? Now this is simple enough. So what is a project team? Anybody would care to join in? I know this kind of communicating without the voice takes a little getting used to, I agree. All right, so project is nothing but any piece of work that needs to be completed.  Similarly in software, in IT a project might be like building a software, a project might be testing it, a project might be like maintaining the software. So projects could be of various types and they just mean that they are just tasks to be accomplished and within IT it is important to remember that every project needs some input, generates an output, so it requires an input and the inputs for IT projects are usually time, money, effort, infrastructure. So time, money, effort and infrastructure. And the output for the IT project is some sort of either creating or, you know, improving a particular software. And yeah, so those are the two important logistics that we need to understand. And the activity of managing the input so that we have consistent outputs, that means, you know, making sure that when you provide the correct amount of inputs and you know, provide the inputs in the right order, provide your, do your tasks in the right order that you end up at the consistent output, every single time, the process of doing so is called project management, okay? So the next thing is domain. Now, I have been asked about the domain so very many times. Every time, whether it is an interview or when I'm like, you know, trying to, you know, find a different position within the same organization, the question that comes to me is do you have domain knowledge expertise or what kind of domains have you worked on? So, and domain is one of the terms that intimidates even the best of us. Let's try and define what this is. Domain simply means it's a key business area. So what I mean, but what is meant by this is, now let's look at sites like Wal-Mart.com or eBay, eBay is slightly different, but again, Amazon or any other sites, for example, that does, you know, that sells products, commodities through an online medium are businesses that belong to e-commerce. And then there are businesses like, I don't know, BankOfAmerica.com and there is Chase.com. So all these banks belong to the domain banking or online banking to be more precise. So basically, all the applications that belong to a particular business area are called applications of a certain domain, belonging to a certain domain. And there are many domains actually. So there's e-commerce, banking, finance, basically everything. So there's retail, all kinds of domains. Now, why is the domain knowledge important? Let's actually spend a minute on that as well. Domain knowledge is important because let's say you have been using like Yahoo Mail or MSN or any other email clients. Now, if you were to be using any of these email clients and if you have to, for some reason, transition to Gmail, would that be difficult?  Do you think that's the case? Would this transition be difficult? Not at all, isn't it? This would be very easy, why? Because you have previous work experience or previous familiarity. You are already familiar with how online email clients work. So it's just a matter of, you know, using the exact same familiarity that you already have onto a different medium is all there is to this. So similarly, domain knowledge, people, you know, employers look for domain knowledge because if I have already worked on say amazon.com, that means I know how retail sites work, e-commerce sites work. So it's very easy for me to actually test, say, a site like ebay.com because I already know how, you know, those sites are supposed to work like. So domain knowledge will help ease the process. But on the other hand, when you look at it, what happens if you don't have the domain knowledge? What happens if you have not worked on amazon.com before, if you have not tested that before? Does that mean it's going to work negatively for you? I don't think so because I don't know whether that's a good thing or a bad thing, but I have never worked in two projects that belong to the same domain. But I never had a problem transitioning from one domain to the other. The reason why, you know, that is the case is because as testers, we don't really, you know, so here's how I look at it.  Now let's assume I'm trying to test if a user is able to buy a product from amazon.com. So basically when I'm a user, what I'm trying to do is I'm actually going to buy. I'm actually performing the task. Why?  But on the other hand, when I'm trying to buy something from amazon as a tester, here I'm not looking for buying. I'm actually trying to validate. Will it work? Will it not work? How is this working? So basically whether I am trying to validate, whether I am buying, trying to buy, the steps to buy a product from amazon is the same. So what I'm trying to get at is that the activity that users perform and testers perform is exactly same on most systems. The intent is the only thing that is different. At the end of buying, the tester will look for, you know, anomalies. Are there any problems? But as a user, you'd simply buy your product and you'd be done with that.  So that is the difference. I mean, actually, as users, as testers, we are users to IT as well, which makes it, so which means that we are never unfamiliar with some system. But even though if we are, this is how softwares work. You provide an input to a system. So this might be a mobile application, a web application or a Windows standalone application. It might be any application you're providing an input. Let's assume this is a calculator. The input that you provide is two and four and you want an addition on it. So these are the three inputs that you provide. So you are providing X, Y and the operator. What kind of action you want performed. By the end of it, you would have a result, isn't it? You would have success to your result. So as long as the input that you provide and the output that you get is consistent, that's enough for us. As long as you understand what the system behavior should be like, that's enough for us. It does not matter in between what kind of system or what kind of processing happens. So here's my take on domain knowledge. If you have, if you do possess the domain knowledge, that's great. I mean, any skill is good to have. But on the other hand, not being familiar with a particular domain is not necessarily a negative factor for a tester to be successful in that domain. But on the other hand, if you're trying to build your career into becoming a business analyst in a particular domain, then it's good to invest that time on learning a domain better. So don't worry about, the reason why I focus so much on this is we've had a few requests from our past students saying that, I mean, the application that we give you as part of a live project is an e-commerce application. So we've had many requests saying that can we get a banking project? Or do you conduct like separate session on how to test a banking project? All of these requests, but honestly speaking, there's no difference in the way you test. An application is an application. As long as you understand it thoroughly, there is no difference in the way you would treat that application depending on the domain. But if you wanna become a business analyst and grow in that area in the analysis side, then that is a completely different category of learning interest than what we are going to do here. So coming back to the basic definition of what domain is, it's basically a key business area. Next comes technology. A lot of times I see resumes where they, the project description is put after that, the domain, technology, programming languages. So all of these details are given. So one of the questions I commonly ask when I look at resumes like that is what do you mean by technology? So how did the technology play a part in how you tested it? Technology simply means that what are the technical, the technical specifications on what went into building your product? So product in our case will be the software. So the technical specification of what went into building this software. Now examples could be, let's say this is xyz.com. This is a site. Now if this were built using Java code, you know, programming languages Java, if this was using web services, SOAP UI services, SOAP services or REST services or if this was using XML for its data transmission and if this was using say MySQL or DB2, some sort of a server at the back end, all of these details become the technology that is used to build the software. Now back to how is this relevant to test this? Does it matter how the software is built or you know what was used in building the software when we are trying to test it? 90% of the time, no. It does not matter how the software is built because at the end of the day, whatever testing we do as functional testers, I know we haven't discussed what functional testing means yet. I will talk about that going forward but the kind of testing that we are going to discuss here in this program that has nothing to do with how the product is built. All we are interested in is what kind of input can it take? What are its capabilities? Is it being able to satisfy its capabilities or not? And that's where ends our job. We are not going to, none of these specifications make a difference in how we test or what we test or any of those other testing related logistics. But on the other hand, is it good to know what the product that you have been working on is based upon? Definitely yes. Next is platform. Platform is again slightly related to technology but this is about where will the product run? So this is about where will the product be used? Running is nothing but executed. So here's the deal. So you might be actually building a car in a garage but that's not where it runs, isn't it? It needs to go on the actual road. It needs to actually be in its real-time conditions, real-time running conditions. The same, that's exactly what platform means. Platform usually means what is the operating system that it's running on. So there are many applications that run on Windows platform. There are many that run on Unix, Mac, so on and so forth. So platform simply means that the specifications of the target system where your product is intended to run. Last definition team. And I really want your participation here. So what is testing? What do you think is testing team? Preventing and detecting the errors. Fair enough, thank you. Validating the functions of a software. Testing is the process of identifying errors, great. Any other definitions? Thank you, great definitions. Now testing is actually, I mean, the book definition. Finding errors in a piece of code, product development, is it meeting the specifications? Testing is the product of identity, okay. Removal of defects and making a product effective. So here's what I have a list of things based on your answers. Testing is to prevent, find, and remove errors. Can I conclude this is correct? I mean, can I conclude, I mean, this is based on all of your inputs. This is the definition I have. I mean, this is the three activities. Finding if the code does the work fits its purpose. Thank you, that's a good one. Now testing is an activity that we perform to make sure that the product works as intended. Oh, that's a bad spelling of intended, pardon me. Okay, so testing is an activity where you're actually going to check if a product works as intended. Now, let's say I bought a new toaster. I don't know why toaster, but toaster. Let's assume I bought a toaster. Now, what would I do with the toaster? Let's say I bought it for the intention of testing a toaster. How would I go about it? Do you think I will look for errors? I will look for whether it can toaster or not. One or two teams. Which one would I do? When I buy a toaster just for testing, will I go look for errors? Will I go or will I just toast and see whether it works or not? The second one, isn't it? So testing is never really about finding bugs. Testing is about validating whether it is doing what it's supposed to do and it does not do. When the product falls short, we have found ourselves a bug. So that's what it is. Testing is never about bugs. So when testing is not even about finding bugs, it is never about preventing or removing bugs. Removing is definitely out of scope for testers because we are not developers. So when you say software is code and software has bugs and when you have a bug, how do you fix it? You have to go manipulate the code so that the bug is eliminated, isn't it? So since we don't possess the technical expertise, nor does it fall under the boundaries of our job description, defect removal is generally not our job. Preventing to a certain extent, I would say that's true, but then that is not the exact testing activity that is QA. QA is called quality assurance. This is something we'll discuss going forward. Usually testing teams are called QA teams because we not only find errors, but we also prevent bugs. But testing as an activity is simply to make sure that the product works as intended, which means we don't go looking for bugs. We go and check whether the product is working as it's supposed to work and when it's not, we would have found an error effectively. So defect prevention to a certain yes, but not like as far as the testing activity, the core testing activity goes no. It's also not about finding bugs. It's also not about removing the bugs. Removing the bugs is definitely out of scope for testers job. Our job ends as soon as we find the defect and we pass it on to the respective teams, which is in most cases, the development team, okay? So yes, that actually brings us to an end of a long vocabulary section. Now let's move on to the main part of the program, which is software development lifecycle. Now, what is software development lifecycle? One thing that I find very useful when I'm trying to learn new concepts is try to look at the name. I mean, why do you think this particular process has a particular name, right? So software development, we understand that. We're talking about developing a particular software, lifecycle. So in the course of this program, we'll discuss the software testing lifecycle, defect lifecycle, risk lifecycle, release lifecycle, bug lifecycle. So there are like many life cycles that we will keep on discussing in this program. And even after when you are trying to learn something else, life cycle simply means the stages. Life cycle means that something is transitioning. So again, bad spelling. So something is transitioning. So software development starts from a zero, isn't it? So when you start with it, you're absolutely starting at point zero and you're building on to achieving what you would call a software that works, like workable software. All the necessary, all the intermediary stages and how does transition happen between one stage to another is what encompasses the software development life cycle. So software development lifecycle is nothing but the step-by-step process of how software is built. So this is like a butterfly lifecycle, which actually, that's what it reminds me. Because that has nothing to do with software, but that's the name you have. It just means that the different stages, the different phases, one transitioning from the other, but then it's a continuous process. So one of the software development lifecycle processes that we will discuss in class is called waterfall model. The waterfall model personally is my favorite. It's the classic and this is being used to build software systems since forever and it's still prevalent in the market. Waterfall model is also called a linear model. And we'll see why. We'll also see why it's called waterfall model. There is a reason why it's named so. So waterfall model or the linear model is like the classic, but one thing that we need to understand before we even go into the waterfall model is software development is part of a business. It's actually, you know, it's part of the IT business. And there are three important people who are affected by the business. For one, the client.  And so far I have a physical business which is a brick and mortar, like, you know, physical showroom where I engage in buying and selling cars. But I want to do this online because online businesses have great benefits, isn't it? They are available 24 by seven. There's no infrastructure costs. I mean, little infrastructure costs and you know, they're much more convenient and the whole world is shifting towards it. So definitely going online might be good for my business. So when I decide to do that, can I do it myself? Probably not, isn't it? Because I'm a car dealer and I don't have the technical expertise to make it happen. So in that case, what would I do? I would get in touch with somebody called the software service provider, somebody who can build this product for me. So this is the second, you know, category of people who are affected in the software development process. Lastly, just so this person will build something called cars.com, something to that effect. Now, once I have cars.com, will it be either used by the client or the, you know, software service provider? Not necessarily, isn't it? This is actually for people who are trying to engage, I mean, customers of the client. So basically we have end users. Or real time customers who are going to use the product. So we have three important parties in the process of, when we talk about the software, in the context of software. So we have a client who is the business owner, also called the business owner. So we have a software service provider or these people are also called the builders who will build the software.  So there are three stakeholders. Now, end users is something that we cannot really, you know. So this is the consumers. This is where, this is the side of the business people, basically. So within the business, this is how it goes. So when the client recognizes that there is a need or there is a requirement that needs to be built into a software, they're not going to just, you know, go to the first software service provider and get it done, right?  We don't just go hand it over to the first person we see on the road, isn't it? We are going to do some shopping around. Same thing happens with the client and the service provider as well. So what the clients do is, team, are you able to hear me okay? Because nothing has changed from my end. Okay. Sometimes if you are facing a problem with the audio, make sure that, you know, there are no other applications open and all that. Beyond that, I don't know what, I don't know. Let me know if the problem still persists. We will see what we can do about that. All right, moving on. So the client has a need or a requirement and the approach, so they will actually, make a list of what is that they want. So it might be a time frame. They might want this in the next three months, right? And probably a few, like list of requirements. So you would want like a site where you can do business and you will define what is it that you wanna do. So maybe the client wants to start with simple like, you know, selling cars. So they just want to create an inventory list online and they want to provide a facility where, you know, the person who is viewing the car can make an appointment at the dealership or if they can buy it, something like that.  What can it do? What should be the limitations? All of this. Also, they might have a budget in mind. They might also have like, you know, a few other requirements like, you know, something should be easy to maintain because they don't wanna build a site that will need like, you know, constant babysitting from a technical team. So they might have their own set of requirements. So these requirements that usually get passed on from the client to the service provider are called business requirements because here the client's focus is his business, not necessarily the website because that website right now does not exist. At this stage, it does not exist. All they want to do is they wanna expand their business. So all the requirements that they have in terms of expanding their business into the virtual world are called the business requirements. We'll talk more about this. So what the clients will do is they will set this, you know, particular set of requirements and they would publish these requirements to multiple software service providers. So each service provider, what they will do is, so all of this is pre-software development lifecycle team. So these are the steps that happen before the waterfall model begins. And don't worry if this is not making a lot of sense because we are never involved in this process. This is something we are just learning for our information, that's all.  Now, feasibility analysis is something that we will, again, it's a term that we will hear over and over. And what it simply means is the simple question, can we do it or not? So clients may or may not be computer savvy. So sometimes they might come up with requirements that are simply not possible to be implemented through softwares. This is actually a real request. One time we were building a product for hospital management systems and we've had a discussion and one lady came to us and said, this site should have a user ID and password but it should not be the same as the one the user will use for the insurance company. That's something we can never impose on the user. We can't say that, hey, you've used the same password for insurance, you will not be able to use it for here. Because for one, we can never know what the insurance password was in the first place. So even though software can be pretty effective, there are some things that software cannot do. So feasibility analysis is nothing but picking up all the business requirements and deciding can we build it or no. Then make technology decisions like what database is to use and all that, infrastructure decisions, like where do we do it? Do we do it like in-house, on-site? Do we do it like in a two-team framework, one-team framework? So all of that stuff, followed by people. What kind of people are we looking for? What kind of skills do we need? Do we have them already? Do we need to hire them? So all of those staffing decisions are made. So once each software service provider makes these decisions, they would prepare something called a proposal document. A proposal document has all of these things. A proposed solution, schedule, technology, budget, ETA is nothing but, when will we deliver? ETA stands for expected time of arrival. So it's something that is used in the context of firefighters. So it's like, ETA for the firefighters to come is 10 minutes or something. So it's like, when can we expect work to be done in simple terms? Then what kind of maintenance do they need? Service level agreements, legal contracts. So all of these details is presented to the client. Now clients will get multiple proposals from multiple software service providers and the clients will decide which one is a good option, which one is probably better quality for less money. So all of these decisions are made and the client will decide on which service provider they are going to go with. So all of these activities that we are talking about here, the client approaching the software service provider, they are preparing a proposal document, coming back to the client. All of these things are pre-SDLC and these are not even done by the testing team. These are done by what there are teams called pre-sales teams, which go bring business to IT companies. So they talk to clients, understand their needs, prepare proposals and all of that. So why we are talking about this is, here's why. Once this proposal is accepted by a client, that's when the software development lifecycle begins. So I just wanted it to be a continuous thread rather than we start abruptly at the place where software development lifecycle starts. That is the reason why we are discussing this. So once the proposal is accepted, the traditional, so in the traditional waterfall model project, this is how the project would begin. You would start with the initiate. So there are six stages, initiate, define, design, code, test and deploy. Again, we will talk about this a lot and a lot and a lot going forward. So let's get started and discuss what the different steps mean. What are the activities carried out, so on and so forth. And this is a great introductory topic to start our course, because as I said, it's not just important to be good at what you do. It's also important to understand what the other people involved in the software development project are. What are their roles and responsibilities? What kind of inputs can you expect from them? What kind of inputs would they expect from you? So it's important to understand this process because IT projects are always, always based on a team framework. So this is a great topic that will introduce us to all that and much more. So before we go to the software development lifecycle, do you have any questions, team? So there was one question about is this the running notes? No, this is not the running notes. This is just a way for you to, this is like the whiteboard or something. So but then as we've discussed much more formal concepts, we will note down things in this Excel sheet and that will be the running notes you'll get. Any questions so far, team? Is everything making sense? So software development lifecycle, the waterfall or linear model. So it has six stages. Initiate, define, design. So we'll go ahead and keep writing as we go. And whenever we are discussing any formal method, we will talk about, it's very important to understand three things that we will start with and we will keep adding more and more to that. And the first one is what is the input that is when do we start this process? And the second thing that we need to understand is output, that is when do we stop? Finally, we also need to understand who are the actors or who does this work, right? Yeah, so let's start with this. We'll also probably talk about what this process is and how this is done, maybe. So yeah, let's start with this. Now, initiate is the very first stage of the project, software development lifecycle project. So what was I saying? Yeah, initiate is the very first stage of the software development lifecycle. So it's like the inception of a particular project. So this is where the basic teams get formed. So initially you have somebody called a project manager. This person is like responsible for the delivery of the entire product and they will have to take care of all the teams, that is development team, QA team. So they are like the one point contact for making sure that the entire project runs on track. So the second actor who gets involved at this stage is the business analyst. So business analyst is somebody who is a domain knowledge expert and business analysts are also called SMEs, subject matter experts. So essentially these people are very good at understanding two things. They understand business and they understand software as well. So ideally if we are looking at the same cars project, business analyst for this project would be someone who knows the car dealership business and at the same time he has good understanding about the virtual systems that implement or that actually make the car dealership process happen. So these are people who have a fair amount of understanding of business models, software systems and et cetera. So to make sure that the business has an equivalent virtual entity. So this is what I mean. So when you go to a grocery shopping, say for example, these are the sequence of things that we would do. We would browse for what we need. We would choose them, that is we add to cart and then we probably like at the end of it where if we wanna remove something, so you can update your cart that is with whatever you want and then what do we do? We check out and during checkout we could pay in cash. We could pay with cards, checks, so on and so forth. All of these multiple things that you can do in the store. So when you look at the same equivalent Walmart.com, the same things you can actually do online virtually. So this kind of smooth transition from a store model to an online model is something that is taken care of by the business analysts. They create what is called the business models that are later implemented by development teams to build what is the Walmart.com or some such site. So it is very important for the business analysts to understand the core business at the same time, understand how he can translate the same thing into a virtual medium. So business analysts are very, very important and in this stage the third actor who get in, who are, who play a prominent role is the clients themselves. So what happens in this stage? So what happens in the stages? BAs, project managers and clients, they have regular meetings, they talk to one another, they discuss and finalize what should be the scope of the project. So what is it that the client wants and you know, what is it that they're looking for, what are the time frames they're looking for all of these details. Now you might be wondering, aren't all of these details discussed already in the pre-SDLC stage? Well, they might be. But here's the deal, in the pre-SDLC stage, the only teams that get involved are the pre-sale stage. So the people who are actually going to build the software are not involved at that point. So they don't really know what the requirements of the client have been. So it is again a task to sit down, get the scope one more time, make sure that it is in line with the pre-sales and also perform another feasibility analysis because these are the people who will be actually implementing this on the floor. So the scope is defined, business requirements are collected and project plan is drawn. So basic project plan on kind of when do we start, when do we stop, what are the milestones, all of those are figured out. So this is mostly in the form of meetings, brainstorming, exchange of ideas basically. The input to start this stage is the proposal document. Proposal is finalized. Now, never will QA teams get, I mean normally it's not normal that QA teams write the proposals or have access to the proposals. Proposals are usually very confidential documents. Regularly not, I mean commonly not made available to the team members because they have details like billing rates and all that, which is confidential and is usually a secure document. But then the very fact that the proposal is finalized and the project starts, this is called the project kickoff process. Once the project officially starts, kickoff is nothing but the official beginning. The initiate process begins. And once the, so once all of, and then the client, the project manager and the business analyst, they all sit down and figure out what is the scope, what are the business requirement and then we create a basic project plan. Now at the end of this stage, we will have something called a business requirement document. So all the discussions, all the, back and forth deliberation of the scope will decide to finalizing what are the requirements from the perspective of the business of the client. So these things are recorded in a document, called the business requirement document or the BRD. In addition to the BRD, you would also have something called a project plan document. This is prepared by the project manager. BRD document is prepared by the business analyst. So the output of this particular stage is both the BRD and the project plan document. Now going forward, the next stage is the defined stage. Usually in the waterfall model, the input for a particular stage is the output for the previous stage. So in the defined stage, what happens is business requirements are translated or transformed into functional requirements. So let me explain this a little bit. Now business requirements, so there are two entities when we are looking at any IT project. One is the business and the second is the software that enables the business. So while we are in the stage of business requirement gathering, that is when we are in the stage of BRD creation, we are focusing only on the car dealership business. What does it need? It needs an online medium, so it needs an online website. And this site has to be accessible both on mobile and web applications. And what should it be able to do? It should be able to create an inventory and sell cars. For now, they should be able to sell cars. Now, by the time we move to the defined stage, the focus is no longer the business. The focus is the software. Now, when we say software, how should the software accomplish this? So as soon as you log in, maybe there should be a homepage. I mean, as soon as you try to access the car site, there has to be a homepage where there has to be like search or a browse option. Which one is it? I mean, deciding on how this, the software and, you know, how the software accomplishes the task of selling a car, what are the options it should have? How should it be designed? All of these details go into functional design stages. That is the defined stage. So from the browse, you can select it. Once you select it, you can actually check it out. You have options to pay by credit card there itself or you can pay in the physical location. So all of these, you know, the menu options, the page by page description of how it should do it or, you know, what it should do. All the details and, you know, limits of the software I decided in the defined stage. So how can a particular software accomplish a business requirement? So the business requirements are translated into functional requirements in the defined stage. The input for this is clearly we need a business requirement document. Who is involved here? So usually this stage is pretty much carried out by the business analyst and the development team because they will have to develop the software, isn't it? So the development team and the business analyst, they make a combined decision on how they can transform the business requirements and incorporate them into the system as system or functional requirements. So how does this happen? This also is usually mostly meetings and this is also working hand in hand creating a lot of diagrams. So there are lots of, you know, things like use cases, use case creation. So there's a lot of work involved, not just like, you know, talking one-on-one. The output of the defined stage is usually another document which is called the Functional Requirement Document or the FRD. This is also called the Functional Specifications Document or this is also called the SRS, System Requirement Specifications. So whatever name it's called, it's all the same. Different teams use different naming conventions. Any questions so far, team? Everything making sense? Perfect. All right, so once the defined stage is done, we move on to what is called the design stage. So design stage is technical, technical implementation of how we are going to do it.  So the menu option should have these details. The menu option should have maybe other options as well. So one thing is design is a stage where all the technical details are charted out. That is how should the front end look? So the page-wise physical design of placement of different components, how should it look like? Those things are decided. Then the implementation. Like for example, if you are supposed to use like a Java class to make, you know, a particular Java class to accomplish the calendar function or something like that, all of those implementation related details are also present here. So if you're using an XML, what should be the, you know, how should this be structured? What should be the structure or how should be the layout of this XML? And if you're using a database, what kind of table structures are you going to use? How are you going to define your tables? What should be the columns be? Where should the data go? So all of these technical details, like, you know, how can you, like so far in the business requirements, you're planning on how to accomplish the business. In the system requirement, you're doing the same thing, but here you're focusing exactly only on the software. So you're planning on how the software should be. And in the design stage, the activity that gets conducted is how should you accomplish the system requirements that you have come up with? So it could include designing the first front end, that is, you know, the look and feel placement of objects. It could be like designing the XML structure, database, so on and so forth. So all the details related to implementation are carried out. So the input for the design stage is the functional requirement document. And the output for the design stage is a technical design document. And this stage is mostly done by development team and the other technical teams. So these technical teams could be data architects. They can be HTML designers. They could be any other, you know, some people who are going to take care of installations, et cetera. So any other technical teams that can help us with the process become integral part of the design stage. Now what's important to note is, even though we are not mentioning that, you know, in the defined stage, the project manager is there, the project manager is always going to play the role of a coordinator and make sure that things are moving along smoothly. Similarly, when we come to the design stage, the project manager also has an involvement, but again, passive, slightly. And also the business analyst will also overlook the entire process because the business analyst has to make sure that at every stage that the project, you know, evolves, so as the project is evolving and in every stage it is the job of a business analyst to make sure that the product at every place is in line with the business targets that it is supposed to achieve. Otherwise it's going to be completely useless, isn't it? You could build something that looks great, but at the end of the day, if it does not satisfy the business needs, you have essentially failed at building a project, building an IT product. So that is why business analysts are constantly involved, making sure that every activity that we do is lined up, is targeted at achieving the business goals. So what is this here? Technical implementation are listed and defined. Yeah, so this could be design, this could be database, this could be program and its structure, programming language related details, all of that. This is also both meetings and work, lot of documentation creation. Now after design, we have the code. Code is straightforward for us to understand. To write effective code, you would need all the documents, functional requirement document, technical document, business requirement document, so any sort of reference. So what happens here is actually, code is created like you know, the means programming for the creation of the software takes place in this stage. So this is where actual implementation begins. So far it's all about planning and deciding and deciding about what to do, how to do in each stage. It's all about making decisions, but in the coding stages where actually work gets done. Software starts taking shape. The physical component of building the product starts taking shape. So this is predominantly taken care of by the development team. And of course, technical teams, business analysts are all, and then project management team, they are all involved passively, making sure that everything's going fine. At the end of the coding stage, you would have a code that is ready to test. And this is actually, you know, how in the sense code is created using different technologies and all that. The fifth stage of software development lifecycle is test. So to test again, you would need the code of course, that is to be tested. And then output of this, we will talk about that. And here in the test stage, it is the QA or the software testing team that gets involved. And of course, business analysts are here, project managers are here, development team is here to fix bugs that we find. But all of them have like, you know, a secondary role to play. The primary role is that of the quality team or the testing team to make sure that the product is, you know, fit for use basically. The product is tested. And also, once all the coding is done, the product starts to look like how it would look to the end users. Here's what I mean. Let's say I had like, you know, a search component that I have to include. I have to include a browse component. This is my page. I have included all of these components. There are different, like, you know, probably there is, if there is a deal that shows up here. So at the end of the day, when all the coding is done, this is something that looks like the product. So this will be something, this will be similar to the customer facing product, isn't it? Once all the coding is done. Now, once it comes to the QA or the test stage for testing, you are going to actually look at a product that starts to resemble the final system, isn't it? So that is why the testing that we are trying to do here is called the system testing. So this is pretty much system testing stage. Okay, we'll talk more about what system testing means. And at the end of system testing, what you would have is code that is ready to go live, that is ready to go to its, you know, users.  There might be bugs. The bugs will eventually get fixed. So by the end of it, but what I'm trying to say here is even though it involves like, you know, multiple stages of revalidating, re, you know, making, there might be some fixes that need to go into place. By the end of the day, once test stage is 100% complete, we can say that the product is ready to go live, right? And what happens here? System is tested. And also another stage of testing is conducted here. We'll talk about that in a little bit. So basically, once testing is done, there is the code that is ready to go live. So finally, we have something called the deploy. Now, deploy is just a fancy term to say install. Now, what deploy does is, the input for this is clearly the output of the previous stage, that is code, tested code. So once we have the tested code, the team that is involved here who takes care of deployment is called the deployment team. Deployment is nothing but installing the application in a way that it is accessible to its end users, like, you know, the car customers. So this is also called the deployment team. This team that takes care of installations is also called the support team. Again, it all means the same. Different companies have different names as all. Or this could also be the operations team, environment team. So any of those names are applicable. So these teams are going to, like, you know, install the code in the real-life environment. And the output is that the product is live and is available to its customers or audience or whoever. So that basically finishes the software development lifecycle. Now, at the end of the deploy stage, once the product goes live, it depends on what kind of agreement the client and the service provider has. So if they have any maintenance agreement, like, you know, if they say that, you know, we are going to be on standby, if any issues come up, we will fix it for about one year. After that, you will have to be on your own. So some sort of agreements like that are usually in place. But the development part, that is actually called the maintenance part of the project. But as far as development is concerned, once the deploy stage is reached, the project is 100% complete. So as you can see, this is a waterfall or a linear model because the output of one stage is the input for the next. That means you cannot start, initiate, and define simultaneously. You will have to wait for initiate to be completely done. So you can move to define, and you'll have to wait for define to be completely done, to be 100% done for you to move to design. So because of the nature, because of this exact nature, it is a linear model. And because, you know, of how the input and output fall from one stage to another, it's also called a waterfall model. Any questions on the basic model team? This is like, you know, as I said, something that I feel like is very organic to how software gets built real time. So any questions on this model? Is everybody able to follow through? Is everything making sense? No questions? Okay. Yes, I'm going to send this notes. Perfect. So, all right. So let me ask you a question. So let's actually consider a situation. Let's assume the project started in January. So let's assume all January, the initiate stage was going on. All February, the define stage was going on. Again, hypothetically, this is not possible, but let's assume every stage takes an, you know, equal amount of time, and this is how it went on. Then came March design, April code, and May is test, right? So tests, we all understand, we are testers. So here we are. Now let's say, as a tester, you've come in May and you're trying to test, let's say we have like the next four weeks to test this product. What do you think is the first thing that we do? Do you think we will just have this? So here we know that by the time the software moves into the test stage, you would have the system just the way it would be. You know, it is pretty much the customer-facing product that you have here. So that means, let's say this is like a calculator application. So do you directly start adding two plus two, and you know, two minus two, or so on and so forth? Do you think this is what we do? So do we directly start working with the product? Do you think so, team? Now let's actually take one step back and see what the definition of testing is. Testing is actually to make sure the product works as intended. Now for a calculator, we know that when you say two plus two, it is supposed to add. But what if it's a complicated insurance claim? Will you know how the system is supposed to work? So the intended behavior, is it that easy to know that we can come in the end like, you know, right before the product is ready to go live, do you think we can come in the end just test? That is commonly not effective. So testing, even though the mention of the testing activity happens, only in stage five of the software development life cycle, testing teams are involved way ahead. Now if you look at the ISO standard rules, they actually, ISO is a kind of process certification where they will lay out few guidelines on how to do our work for maximum efficiency. So if you look at the ISO standards, they recommend that the testing team should be involved in the initiate phase itself for maximum benefits. So strictly speaking, this is the waterfall model. Now if we were to, since we are testers, we want to know how testing happens, how does, I mean, where are we involved? What is it that we do? Let's actually take a look at what is it that we do while the initiate stage is happening? What could be our involvement? Who are the team members within a QA team and what are our roles and responsibilities while the main activities are going on in the software development life cycle? So let's look at the QA team and the QA responsibilities. What is it that we do in this stage? Now ideally what ISO recommends is that we join this initiate meetings along with the client and we kind of work along with them and figure out how much time it will take to test in the initial stage itself. That's what the ISO recommends, but normally in the most practical sense, in the initiate stage QA team does not get involved. And even if we do get involved, it's normally counterproductive because there's a lot of finalizing happening between the client and the business analyst. So nothing is final. So there's no concrete ground for us to base our testing estimations on. So for this reason, initiate stage, there is usually no involvement for the QA team. So again, I know ISO standard means well, but practically I also do not see any use for the QA team to get involved here. But if they were to be involved in the initiate phase, what we would do is we would work along with the business analyst and the client stay there and understand the nature of the business and the targets that the business is trying to reach through this new endeavor. So that's what we will try to learn if we were to be a part of initiate phase, but normally we aren't. So we usually get started in the defined stage. And usually QA team is not a constant size always. And this is something we'll discuss more and more going forward. So QA team starts small because the actual work is only in stage five. Here what we are doing is merely preparing. We are only preparing for testing effectively in order to understand what is the intended system behavior. So what we would do is here is in the defined stage, usually it is only the QA lead who gets involved and think about what inputs do we have to work with. The QA lead at this point will have the output that was in the previous stage because the current stages input or output, the current stages output is currently being worked on. So the QA lead also will have the exact same input as the development team does. So QA lead at this point will have a BRD to work on and also the project plan, right? So based on that, what the QA lead will do is understand the testing scope, right? You know, what are the things that we want to test and try to basically understand what is the business target of the system. That's all we will get to kind of figure out. And based on the project plan, we can create a test plan document. Again, this will not be a final version, just a draft. Now why wouldn't it be a final version is a question that we might ask. And that's something, again, we will talk about it more and more as we go forward. But the reason why we cannot make a complete test plan is so far, again, when we are testing, we are going to test, going back to the two entities. We have two entities, which is the software and the business. And where do we conduct our testing? Is it on one or two team? Where do we conduct our testing? Is it on the software or on the business? Always on the software, isn't it? For us, we are going to conduct testing only on the software, not on the business. Because how can we even touch the business at any point? So because we have to test the software, we need to understand the scope of the software. I mean, it's a good thing to know, like keep things in perspective on what the final target of the system is. But when you're looking at day-to-day work level, what you have to really work on is the software. So here's an example. Now, when you are a tester on walmart.com, you would be testing the walmart.com application and not necessarily on whether or not walmart.com's business policies are correct. So it's never about the business. It's always about the software as long as testing is concerned. So to basically plan a concrete, to come up with a concrete strategy on how you're going to test, what is it that you're going to test, you need to know everything about the software. And how would you know everything about the software once you look at the FID or the SRS document? Unless you have this, you cannot plan effectively. But on the other hand, based on the project plan, you can come up with an initial draft because again, they might decide that testing will come up actually in May and they might have planned to have like three to four resources based on their budget. So you do know these logistics of how many people, what is the timeframe, you know, tentative timeframe, tentative milestones. So based on that, we can plan a basic version of the test plan, but not entirely. You can plan it entirely only after the functional requirement document can be reviewed, which is not yet available in the defined stage, right? So the basic draft is prepared and scope of testing to the extent possible is defined as well. Next, going to the defined stage. Here, the QA team gets involved. So when I say QA team, it involves the lead. So I'm not going to write QA team and the QA lead. So one or two testers get involved at this point. And here, remember, we have the functional requirement document. So we can actually write a test plan document and we can also create the test documentation. So in other words, what we are going to do is we are going to prepare for testing. So test preparation. So the first thing that we have to do in order to prepare for testing is to understand requirements. So how do we understand requirements by reviewing the FRD document, talking to the business analyst? So there will be like multiple induction meetings at this point where we are trying to go back and forth on understanding the functionality of the system. So once we have that, so once we know what the requirements are and how they function, we will figure out what to test in each of these requirements and how to test them. And if we need, do we need any special data? Do we need any special conditions that need to come true for us to be able to do that? So all that documentation we create while the application is being built. Finally, when the application is being built, we go ahead and test it. And here, remember, we do something called functional testing. Functional testing is again at the level of understanding the system's functions. We'll talk about that in a little bit. Probably tomorrow, the difference between functional and non-functional testing. But here what we would do is we would perform the testing of the entire system as the QA team. And as I said here, this is system testing. There is another level of testing that goes on. Now, if you were to follow the SDLC, Waterfall models strictly, what happens after testing? It goes to deploy. That means the QA team, which is actually a software service provider, you know, somebody who belongs to the software service provider side. Once they say that, you know, this is yes, and you know that, I mean, when we say it's fit to use, we are basically saying yes, the product can go live. The product goes live. Now, does this mean that the client is not involved in this decision? Because at the end of the day, we are trying to satisfy the client. The client is the ultimate decider of whether or not they want to use the product for their business, right? So let's say somebody wanted you to build a banner that they want to hang in front of their business. And you build something that you think is right, but at the end of the day, whether the other person wants to hang it in front of their shop or not, depends on whether they think it'll be beneficial for the business or not, isn't it? So at the end of the day, the client is the one who takes the delivery. So it is not the QA team's decision. It is not the testing team's decision. It's not the project manager's or the software service provider's decision, whether or not it goes to deployment. The client has to make that call. So there is another stage of testing between the system testing and the product going live, and that's called UIT. So UIT stands for user acceptance testing, or simply acceptance testing. So user acceptance testing is done by the client to make sure that the product is fit to use. Now at the end of the day, the client is not going to test as thoroughly as the QA team, but they're going to check few highlights of the software and determine if they're satisfied with it or not. So this is like, let's say you gave your car out for servicing, but you're not just going to bring it back without test driving, isn't it? You'll have to, you just want to make sure that whatever you want it fixed, is it fixed or not? Is it fixed to your satisfaction or not? So it's not just enough if the person who is fixing it thinks it's fixed. It's also important that you be satisfied with whatever action that's been taken on your car. So same thing is true with software as well. So just because the QA team thinks or the project management thinks that the product is ready, it does not mean it can go live. The clients also put the system to test. So once this testing stage is, so there are two stages of testing here, system testing and then the UIT testing. Now this is usually carried out by the client or clients representatives. At the end of it, you would have a acceptance ready software. Now here if they decide to, if they are satisfied with the product, it goes live. If they're not satisfied with the product, they're again going to have to revisit it, make some changes and make sure it is as per their instructions. So there's system testing, UIT testing and here the QA team also gets involved in the UIT testing in terms that we support the testing process. Like we are on standby just in case the client needs any help, we provide that help. So QA team gets involved way ahead of time rather than just come in the test stage and strictly just test. What we do here is we get involved ahead of time so that we have enough time to understand, prepare and plan for the testing activity and make sure that we test in a much more cognitive and educative manner than haphazardly coming and pushing some buttons at the end. So that is the QA team's involvement. Any questions team? Okay, so now that we've talked about system and UIT testing already, there are like four stages of testing or four types of testing that happen to a particular software product. Again, we will discuss more and more on this tomorrow. So these are unit integration system UIT. So these are the four testing levels that happen to every software product. Unit and integration testing are done during the coding stage and these are done by the developers. System testing is done by the QA team or the software testing team and this is done during the test stage of the SDLC. UIT is taken care of by the client and this is done also during the test stage of the SDLC. Let's briefly define what each one is so that tomorrow we'll actually talk more and more on this. Now while the development team is coding the product, it will not be, I mean, first of all, IIT teams, I mean, any work in an IIT project happens on a team member basis. So what I'm trying to say is one person might not build the whole product. Even if they do, they might not do it in one go, right? So software gets built piece by piece, you know, part by part or unit by unit. So basically a unit of code is nothing but a piece of code, that piece of code that works as an autonomous body. So here's what I mean. Let's say there is a calculator. So this calculator should do both, should do like addition, subtraction, multiplication, so on and so forth. So there are like many, many mathematical operations that this calculator is supposed to do. But as I said, all of this might not be done on one particular day, right? So let's say on a particular day, the developer has created code that will perform addition. So let me write some pseudocode. Again, this is really not any programming language, just some pseudocode. So x is equal to value one, y is equal to value two, result is equal to x plus y, and at the end of it, it has to print the result and show whatever is x plus y. So assuming this is the code to perform addition, this is not the complete code, we understand. So this is a part of the code. But can this work by itself? If I just give like x and y values, it will give you an answer, isn't it? So pseudocode means this is not really, this is not a programming language, this will not work, just to give us an idea of how it works. So it's like, you know, just sample code. So something that appears like a code, but it's not code. I hope that makes sense. So this is basically a unit of code. It can accomplish a particular task, but this task is not a complete task. It's something that is a part of the whole thing. So unit testing can be done as soon as a particular unit of code is built. And unit of code is a few programming language lines that can work as an autonomous unit. So here, as long as I supply x and y, it will supply me with result. So once this basic unit is ready, developers will test this particular piece of code. And once this is done, they'll put it aside and they will test code in terms of units. So unit one might be addition, unit two might be subtraction. So basically you have all of these units that are written separately and tested individually to make sure that they work. Now, important thing to note here is, how does the developer test the addition code? So there are four lines of code, isn't it? Do you think the developer will print it on a paper, print the code on a paper, read it line by line and decide that it works? Yes or no team, do you think that's what they do? Do you think the developer will read through the code and decide that it works? No, right, because it might not work. But then how do they work with it? Do they get hands-on? Do they supply different values of x and y? Probably a positive xy, a positive y. So let's say positive value for x, positive value for y, negative value for x, positive for y, maybe they'll supply values that have decimals. So do you think they will provide all of these different input sets and check the corresponding output and then make sure it's working? Do you think that's what they do? Why do you think no? I would definitely think yes, because they would want to make sure that it works in most, I mean, most common conditions, isn't it? Now, what we are trying to, what I'm trying to tell you is here is, they are not going to look at something static as a paper that will not change. They are not going to read through it. They are going to interact with the system dynamically. So any form of testing that involves the tester to interact with the system dynamically is called validation, and this is called verification. Now, basically, I might just read through the code and figure out that a line of the code is missing, right? So that's also a way to test, but it's not most effective. So anytime you're trying to test a particular software by reading through it is verification, and when you're actually putting it to test by interacting with it dynamically, that's called validation. That's something we'll discuss later again, but let's assume this is what happens. I give an X and Y value, and the output is incorrect. So basically my test failed, or in other words, the developer has encountered a defect. So what do you think the developer will do at this point, team? Do they report the defect, or do they fix it? What do you think they do? They fix it, right? They are the ones who've created it, and they also have the technical expertise to fix it, so they would actually fix the code. So when I say fix the code, do they have to manipulate the code? They have to, isn't it? So they have to really, so they cannot actually forget about what's in the middle. They can't just give an input and get an output, right? They have to actually look through the logic or look through the individual lines of code to effectively perform unit test. So any kind of testing that involves the tester, in this case, the tester is the developer, any kind of testing that involves the tester, the person testing, to take a look at the code, to follow through each and every line of the code while they are testing is called white box testing. Here we consider code to be a box, right? While the developer, who is the tester here, when they are testing a particular unit, they have to look through the code, isn't it? So this code cannot be a black box. So any kind of unit testing is a white box testing technique because it involves them looking at the code. And don't worry if this does not make sense at this point, we will discuss this tomorrow one more time. So here's what we know about unit testing so far. We know that developers perform it. We know that this is a dynamic form of testing or that it's a validation technique. We also know that this is a white box testing technique, which means the developer has to look into the code and not just treat it as one unit where he does not have to look into the programming logic. And we also know that the developers themselves fix the code. Now with that, let's move on to integration testing. Integration testing is when you have these pieces of code, unit one, two, three, four, so on and so forth, putting them together, like maybe you just want to, I mean, if you put everything together at one point, probably if something is not working as a result as a whole, you probably will not be able to figure out which module is faulty, right? So usually integration testing happens with integrating one module to the other and then gradually going on to making sure that it's the whole product. Now when the integration testing is happening, so when I say integration testing, it doesn't mean that I'm going to put unit one and unit two next to each other and it's a done deal. No, right? So when I say integrate, I'll have to write code so that these two modules work together. So integration testing again is validation because I'm not going to put them next to one another and imagine or just assume that they work. I'll have to put to test both of these features and see if they work or not. Let's assume this is the functionality. First I will view a car and then I will go into the buy screen, right? So this is actually to browse the car and this is actually to make the payment and buy the car. So let's assume these are the two modules. Now how are these two modules integrated because they interact with one another? So I can't just assume that when I view a car it'll automatically, I can automatically buy it. I'll have to perform the validation on that. I'll have to actually dynamically do those operations and see whether or not it's happening. So it is also validation technique and it also involves a little bit of programming because integrating of modules means you will have to write code so that they can work together. And once a bug is found in the integration testing that is also fixed by the developer which means the developer can't just assume that this code is a black box, just provide an input, get an output and think that it's working. They will have to look through the code, make changes if necessary, and be really aware of what the box is. The box, it has to be white for the developer to be able to look through it and understand it appropriately. So for that reason, integration testing is also a white box testing. So let's look at one other thing about integration testing. Let's say there are four units of code, okay? Unit one, two, three and four and all of them are put together. So you have put one and two first together and then one, two and three and then one, two and four. So finally you have the whole product together. So at this point when I provide an input and when I receive an output, I'm actually testing to make sure that the entire system works. So this is similar to system testing, isn't it? So once the product is completely put together, this is similar to system testing. So since integration testing is a little bit of both white box testing and black box testing, like system testing, like for example, in a calculator, when I'm performing the addition operation as a tester during system testing, do I care like how the code is written? I don't, for me, this box of code is a black box. I do not worry about what programming logic is being used, what statement is being invoked as a result of the operation I'm performing. None of these matter to me. So any kind of testing technique where you do not have to deal with the programming, where you do not have to see the code, that's black box testing. Since integration testing includes both white box and black box, it is sometimes called gray box testing. Again, we'll discuss all of this tomorrow, just giving you a basic introduction to this.  We only look at, you know, we provide an input to the application, whether or not it is working as intended is all we check. But when it comes to unit and integration testing, the developers will make sure that, you know, the code is taken into consideration that it is kept an eye on at all times during unit and integration testing. So that is why unit and integration testing are called white box testing techniques. Integration testing has a little bit of both black and white, so that's why it's called gray box testing technique. So there you have it. There's one last topic of environment that I wanna talk about. But before that, I just wanna make sure that, you know, we have no questions on this because if we do, I would rather take them than, you know, handle a new topic. So is everything okay, team? Any questions? So there was a question earlier about if we are going to discuss test-driven development also. First of all, test-driven development is a topic that is, how do I put it? It's a hypothesis that is still in the process of being, you know, refuted or accepted because test-driven development basically focuses on testing as the primary activity, then builds on, then goes on, you know, how we can build a product that focuses more on testing. So this is actually a new experimental thing and it's not, you know, prevalent in the, I mean, it's not completely accepted by all clients and all people. So that's not something that we'll discuss. But if you are interested, you know, do your research, if you have any questions, feel free to send me an email and we can discuss that offline. And if you feel like you wanna share that with your class, let me know, we can do that as well. But as part of the class, we are not gonna discuss that because this program is really aimed at getting your job ready in as quick, in as little a time as possible and as thoroughly as possible. So this is mostly about, this is very oriented to, you know, real-time job situation than, you know, experimental future things. So that's the way it stands. But as I said, you're welcome to do your research and, you know, questions or if you wanna share that with the class, you're most welcome. Okay, so far what we know in the software development lifecycle topic is we understand the different teams. So we understand what project manager does, BA does, development team does, what QA team does. We also know what other technical teams are, deployment teams, so on and so forth. So we have a good understanding of people. We also understand processes. What are the documentation that you could expect? Business requirement, functional requirement, technical requirement, different types of testing. Like, for example, I mean, we know that the QA team's involvement. What kind of activities does the QA team do in the software development lifecycle and what stages? We know that as well. We also talked about what is white box testing and black box, gray box testing. So we talked about that briefly. Of course, I admit we haven't discussed it in greater detail. So we also know what unit testing is, integration, system, and UIT testing. So you see why this is my favorite topic to begin with. So it's like this one topic, but in an hour's time, there is just a lot of ground we can cover, a lot of things that we can try and learn, and that too, keeping everything in context and not really running around from places. So yeah, with that said, this one last topic that I wanna talk about, that is, where? Now, where does software development happen? So when I say where, this is what I mean. Let's say, now, let's take a look at a product as popular as Facebook, right? And we have something called a facebook.com where we all can use this, right? Now, Facebook is a product that compulsively changes like every few days, isn't it? There's something or the other that's happening new. So that means there is development happening. And finally, users are using it. I mean, many of us are using Facebook while the development, let's say, is making changes on it. Do you think this is what happens in real time? Do you think the development is changing Facebook while the users are actually using it? And when the development is changing, the QA naturally follows, isn't it? The testing naturally follows. Do you think the developers, developers, testers, and the users, that is the customers, are actually accessing the same instance of Facebook? Do you think that's what's happening to you? Yes or no? Do you think on facebook.com, on that one particular site, all of this is happening simultaneously? No, why do you think it's no? Because, let's assume today, I'm trying to create something on my timeline. Again, I'm not very familiar with this, so let's assume something's happening with my timeline. I'm trying to post something. And let's assume facebook.com removes this feature as part of its development and replaces it with something else. Do you think as an end user, I'll be happy? Somebody interferes into my work and somebody actually overtakes it and takes off what I'm doing? No user is gonna like it. So all of these activities are going to happen in different physical locations. So it'll be the same Facebook application, but spatially, space-wise, each of these different people who are acting on the product, they share a different space. Thank you, it does have a QA environment. So basically every company has three instances, three spaces where each of these people can do their work in peace. So there are three environments in software systems usually. There's a development environment. So environment is nothing but, let's say there is a Java 3.5 or something that needs to be installed. There is a web browser that needs to be available. There is a DB server that needs to be connected. So all of these specifications are replicated in more than one place, but each one is dedicated for one particular type of people. So right now, Facebook version 13 is in production. That's what is being used by users. But development team might be working on a version 14. Development team might be working on a, yeah, development team, let's assume they might be working on a version 14, which is a newer version with more features or some sort of enhancements or improvements over the product as it stands today. So they would be developing that. Once they're done, they would move that code to QA, so the QA can test it. And once the QA test, this can go into production. So while the users are now using 14, the rest of the teams can use 15. So this is to make sure that each one has their own different space so that one does not interfere in the other. Now you might ask, what happens if one interferes with the other? Now, if we interfere with the production environment, it could cause a loss of satisfaction with the end users. If developers interfere in the QA environment, QA testers might not have a very consistent environment to assess their results in. So for all of these reasons, environments are separated. So the coding happens in the development environment. So let's also add where. So the testing happens in the QA environment. Development happens in the development environment. And finally, the product goes into production environment. Now, when it comes to UIT though, it could happen either in the QA or the production environment because at the end of the day, this is the choice of the client. They probably want to test it before it goes live or immediately after it goes live. So it's their choice completely. So if the UIT happens in the QA environment, it's called alpha testing. If it happens in the production environment, it's called beta testing. So it's the same process, same thing that happens except that the environment is different between alpha and beta. But we'll discuss more and more on that tomorrow, not to worry. So this is another thing that is worth discussing while we are discussing the software development lifecycle. So that's all I have planned for today. Now I'll open up the floor for questions. If you have any questions, feel free to let me know. I'll send out this Excel sheet in the email today along with the training plan. And this is SDLC. I will also add what today's assignment is. Again, team, there is no, I'm not gonna impose the assignment on you. But if you wanna just follow through the class and work in parallel to what we do every day here, you're welcome to do the assignment. And I'll give you the details about where you can send them to me and how. Yeah, and also we have some students who do all the assignments over the weekend and send them all in a bunch. That's okay too. So feel free to find a way that works for you. So today's assignment is again, for the first week, I don't like to get technical. So we're not gonna do anything like test cases, test plan. So none of those things. We will keep it simple, we'll keep it straightforward. We will also keep it as something that makes sense, that's something that's natural and easy to adapt. So along those lines, what I would like you to do today is since this is our first day as testers, we wanna get some perspective on this. So what I want you all to do is take any site or any application. So it might be a web application, mobile application, or a standalone application. So any application or site, so let's say I'm gonna pick up the Excel sheet itself. Microsoft Excel is my application. So you are free to pick anything that you want. And in this, try to list out 10 features. It's very important as testers to be able to figure out what are the features and what is the intended behavior. So take any site, take any favorite application of yours. I'm taking Microsoft Excel. I'm gonna write a few features. So try and write at least 10 features. So I'm simply, I mean, in any format or in any way you like. So I'm gonna say that the text in a particular cell can be formatted as per font, font color, and type. I can attach, an attachment can be added to a cell by using the insert object feature. Or the spreadsheet can be saved from the home menu. So so on. So try to write at least 10 of them. If you can write more, you're welcome. So once you have that, send your work to me at SDHCourses at the rate gmail.com. If you are sending it to me on a day-to-day basis, try to send it to me at least an hour before the class begins tomorrow. That way I'll have enough time to take a look at your assignment and provide you the feedback. If I'm late on providing the feedback by a day or two, just please bear with me. I'll try and do the best that I can. So that's all we have for the day. I will send you the material, bonus material part one. Yeah, along with today's course content and the video. So any questions, team? If there are no questions, I hope you've enjoyed today's class. Let me know if you have any comments, questions, feedback, feel free to send me an email at this SDHCourses at the rate gmail.com. We monitor that pretty regularly. So if there's nothing else we can sign off for today and tomorrow we will meet with another, sorry about that. So tomorrow we'll meet with another development lifecycle, which is V-Model. V-Model is not necessarily a very different model. It's basically a slight variation on the waterfall model and we'll see that tomorrow. Yeah, so one last question. Should we use the Excel sheet? If you want to use that, you're welcome. If you want to write it in the email itself, that's okay. If you want to use a notepad, that's fine. So any method works basically. And any other course that you would suggest with this one? Again, that's a personal choice really. It's too soon to tell is all I'm thinking or you can just actually send me an email with the details and I'll try to get back to you. Okay, thanks everyone. Have a good one. I'll see you tomorrow. Bye-bye team.