 Hi, everyone. Welcome to the manual testing and automation basic session by the software testing help team. I'm Swati. I'm going to be the facilitator for these sessions. I'm a computer science engineering graduate and I've been a QA for about 10 years now since 2004. I'm CST and CSQA certified and I've been a facilitator for these sessions for about a few months now, close to a year now, and we've had over 200 participants who have taken this session already. Today in this demonstration session, what we're going to do is I'm going to give you an orientation of the syllabus, the format of these sessions, what all is included and we'll also take up a test topic to give you an idea of how every day session goes on. Right? So let's get started with the syllabus. So we'll start with the roadmap of the entire course. Now, you all must have seen on the website that this is a five week class and we have three days a week each day. Each day session is two hours. Okay. Now, right now, this goes on Mondays, Tuesdays and Wednesdays, 7 p.m. to 9 p.m. specific time. So the curriculum of this session, since we have most of the times our students are from non-IT backgrounds and some of them, even though they are from IT background, they are beginners to QA and some of our participants have already been QS for a while, but they want to have a class which enforces their basics. So we have a good mix of all sorts of students in our class. So what we do is we try to start from the very beginning. Now, we try to start from topics that will ease our way into the advanced topics very well. So we start with the software development methodologies. Now, before I explain this, let me tell you who this class is applicable for. Now, this is a QA class. So anybody who wants to or needs to learn QA, this class is perfect for you. So if you are a pressure right out of college and if you're looking for an entry into IT and if you're interested in QA and want to make an educated guess as to whether this is something that you're interested in or not, so this class works for you. And if you've already been a QA, as I said, if you want to reinforce your fundamentals, this class is for you. So basically anybody who wants to learn QA, this class is aimed at them and there are no prerequisites as such. We do not expect you to be an expert in anything before you get in here. So it's not like we're looking for IT professions or anything. So what we are doing here is we have a QA course and we also try to give a glimpse of real-time work that happens in projects so that if you are new to this field, new to this IT field also, it will be a good exposure for all of you. So coming back to the topics, the first week we have the development methodologies. So here we will talk about the different ways in which software is built. So why does software get built? What is a software in the first place? What are the steps that go into it and where does testing come into picture? We'll talk about all that in the first week's topics. So as you can see here, we have the V-model, waterfall, agile model, all of these models. So the focus here is both the traditional and the more, how do I put it, the more recent developments in the software development aspect. So we have you covered as long as, as far as everything, all the methodologies are concerned. So even though we are going to talk generally about everything that happens in the development process for the project, the focus still is on here. So even though we try to learn all the stages, we are much more keenly concerned begging on how software testers play a role, what kind of factor it is to do. So the focus is still on testing while we are trying to learn, while we are trying to get the entire IT perspective. Starting with the, again, we're going to go much deeper into the testing process. So we have the software testing lifecycle, the main topic that's going to begin in week two, and that's what we're going to talk about in the next two weeks. So all the, everything that is a part of the testing lifecycle, all the inputs that go into it, and all the developers that we create, everything is going to be explained. And the focus of this class is strong fundamentals at the same time, practical application of the knowledge. So everything, both the theory and the practice is going to go hand in hand. And at the end of the first three weeks, we will have everything in our hand that we need to know about the QFU within a practice. Now week four is again something that will be highly beneficial to you in terms of adding skills to your resume. In week four, we're going to take up incident management tool, which is Jira, a defect management tool, a test management tool, a Q test. So not only do we provide you a 100% overview of these tools, a walkthrough, we also give you a test ID so you can, you know, practice working on the tool and gain some skills on it. And in week two comes the automation path as well. Now, this class is 100% a manual testing class, but we want to introduce you to the automation topic as well. The reason is, see, especially when I started my career, when somebody told me that a tool will perform testing for me, it somehow sounded to be, you know, something that is too good to be true. So for those of you who have never seen automation, you know, really happen or, you know, if you've never, you know, hands on worked on creating an automation test, it gets very hard to conceptualize or, you know, this whole automation car that becomes an obstruction in our heads of a big black hole that we somehow can't figure out. So we want to help our students out in cases like that. What we do in this classes, we'll talk about all the theory that leads up to automation like, why do we automate? Who automates? What do you need in order to automate all that, you know, background information? And I will give you an overview. I will show you how automation happens with the help of QTP. So to clarify, this class is in no way a QTP class. It's just and making you understand the automation concepts using QTP as a vehicle. That's all. Now week five is going to be your career counseling, most of it. So in the class, we'll discuss how to create your resumes, you know, what to include in it, what not to include in it, you know, how can you portray your experience in a positive way. If you are from a non-IP field, how do you explain that change? All that we will talk about in the resume session and also the mock interview sessions. So here we'll discuss, you know, things about what kind of questions you can expect in an interview, how can you answer? See, as far as the technical questions go in testing, there are like, you know, multiple resources on the internet. But it's about, you know, answering questions that are relevant to your situation. That's how the thing will take up in week five and also the certification guidance. What are the beginner level certifications are available? You know, what might be more relevant to you? Again, in my opinion, no certification is a bad certification. So I wouldn't say one is better than the other. It's just about what would you prefer. It's about personal preference. So I'm going to give out to you all the information about these certifications. So you can make a decision as to which one appeals to you better or which one, you know, fits what you're looking for in a better way. So that's what we're going to pick up in week five. And in week five, we also, you know, keep some buffer time. Just in case we, you know, miss out on any topics, we can just catch up. In addition to all this, every day session is going to have an assignment. So you get to apply the knowledge that you gain in that day's class. We also have a live project. We provide our students with an application that, you know, you can test and find, you know, perform all the real time activities via this application. And then there is the bonus study material that every one of our participants receive. So these are some QA eBooks and ISP QB related material, which is a great value add if you ask me. Now, yeah, that's basically how the entire curriculum is going to look like. So let's talk about how each day session goes on. So the way each day session goes on is we have, we break down our session into two, three parts. One was the vocabulary part. We discussed the main topic. And there is a practical application or, you know, in other words, assignment related stuff. Now, every day session, we'll try to do all these three parts. Vocabulary is because, you know, sometimes when we work in a certain field, we kind of, you know, have some words that become common part of our conversations. For example, you might say, when is the build going to get deployed? For newcomer, build sounds like what exactly is the build is, you know, a piece of code that is ready to get to, you know, be installed. So those are the kind of words we want to like, you know, speak the QL language. So every day, we will try to pick out one or two words. Again, we also give our students a chance to, you know, bring their own words. So we will have that part where we, you know, get familiarized with the QL language. And then there's going to be a main topic, which is basically, you know, any topic that we are at that particular day. And then the practical assignment. So starting from day one, there is going to be an assignment every single day. So there's a learning curve right from the very beginning of the class. So that's how every day session is going to be like. So even though the session is for two hours, we will have a main topic for one and a half hour. And the last 30 minutes, we would like to leave it for Q&A because question and answers. See, being an IT professional is mostly about communication also. So we want to give our participants a good chance to interact with each other and with the facilitator so that we can, you know, have a brainstorming session instead of this thing like, you know, lecture. So the last 30 minutes is usually a question and answer session. And after the session ends, every day, the notes that we make during the session, which is basically, you know, whenever we are discussing the topic, I like to like, you know, jot down few points that seem important. And so the running notes and the video recording of every day session is going to be sent out to our participants in an email every single day. And these video recordings are going to help you revise the topics. If you need to see them one more time, you can just go ahead and do that. And these recordings are available for our participants for a period of 12 months. So that's basically a little bit of background information about the class. So yeah, there's going to be a vocabulary. There's going to be a main topic. There's going to be a practical assignment. In addition to all this, our students can have set up one-on-one sessions with us. Now these sessions would be about your resumes. So we have a generic resume class, you know, one day in the class we discuss about the resume, but that's not all. You can, you know, make your resume, send it to us, we will revise it or give you a make-change this and you know, unless you have, until you have a perfect resume, we can, you know, go back and forth on it and fix it and, you know, make it work for you. And similarly, if you have an interview, you can give us a call and we'll guide our students, that sort of stuff. So apart from all the stuff that happens in class, we have one-on-one sessions also with our students. Of course, we need to schedule them early on and things like that, but we do make that happen as well. So that's about our, you know, classes in general. Now today I'm going to take up a topic and, you know, give you a brief idea of how the topics are going to be dealt with in the class. So this is going to take five to six minutes and, you know, we'll take up the test planning topic. Again, this is only going to be an introduction. So let's get started. Now, you were talking about the SDLC, right? So SDLC stands for Software Test Life Sector. So this is about how a QS stands for Quality Assurance. Now, whenever you say testing, it's all about, you know, finding defects. But that's not all what testers do, correct? As testers, we not only find defects, we do activities that help them defect prevention. So basically, since we are so much more than just identifying defects when they occur, we are also about, you know, making sure that they don't occur in the first place. QA, we call ourselves QS, which is because we do both defect prevention and defect identification. So that's what I mean by, you know, QA every time I call us the QA team. So in the software testing life cycle, you can say that there are three main, you know, activities. You can just break it down into three stages. One is the test planning, test planning, and test execution. See, say you have a web page in that there are like 20 elements or, you know, 20 components or 20 items in it. Now, if you some components are related to each other, say for example, there is a month, day, year, each one is a different field, correct? You have a choice to choose month, you have a choice to choose day, you have an option to choose the year. Now, all of these three fields, they contribute to the date of birth as a collective, you know, one-part field. Now, for us to test the date of birth, you know, for a part of it, you will have to test each of these, you know, elements individually and what they constitute, you know, as collectively. So it's not only about like, you know, checking whether things are existing or whether, you know, you are able to make a choice or not. That doesn't, you know, that's not only the extent of testing. You will have to plan, you will have to understand the rules, you will have to like, you know, come up with intelligent situations to test. Only then will the testing activity be successful, correct? So in order for you for us to do all that, we will have to first understand the application really well. We will have to understand the logic, you know, based on which things are going to be, things are going to get processed and stuff like that. So it's very important for us to understand the logic. So testing does not mean that you have an application and you just, you know, work on it and find defects. This is not how it goes. As testers, we have to, you know, plan diligently, you know, apply that plan or use that plan to create our tests and eventually test the application. Only then will we be able to test correctly, identify the maximum defect and provide value as testers. So basically test plan is one of the first things that happen in a project. And the reason is because testing is not only about coming at the end, pushing some buttons and finding problems. It's a structured activity that really has to be controlled or managed in a way that the results are always consistent and effective. So basically test planning is one of the first activities. Now, every activity that we discuss in class or this basically the whole test planning is a process. Now, anytime we discuss a plan, we try to talk about what is the input, who are the actors and what's expected at the end of it. So at least these three components, in addition to that, we'll discuss what each process is, when does this happen, how does this happen. And if anything else is relevant, we'll discuss all that. So for that, let me get an Excel sheet and start typing down the test planning process to this. So as we talked about, we are going to come up with an input, output, what is it, who does it, in other words, actors, when does this happen and stuff like that. Now, test planning is the first step, correct? So when in the sense, this is the first step of the software testing lab subject, who this is an activity that is led or driven by the QA lead. Now, and but then this is in no way an independent activity. This has to be something that the QA team members are going to participate or provide their inputs. So I'll explain that in a little bit. The input for this step is basically the project plan, because the overall project plan will tell you when the project is going to start, when is it going to end, when is the QF is going to start. So one of the primary places from which we can draw our outcome and think about what to intrude in our test plan, especially when it comes to date, number of people, that sort of stuff, we will always test with this logic plan. In addition to that, we refer to the FRD document, which is the functional requirements document. This is to understand the scope of testing. See, we have to know how much, you know, how much is the extent of the application. Say for example, there is an application that has that runs 10 webpages and has probably, you know, 150 features that are implemented on it. So you need to know the size of the application, the complexity of it. You need to do some sort of analysis to come up with how much time it's going to take for us to test. So this sort of analysis, it, you know, see, if there was a previous application that you tested or, you know, that as a team, you all handled that it had like 10 webpages and sort of, you know, something similar to, you know, something, a number of features that's close to 150 features, the complex. So basically, this is the, this is a previous version, correct? So this is some history you've had in testing similar applications. So that sort of experience plus, you know, understanding of the current situation is going to help us plan better than the test planning phase. Since test plan, now the output of the test planning phase is a test plan document. This is typically a word document. Again, that's not a standard, but most of the cases, this is a word document that runs over 25 to 30 pages and has all the information that you would require in order to decide how the testing is going to go on. Now what this process is, so this document is a sort of blueprint, a sort of map that's going to tell us how to go ahead and test the application. Now if this is a document that's very important, you cannot have it like, you know, being updated by everybody at the same time or, you know, anybody who has access to it. So test plan is a document whose integrity is very important for the success of the project. That's why it's a document that is made accessible to, I mean, for anything only to the QLE. So this is an activity that's predominantly led by the QLE because it's very, very important to have this correct, to get this correct, right? And the QA team members are going to participate and provide their inputs in this activity. Now the test plan will contain information about what are we going to do while this probably is more relevant in this section. Who are going to be involved? So what are we going to test is, in other words, the scope of the testing project. Who are going to be involved, the people partner? When is the testing going to happen? So in other words, the schedules. How is the testing going to happen? So when I say how, it means how would you create the test cases? Would you use an automation tool or not? So how in the sense, in this section, you can talk about the deliverables, like are you going to base your testing on test cases? Or are you going to be basing your test cases on, you know, creating an automation test script? If yes, what is the naming convention, that sort of stuff. This will also have information on what is the output that you're going to generate at each phase. How you are going to communicate with each other in the team, you know, and what are the roles and responsibilities of the team members. And how if you have, you know, there are any tools that you're going to use, what is that? What kind of data are you going to provide for your testing? What kind of, say, if you identify defects, how to deal with them? So the defect management process is put into your test plan. And then if there are any risks that your project might run into, those risks are, you know, listed and how to handle the risks, that plan is also made a part of a part of the test plan. And then see, and, you know, given the time, we would test it, we would test the product until we find all the defect, correct? But it's something that cannot go on forever. So when the time is limited, and we know when you have so much to do, you will have to come up with a situation on when to stop testing. See, even today, if you have like, if you go to like any of these popular sites like Amazon.com, any of those live sites, if you sit down and test for probably, you know, a few months at a time, you're still going to find one or the other defects because, you know, no software is perfect. So, but then is it really worth it to sit that much time to find that one defect or just send the product into production is always going to be the question. So a test plan is going to talk about when to stop testing as well. So here we would also have information on the exit criteria. So when the testing is going to happen in the schedule, in addition to this, we'll also have information about the entry criteria, which means when to start testing, we will also have a when to stop testing, the environment in which the testing is going to happen. And if there are any reports or metrics that you're going to collect, that information is going to also going to be a part of the test plan. So basically, these are all the constituents of a test plan. Now, for some reason, this is also an important question they'll ask you, what should the test plan be? Sometimes the question could be in the form of what what is the table of contents for your test plan. So they're looking at what are the components of the test plan. So briefly, these are the components of the test plan. Another interview question that comes with the topic of test planning is, what is the difference between a test plan and test strategy? Now, as you can see from this, the constituents of the test plan, half of them are managerial stuff like who are the people, what are the schedules and stuff like that, the roles and responsibilities. So let's just use a different color to point out the managerial parts of it. But some are very specific to the application that we're testing, like the scope, how are we going to test, the tools, the data, the defects. So all of these are specific to the application that you're testing. So anytime you're trying to come up with a plan that is technical in nature and that you're going to concentrate on the application being the major focus, those parts of your test plan become your test strategy. So you can say that a test strategy is a subset of your test plan. Test plan will have managerial plus technical insulation. In other words, managerial in the sense this is project related, technical in the sense this is application or the software related. So all the parts that are specific to the application or the technical information related information, this becomes the test strategy. So in the class, we will discuss about entry criteria in detail. We will discuss about functional requirement document and understanding the scope of it in detail and the delegables in detail, risks, risk management, that part in detail, exit criteria. So all of that is going to be discussed in detail in the in detail in the class. In addition to that, we'll also take a look at a real time test plan document to get a good understanding of this. So I hope that gives you a good idea of how day to day classes go on. And I hope this demonstration will help you make a decision on whether this class is right for you or not. Thank you for your time. Thank you so much. Bye-bye.