Quality Assurance Testing from Scratch to Finish

1. Introduction: Little introduction about me, my name is Emeka, and I used to be a quality assurance engineer for many years. I've worked for a lot of private companies and government companies as well. I mostly specialized in minor quality assurance, but I've done some automation testing as well. But in this course, I'm going to be training you guys on minor quality assurance. If you need to QA or you just playing around and sort this course. Welcome. I'm actually going to do some training to get you guys up to speed in terms of getting knowledgeable manual quality assurance, what are the roles and responsibilities of a QA engineer, what do they do their day to day activities, and also interview preparation and tips on how to make a good resume. So definitely enjoy the process and happy learning. 2. What is SDLC: So what is SDLC, where SDLC stands for software development life cycle. So this is kind of like where the whole magic happens. So in terms of software development life cycle, I'll kind of break it down in terms of, you know, when an application or a software is trying to be developed, right? What how is the process or the method of developing an application or a software from scratch to completion. So entirely that whole process is what we call a software development life cycle. Now, in the software development life cycle, it goes through a lot of phases, and there are a lot of people, subject matter experts or job functions that play roles in the software development life cycle. So I'm going to explain the whole like in terms of what are the team players, you know, how those process take place, you know, when it takes place. And also for you, QA, how do you participate in the software development life cycle? What is your role? You know, what do you do in that process? When do you come in? So all these are going to explain to you later on in the course. 3. How does SDLC work: So how does SDLC work? Well, like I mentioned, it's kind of like the umbrella of how an application gets developed from start to finish or a software gets developed from start to finish. So now in the SDLC is all broken into phases. So one of the first phases is the requirement analysis phase. Now, if you're kind of new to SDLC or new to IT, what is requirement analysis phase? So requirement analysis phase is where the business analyst or the product owner, you know, sits down with the stakeholders. So we is a business analyst. A business analyst is a person that is hired to actually write user stories or write the functions of how the application or the software is going to be developed. So the artifact or the document, the user, the business analyst comes up with, is a user story or a business requirement document. So let me break it down further. So this person, a business analyst, goes to the stakeholder. Now, who's a stakeholder? Stakeholder could be the business, someone that is actually for let's, for example, we talk about Walmart. Who is a stakeholder in Walmart. So it could be the managers, you know, people that are actually like working in Walmart that have this need to let's say they want to develop an application for their customers to go online to purchase product, right? So the managers or folks in Walmart can get a business analyst and SG know what, we have this issue. We have this problem. We trying to develop a software or an application that can allow customers go online to purchase stuff. That's a typical example. So what the business analyst does is that the business analyst sits with the stakeholders of Walmart and they kind of, like, you know, draft high level scenarios of what this application should be. So the application could be typical example, it could be a regular application where people can purchase stuff. So it has to have a logging ID, it has to have a password. It has to have a checkout screen. It has to have where you could enter in your card information, all those things. So the manager kind of has an idea of what they want. It's up to the business analyst or the product owner to put this into a more structured way that is more thought of, is more organized where the developers or wherever can work on it. So the stakeholders are kind of like giving ideas high level, not organized. So the business analyst is now responsible for getting all those ideas and putting it into a more structured format. So what is a more structured format? It could be, for example, the application should have a user ID. The application should have a password. Now, what kind of password? The application, the password should all be case sensitive. You know, it should be eight characters to ten characters long. So all these are kind of like specifics, right to the point. So that's what the business analyst is responsible for doing. Making sure that whoever is going to develop has a clear understanding of what they're trying to do or what the application is supposed to do. So that's the role of a business analyst. Business analyst takes all these ideas, puts it down into a more structured organized format for whoever is going to develop the application should work on. And the end product of the document or what the business analyst develops, the end product, is what we call a BRD. That is a business requirement document in Waterfall. I will get into what Waterfall is later on, in Agile is what we call a user story. So a user story kind of like talks about a scenario, what are the acceptance criteria or what the what the story should have typical user story could be the application should be able to have a login page. That's a typical user storage. So all these are kind of broken down into bits. So it's not going to be like a document where everything is just thrown into know. Everything is broken down into sizes, where you work on this and you work on that. I'm going to say explain more in terms of how they work how the process in terms of how people or how the team works on this application to get it into the completion phase. But just a recap, we talked about the requirements analysis stage and who those who was responsible in that phase, is what we call a product owner or a business analyst. We are the ones mostly responsible in interacting with the stakeholders, kind of, like, getting their ideas into writing or into a format where they can be able to, you know, get it more down to the developers for them to develop. 4. Design Phase: So the second phase is what we call the design phase. Now, this is where the bulk of the work happens. So who is responsible in the design phase. So like I mentioned earlier, the requirement is drafted. So what we call the business requirement document or the user story, the business analysts have sat with the stakeholders. They put everything in writing, and everything has been documented. They've done the sign off by the management. So the management has actually signed up that o, this requirement is complete and good to go. So in the design phase, the developer picks this up, right? So when the developer picks this up, they start to go into the development phase where the developer starts to develop this application. Now, it could be in phases or it could be all at once. I'm still going to break down the different kinds of methodology, and I'm going to explain to you what methodology is in terms of how this breakdown happens. But just in general, the developer who is actually responsible for writing the code, is the one responsible for designing this application. So they write the the codes based on the user storage. So the user sc mention or the business requirement document that the business analyst gives to the developer is very specific to the point, you know, that everything should be labeled directly. So guess what, the developers are not the one the creativity doing the creativity is up to the business or the business analyst or the product donor are the ones that have figured everything out. So what the developer does is develop. Even though the developer still has to do some creativity in terms of how to develop the application or what kind of codes and stuff to write, but it's not the responsibility to go out of scope. The responsibility is to develop the application as the requirement is stated. So if the requirement says, the the user name should be of this character, it should be eight to ten characters. That's it. It shouldn't be like ten or 12. They could go back and suggest to the business analyst and say, okay, I think it might be this, which many a times it doesn't happen. But even if they suggest, right, the business it is left for the business analyst or the product owner to go to the management and say, Okay, what do you think about this? You know, But many a times when the business analyst or the product owner gets those requirements drafted, the developer develops according to the specifics of the requirements or the user story. 5. Testing Phase: Application thoroughly. Now there's nothing like 100% defect free or 100% error free application. Most applications are going to have defects, even when they go into production. Like when when I mean production, I mean, when they're going to release, when actually the customers are using it, there's still going to be errors, but your role as a quality assurance engineer to make sure that the major errors are cut early. So the ones that might go into production or the customers using might be lit, maybe minor errors that doesn't stop the customer from doing what they need to do. So for example, if a customer cannot go to add their carts, add items to their carts or maybe pay for whatever they bought online, that's a big error, you know, and we're going to talk more in terms of, like, you know, high pits, how do we prioritize something that is a defect or an error, you know, so all these are going to explain like the whole process, the day to day the day to day responsibility of a QA, you know, what do you look out for? How do you do your job? You know, what when you log on to the system log on for the day, what are your roles and responsibilities? We're going to talk more about that in the upcoming course. But in general, for a QA, you know, your role is to test application to find defects. And that requires a lot of creativity. That requires a lot of thinking outside the box. Like, for example, typical example is usar in password L summit. What if I uses all e ten e ten characters, right? Typical example. What if I make all of them more case sensitive. Is that sheer speed and error? And if you're thinking about that, that should also match what is in the requirement business requirement document or user story. So your user story or your business requirement document is your guide in terms of how to test. So it's going to it's going to state exactly and what the application is intended to do. Now your role is to test against it. Your role is to do opposite of what he's doing, what it's supposed to do to create an error. So if it says, use a name and password or go to check out, you know, you do the opposite To see how you going to react when you do the opposite? If you do the opposite, what should you do? Definitely it should give you an error. Because if you do the opposite, you should give you an error. If it's not give you an error and taking you to where it's supposed to take you, that's a defect. That's an error. You also do the positive. The typical userm password summit the right way, and that should take you to the right place. And what we call that is positive testing. So when you do the opposite, it's called negative testing. Negative testing is testing against the application, testing what the application is not supposed to do. To see what the reaction will be. And whatever the reaction is, you should compare it to the business requirement document or the user story. So if it says user name password, submit, you enter in user name, wrong password, submit. I should give you an error. And what does the requirement say about when you enter in user name wrong password and submit? What error does it display? Is it showing you the right error or not? So all the things it's kind of complex, you know, and it's interesting, very interesting like it requires a lot of creativity, a lot of like thinking outside the box, guessing, how can I break this application? What can I do? And many times your ought process should be from, you know, in real life scenario, when a customer is using an application. Multiple customers are using the application. They're going to be drawing different things, doing different things. Some of them might logging, A person might put in the cards. Some people might put in items in their checkout. You know, some people might just different things are going on different times. Your role is to think of different ways of how these customers are going to be using this application in real life, you know, and think about how can I find errors. So your role is not to make sure that the application is working. No. Your role is to break the application. Your role is to find defects. Find ways of how the application will give you an error. Because if you look if you think about it in a way that okay, we want to make sure the application is working, okay, se the name password submit, go to check check in, log in to the application, add items to your card, check out, other things, it's probably going to pass, right? But now when you start doing things of negative, negative testing like I mentioned, so you enter and use a name wrong password summit, what happens? Does it give you an error. Use the name right password summit. You now going in to the check in, you know, pick pick items in your car, you know, take it out, does it take it out? Does it update, you know, things like that I just try to break the system, you know, do things that will require you to like because those things encoding are more just sort of the complex things. So the positive part is probably going to be easier for the developer to develop and it's probably going to pass. But when you start doing things like, you know, in real life, because in real life, customers are going to do a lot of you know, things, different things like they can add a card. They can add add items to the card, next, they can take it off, or they can purchase it, go back, they want to cancel it, you know, things like that. All the scenarios are the things that you're going to be thinking about, like, how can I break the application, or how can I find errors by thinking like this. So that's how you think as a QA or a quality assurance engineer. And we're going to talk more in terms of you know, the roles and responsibilities, you know, what artifacts or documents you need to come up with as a quality assurance engineer to prepare you for testing. We're going to talk about types of testing. So there are various kinds of testing. So like I mentioned, the one I explained to you right now is positive and negative. When that posses are negative, there's still various different kinds of testing. So we're going to explain more in detail and down the line. 6. Deployment Phase: The next phase is what we call the deployment phase. The deployment phase is so let's say everything is like you've done your part as a quality assurance engineer, you tested the application, you found defects or errors, the developers fixed it and gotten back to you, and I'm going to extend the whole process of when you find an error, what do you do? How do you go about it? But let's say everything is done and they're ready to, like, put the application out for the customers to use, right? So that's what we call the deployment phase. So the deployment phase talks about, you know, there's going to be a process of how, you know, the application is deployed in production. So when we say production, we mean in use, like for the customers to go online and use it. So many a times, that process or deployment phase is what we call release. So when they say a release is also talked about deployment. So how do the team coordinate, right? So when a release happens, is when they've done the user stories, they've developed the application, they've tested it, and you've given your thumbs up that so far is good, like everything is working as expected, then the PO Also the death team collaborate in terms of pushing this application to production. One thing you have to be mindful about is the terminology. When I say terminology is the terms or IT jargons or you know, methodology, Agile, Waterfall, QA, PA, PO, business requirement document, all these terms, you have to be familiar with it and be able to talk with those terms because that's kind of like the language in IT. That's how you know people understand. So when you say production, they're not going to say when they push it for the customers to use. They're going to say they're going to push it to production, you know, and also how do they push it to production, a release phase or a deployment phase. So all these terms is something you need to be familiar with, you know, you need to speak this language in IT, you know, so that way because when you're working on a team, these are the kind of these are the things you're going to be hearing, all these terms. You're going to be coming across most of what the terms, so, you know, you want to be able to familiarize with all these terms in terms of, you know, what does it mean. So like I said, I'm So the deployment phase talks about release, right? And the PO and also the business business analysts and the developers, you know, collaborate in terms of getting this effort. The QA is not very participating participate in this process. So the Q ways don't really participate a lot in the release phase is mostly because the development is more active in this phase. They are the ones that make sure the environment is stable. They make sure the environment is ready. And um one thing I'm going to explain also is the environment, right. So when the development work is going on or the Q was testing, they don't they test in a different environment than when an application is deployed in production. So when an application is deployed in production, that is a different environment because I'll tell you the reason why because when for example, I'll use a typical example Walmart. So the Walmart website, right? That application, they might want to update some certain things on it. It is not going to be smart to use that same server or that same environment to do development work because it could mess or interfere with their real production like when an application is in production, right? So let's say a developer writes a code and puts it on the environment in the test environment or the Dev environment. If they share the same environment with the production environment, it could go interfere with the application or the website in production. So let's say typical walmart.com, right? Customers are using it on a constant basis, they're buying, selling. I mean, they're buying stuff, you know, things like that. Now, if if there's a new idea or a new initiative of developing an application or a future that they're going to add to walmart.com, right? They want to add a feature to that. Right. So they don't when the developer works on that feature, he's now working on the same environment as where the walmart.com is being hosted, if that makes sense. So they us in what they call the Dev environment. You're going to hear at them a Dev environment, QA environment, pre Prod, UAT environment. So they have a separate environment, a separate space where they do development work. When I mean development work, I mean dev, testing, UAT, preprod You could have sometimes you have the Dev and the QA could share the same environment. UAT can have a different environment or what we call prep before production. So production is actually where the application is hosted, where the customers get to use the application real like your typical went gone websites and stuff like that is production environment. The application is in use. But that is not the same application where that is not the same environment where the SDLC takes place. The super development life cycle. The whole phases are talked about requirement, development Q way. That is not the same phase of when they do the work. So when you when the development is writing the code, the developer is writing the code, the Q when you are testing the application, you are not testing the same environment as where the website is being hosted for customers to use. So once you do your testing, the development writing the code, you're doing your testing, you give it your thumbs up, then they push it they push that change. Whatever the the developer wrote, or the changes, the new feature he created or the new add ons or anything, and you've tested it, they push it now to production to where the customers were going to be using it. So when work is going on, it's not the same place where the customers are using the same website. So when they do everything. So even the data, everything is all mockup, all is all fake, right? It's not real. Once everything is done, then they push it to production where the customers can now see the change. So let's say the future was to add let's say a different kind of pad to the checkout. So when when you're trying to make a payment, you want to add MX now to one of the options of how a customer can pay. Maybe Amex is not one of the options in production. So the developer writes the code to allow AMEX, work on the website. When he's writing the code, In production, MX is still not available. But he has written a code to allow MX customers be able to purchase with the MX card, and that environment is called a Dev environment. He sends it to you, Un test, test that MX customers can use their card to purchase products on the website. You test that. That is still under the Dev and Test environment. Once you've given your thumbs that I tested it, MX customers can use their card to purchase things. And remember, you've done your negative testing, you've done all those kinds of testing, you've given your thumbs that everything is good. Then they do the deployment or the release. So the deployment of the release is that the they have now push that feature, that change to production where the customers now can use AMEX card to purchase. So when you push it is called a release. When you push it to production, right, the customers can now and they do the announcement that ok, customers, I mean, despite on their website now, you see the Mex logo and stuff like that that customers can now use Amex online. So once it's on their website, then I mean, customers can now use the AMEX card to purchase. So that's what the call then that change has happened and that change is now in live is now in production for the customers to be able to use. So that is kind of like how the deployment phase happens, you know, and also in terms of the environment. So that environment is also very key. You're going to weakness that a lot. So the death, the Q environment is different from the production environment. And we're also going to talk about UAT, what UAT is about in terms of, you know, how does that process happen before it goes into production. So I just that's that's actually that's that's a phase of deployment to release. 7. Maintenance Phase: And the last phase is maintenance and the software development life cycle. So in maintenance, that's pretty much easy, easy, like, you know, the application design production, this has been released to production. The customers are using it. You know, now they're giving their feedback, right? So, for example, maintenance is there so that they could see how the customers are using the application. So let's say, you know, the customers are finding it easy, you know, no defects, no errors, you know, then they send the feedback. You know, we take no, we, but the business takes the feedback, the team, the development team or precise the business analysis, to be more precise. They are the ones that take the feedback and send it to the stakeholders that okay, the application is working fine, no errors, no nothing. Now, if, for example, there's a future that was developed, but it's not working, right? So you guys missed it. So the deve missed it, the QA missed it, you know, it's in production, the customers are complaining that they can, for example, they can check out, you know, there's an error in production. That is an issue, right? And that's something that the maintenance phase is for. So the maintenance is to check right the feedback from the customers. How is the application performing in production? Are there any issues? Are there any errors? Now, when there is an error, you know, in production, you know, then there's also a different process of how you can remediate those errors. You know, who, like, you know, you're not going to like cut they're not going to discontinue the whole application in production. No. So let's say you developed the software, right? And you put it in production. Even if there was an error, you're not going to shut down entire application down. You're just going to whatever that error is, you reach out to the BA, we get information, then they work on then they send it to the developer, they notify the developer that, this is what is breaking this is what is happening. This is the error that getting in production. So what happens is that what we call the hot fix. A hot fix is where a production issue. Most of these hot fees are mostly high priorities, right? So it's like for example, in the application, they could say, maybe customers cannot add items to their car. Right. And for them to check out, they need to add items to their car, then to go to checkout phase. So when they add something to their car it's not displayed. That's a hot f that's a big issue, right? Stopping customers from buying stuff. So what the developers does is that he writes a code. Not in production, he writes a code in the dev environment. Me when we talked about the Dave environment, he writes the code to allow customers to be able to add items. So he writes it essential to U now, the Q way. You test it, so you buy a whole bunch of stuff online and see if he's able to you add a whole bunch of stuff online to see if it can be added to the c. Remember, that is not production environment. That is still the dev environment. So you do all this, you make sure it's working. Once you see that, okay, you go as a customer, you go add items to your car and it's adding, right? You take stuff out, did they take out, you add stuff again, did they add all the kind of scenarios? You make sure that you can customers can actually ask off to the car. Once you get the ums up again that to the death that is working that the you cannot add c. Then the dev will now push that code to production to update the current error. So whatever that error is, he's going to after I have reten the code and you tested it, he's going to update that error. So that error what the code wrote is going to replace that error that that is currently going on in production, right to get it fixed. And again, maintenance still happens. So now customers are now going to use that application again. Continue to use the application to see can they now add stuff to their car? Can they now add stuff to the car before they check out. If they're able to, then that's a success that way that error has been fixed. Then they keep using the application. Customers will keep using the application continuously. To see if everything is working. I mean, they keep using the application, not to see, but they'll keep using the application. Then the BA is monitoring, right? To see if there are any issues that are being found or what the customers are saying, are they liking it, or, you know, are they still finding more issues? And in real life scenarios, maintenance is huge because customers do find issues with in the application. They find errors, you know, and that's something that that's why we have maintenance because we're not going to push the application and production and dust our hands and s were down. No. Once we push it to a production, we still have to monitor it to make sure that no errors are being found because if an error is found, then what the customers doing. They are like stop, right? So it's like and that can stop business and that can stop progress. So what they do is that we have to monitor it. So who monitors is the death team, the death team, the SDLC team. So the business analyst developers, you know, we are all there, ways, you guys are still there part of the team to make sure that even though this application is in production, the BAs are still monitoring, right? Just to make sure that the application is still successful while the customers are using it. And if there is any error, that I mentioned, there is a whole process as I explained, of how we get this fixed and push it back to production. 8. What is a Methodology: Now down to methodology, what is the methodology? Methodology. Remember when I talked about software development life cycle and how the umbrella for how an application is developed from scratch to finish, right? So that's what we call the software development life cycle. Now, think about the methodologies one step below SDLC. So now, I remember when I mentioned about all the different phases, the requirement phase, the development phase, the testing phase, you know, the deployment phase, the maintenance phase, those phases is what we call SDLC, right? But a step below is methodology. Now how do the requirements the depth, the Q way, the deployment, the maintenance, how did they fall or how are we able to execute an application using all those phases, right? So the software development is just how application goes from scratch to finish. Now, in those in those beginning to end, we have phases, right? Now, the methodologists using those phases. So in in in in test in development, Those phases can differ based on the kind of methodology. Based on one kind of methodology, those requirement depth Q wave maintenance could differ from another process. So they differentiate, they are different on how you use those different phases. But in general, those five phases is across all methodologies. But now some methodology can be different. From others, you know, using those five phases, right? So the two common ones that I'm going to be talking about is waterfall and agile, right? So Waterfall is kind of like in the beginning when IT was new, right? Waterfall started off with waterfall. So Waterfall is is kind of like an older approach. Agile is the new approach. So I'm going to explain more in terms of what waterfall is, what agile is, what are the pros and cons, you know, which how they different. And I want you guys to be familiar with both because I feel like when you know waterfall, you know agile, you're more equipped. You're more versatile in terms of being a more experienced quality assurance engineer. So I think nowadays everything is agile, like a lot of companies are transitioning from waterfall to agile. But it's very important, it's very good for you guys to still know waterfall and know agile. So that way you can be able to be more educated in terms of knowing the differences, knowing also be more equipped to be a more quality qualified quality assurance tester when you know both. So that way, you know, you're more knowledgeable in terms of understanding the the SDLC cycle and know how a QA performs in both waterfall and agile. 9. What is Waterfall: So what is waterfall, right? So Water fall is a methodology, and we use that term methodology. So Waterfall is a methodology under SDLC or Super development life cycle. So what does waterfall comprise of? Waterfall comprises of all those phases. So there's a requirement phase. There's a development phase, there's a testing phase, there's a deployment phase and there's a maintenance phase, right? Like I explained all those phases in waterfall. But how is it different or what is waterfall? So Waterfall is a methodology where an application is developed entirely from scratch to finish before it goes into QA and Diploma. So so just like when like I mentioned, like for the business analysts, right when they sit down with the stakeholders and the kind of like the stakeholders explains what they want, what the application should look like, what they need. The business analyst takes this idea, write it down into a more detailed process, into a more detailed document where the developers can be able to develop the application because you don't want to have confusion when the developers are writing the codes. They want to be as specific as possible, specific to the dot as possible. So in what off, The person that writes that sits down with the stakeholder is what we call a business analyst. Right? And I'm going to explain who sits down with the stakeholders in Aj, what they're called. But in Waterfall, someone that sits down with the stakeholder is what we call the business analysis, right? And the documents that the develop that they create after speaking with the with the stakeholder and they send it to the death team, the developers on the key way to do their work, is what we call a business requirement document. Now, in some cases, there are situations where they have business system documents. So a business system document is a step below business requirement documents. So business requirement documents is where where all those requirements are written. So what we call a requirement. The requirement could be bullet points scenarios, right? So it could be An application, a login page should have a user ID. That's a requirement. I I I waterfall, we call it requirements. So a password should be eight to ten characters long. That's a requirement. The login page should have a submit button. That's a requirement. Once you click the submit button, the user should be able to add items to their ct. That's a requirement. The user should be able to add up to t items on their cut maximum, that's a requirement. So A this is stuff that the business analysts was discussed with the stakeholders. And the stakeholders was kind of like the stakeholders don't have to come with all the whole solution. It is what we call the business analyst and and the stakeholders sit down and they have this conversation like they brainstorm, how the application should feel. And what this process of the business analysis sitting with the stakeholder is what we call a requirement elicitation session. So a requirement elicitation session, is where the business analysts and the stakeholders. So managers of the company sit down and they discussed how the application should be. So that's what you call cool requirements gathering or elicitation session or workshop sessions. So once this is actually documented, right, then the business analysts gets down to a more detailed process documents it I remember in what up for the scratch is beginning to end. So they developed the whole application. Let's say it's a big software ware. There's a the logging page, you have stuff that you could buy, you have stuff that you could add to your card, you have stuff that you could whatever the application is, the business analyst is going to document everything. Everything right in a business requirement document. And I told you what the requirement is, so it's like other scenarios, right? So the whole requirements will have some requirements to have up to 300 scenarios, right? Once they have that, they go back to the business, and c this is what we come up with, right? This is what the requirement is for them to review. Once the requirements once the business analysis once the manager reviews it, right, and everything is good, then they sign off. So the business has to sign off on the business requirement documents. Because if they don't sign up, it means that they haven't given the approval, because the business analysts cannot just write off and give it to the developer. I know everything is processed, everything needs approval and stuff like that. Most of these things are like big deals, so right? So the business goes to the business analyst goes to the stakeholders and says, they show the requirement document of every scenario they've written and for them to approve. This process is what we call a jab session, JAD jab session. So in the jab session is where the business signs off. So they sign off and they give their approval and this is also they could come back and say, guess what? This scenario here in the requirement document, I don't want this, or they could say, can be done this way. So they go back and forth. So once everything is complete and signed off, then the business the business analystis that requirement that signed requirement documents and sends it to the developer. Also, they also send a copy to you, the quality assurance engineer. Because that way, once the developer is developing the whole code, now you have what you have the business requirement documents in your table, you have the copy. So now your role is, if it has maybe 1010 requirements, right? Your role is to come up with ideas of how to test those ten stories. And I'm going to explain to you how you can te how you can test those down the line, but. Your role is if it has ten scenarios in the requirements that has been signed off, your role is to how do you capture those ten stories? How do you test those ten stories? Right? So in Waterfall, like I mentioned like Waterfall is everything from scratch to finish. So the develop the business anal writes the whole user stories requirements. The developer tests everything, develops some developer develops everything, the whole ten user stories. You test who you write test cases and you test the whole ten stories, and it goes into deployment and it goes into production. So you push the whole feature or the whole software or the whole application to production at once. So everything is done instantly. So now what is kind of like the drawback, right? So the disadvantage is that it's not flexible, right? So let's say the developer develops the whole application. And the business, the business has to the business analyst has to approve what the developer has developed because even the developer develops it, they're not just going to push it in production, they have to approve it. So the business analyst with the authority of the business of the stakeholders who approve that application. And let's say there is a mistake. Maybe it was eight to ten characters in password. Now it is now this change their mind. The business change that mind said they want to make it 11 to 12. You know, or things like that, it's like they have to it's very complex in terms of once an application of the developed from beginning to end, it's hard to start changing things. It doesn't give room. You know, and sometimes, I'm going to explain, you know, the difference between water fall and age because you know, when you are learning something or when you're getting used to something, you keep improving, the more you keep doing it. The more you keep doing, you keep getting better. So that in water fall doesn't allow that room for improvement because right there is like the thought about the whole requirements, the business and the stakeholder have thought about the whole requirements. Right? And the developers developed it, you've tested it, appreciate the production. There's no room for that creativity to silk again know what. I thought about this this way. I want to do it this way. You know? So in what after everything is done instantly. So once once the death and once B B and stakeholders sit down in the elicitation session, they write the whole requirements. The sign off, the developer develops everything, you test everything and you push it to production. So there's no room for that creativity where, what if it, it does this way, you know, so that's a diferent between waterfall and Agile, but I'm going to explain Agile later, but in terms of waterfall, it's like everything is done from scratch to finish, from beginning to end develop is done, testing is done and everything together, and pushed to production. So that's kind of like an idea of waterfall. I'm going to explain Agile in the next chapter. 10. What is Agile: For the second methodology, I'm going to be explaining agile. In Agile, this is more popular and this is more common, and this is what a lot of teams a lot of companies are using now or adopting now because they felt like in terms of the software, they developing more effective, better software applications than, you know, the traditional waterfall. Remember, I thought that waterfall started earlier on, but now it's like agile is what everybody's diving to go a lot of companies are adopting. So remember I also explained about the SDLC and the different phases in SDLC, right, the requirement phase, the depth, testing, deployment, maintenance, all those phases, and also in water falls, like how those phases tie into water fall, like everything is done from scratch to finish at once. Now in Agile, it still has those phases, right? So the requirement phase, the development phase, the Q way phase, the deployment phase, the maintenance phase. Waterfall and Agile have those phases. But the only difference is that how those phases are used, right? So now I'm going to explain Agile. So in Agile, remember I explain to you that someone that sits down with the stakeholders or the managers in the company is what we call the business analysts and waterfall in Agile, they're called product owners. Product owners, right? So what are for business analysts, IGL product owner? Now, also, remember I mentioned that the document that a business analyte comes up with right after sitting with with the stakeholders is called a business requirement document. But in Agile, yeah, that meeting still happens, right? So they still sit down, the product canner sits down with the stakeholders, right in Agile. But that document is called a user story, right? So it's still the same process that I mentioned, but it's just how they do it. So now, this user story. So Agile is broken into phases, right? So remember I told what of, like, they developed the whole requirements, maybe the ten scenarios in one document. In Ag D is done differently. So let's say they want to develop and fit an entire application. So what happens in Ag is at first, they're going to break the application down. They're going to say, what is the highest priority? Who determines the highest priority? The business? When I mean the business, I mean the stakeholders, the managers and the comple manager in Walmart, for example, they can see that with the product owner, second gues, I want to develop this application. I want to develop the software. Then the PO, the Paton who has the business. What is your highest priority in the software? First, you've got to have a logging page. The customer should be able to log in first. This the biggest priority. The PO is going to break is going to take the log in functionality first. Then they're going to be what's the second one. They should be able to add stuff to their c. Then the PO start second phase. Then the third phase, you should be able to check out when you mean check out, be able to enter in the payment information. So the business is telling the product owner based on priority, which one is which one comes first. I sell one application, but the application is broken down into phases, right? So which one is a high priority. So the business tells the product owner which one comes first? What is what is more important to them first for the application to be built? And once that is determined, then the PO starts to write user stories for the login functionality first. So you're not going to write remember what are for they write everything at once. Knowing agile, they write only the user stories for the login functionality first. So the user story could have maybe four scenarios. Maybe user name password, you should have suit, the types of password that it takes other things right Once the PO writes down the scenarios in a user story. So let's say for example, user story can have so as I mentioned, the login page, right, the par have four user stories, right? So user story is just scenarios, right? So it's going to a user story can comprise of user ID. Description. So what does user ID could be user name, right? Er name function user name. Description could be a user should be able to enter in user ID to access the application. Then it could also be acceptance criteria, right? Also, I'm giving you things that make up a user story. So user story has the couple of characteristics that make up a good user story. So who's responsible for writing the user story, the product owner. So the product owners responsibility to say, Okay, this user story is qualified to go to the business for them to approve it and to see or for them to review it. So it has to have some certainties user summary description, acceptance criteria, you know, what the story should entail, right? So Once that is like determined that once the user story, the product owner has come up with that the producter has come up with those user stories. Then they take it to the business. So remember, the product um probably have like four user stories, right? So it's broken all the log in function it in to four scenarios. So the user ID, password, summit, types of password characters, and all those things. They take it to the business. The business says, Okay, I love it, right? This is exactly what I want. They give the approval, right? Remember in water fault I said as a jazz session in agile, there's no gale session because it's just small small bits, right? In Waterfall, there's a big there's a ga session because it comprise of the whole scenarios, right? But in Waterfall is in Agile is in phases, so there's no need for gale sesion. So the business approves. When they approve it, see the same phase like I mentioned with SDLC. They send it to the developer. The developer picks up the user stories, you know, they work on it. They send it to you. Now, you don't prepare for the whole application. Only what you are preparing for is to test only the logging feature. That's all for now. Once the logging feature, once you tested the logging feature at the developer has developed it here, you now test the logging feature. Then they send it to for deployment, right and going to maintenance. Then the no pick up the second. The second phase and the second phase could be to check the ct, right. So that means can you can customers like log in to the application? I mean, not the log in to the application. Can they add items to their cat and all those things, right? So that's the second feature. So that's why it is like an aj it goes in phases, right? I mean at some of those phase it's a whole process because now we can stop talking about scrum and all those things like different frameworks under agile. But the agile in general goes in phases, right? So waterfall is like a huge like every the whole entire application, and that's waterfall. Then agile is like in phases. Everything is broken down into phase, but they still adopt the whole stages of SDLC, right? So the whole stages like the requirement stage, the development stage, Q way stage, the deployment stage and maintenance stage? Water fall and agile are consistent in those, but how do how they differentiate, right? So in water falls, everything is developed from scath to finish. Agile is like, you know, in phases. So they do phase one, phase two, phase, until the whole application is developed. And as they're doing the phases, they're developing the testing, they're pushing it into production, develop tests, push into production. So some features are coming out gradually, gradually, gradually until the whole entire application has been developed. Now, what are the advantages, right? Ch, why do people using j because it allows room for change. So let's say in phase one, we develop the log in page two, customers can add to the c. But you know, the business and the PO writes the user story. Developer is developing it. But the business say guess what, I changed my mind, right? They don't need to change the whole entire application. They don't need to change the logging functionality. They don't need to change that phase. So whatever that phase is in s adding items to their c They can just go there and tweak it. So that allows room for to be adapted, the application to the adapted to. I allows for improvement. So let's say the phase one, you're writing the log, you do the logging page, you develop the logging page. Second phase, they're doing the adding items to the cap. The more you're working on it, the more knowledgeable you are about the application. Both the death, both and the Q way. Because and also the business can actually write better stories now, because now the more you're working on an application, developing it in phases, you know, everybody's all discussing, talking about it, ideas are flowing. Because now it leaves room for more effective software. Because now it's like everybody's like working on it, you know, we are making changes. I mean, we are doing it. So when you keep doing it, you know, you keep improving, you know, rather than in waterfall, the only thing you are doing is developing because everything the requirement has already been drafted, so you can't change anything. Everything starts from the requirements. So once the requirement is written, there's no room for ideas because the developer is not doesn't require to have any idea, it's just doing what the requirements stat stating. But in Agile, you know, the requirement is not completely fully written, it's just written in phases. So now the business and the PO can self guess what in phase two, you know, because they've worked on phase one, you know, Phase two, more ideas can start coming in thats can start changing. You know, the requirements can start changing. You know, the user stories can start changing, you know, and that allows for more effective software, wide and what are for once they sit down, the business analysts and this business sit down in a room and they write the whole they draft the whole requirement, right? So there's no room for that idea. So it's whatever they tought at that moment. That's what they're going to do. But in AJ, they have the longer time to keep thinking, keep improving and things like that. So that's why a lot of companies are start adopting Aj. And in terms of Aj is more expensive because interim there back in my career is like the higher key ways in waterfall when the application has been developed, right? So when the application is written, the business requirement is written, the developer has developed the application, then the higher keyway just so you just come in for three months or four months. However, test the application and that's it, right? So you have so much put put on your plate like you have all these requirements that you need to like you know, understand and write, prepare your documents and how to test it in just form once or whatever. But in Agile, you know, as from phase one, the QA is already involved, you know, so because you're going to be testing all those phases. So that way, the de team is involved, the QA team is involved, the product nine is involved. So it's more expensive, right? Everybody's involved right from the get go. So that allows, you know, but it has its advantages. But in terms of cost, Agile is also more expensive. But I mean, companies are stressing the value of adopting Agile because, you know, it allows for better software application, it allows for creativity, he allows for mistakes, you know, so that's different between the waterfall and agile. 11. What is QA: Now brings me to the big topic. What is QA, right? What is Q quality assurance engineer or testing. So sometimes you could hear the term quality assurance or you could hear the term testing. You know, it's all the same thing, or you could hear the term quality assurance engineer. So what is quality assurance engineer tester or QA for sure. So a quality assurance engineer or a tester, you know, is a professional that works in the software development life cycle that tests the application. So that's your role. Your role like I've been mentioning in the course is to test the application. So, you know, now I'm going to explain also different kinds of testing. I'm going to explain what are the documents or artifacts that is required for you to have or you to do your testing or to do your job or to do your role, you know, so I mean, QA is big, right? It's really big, like in terms of they have various kinds of testing, they have various kinds of software. You could use and I'm not trying to say that to scare you, but just to get you interested, this is a carer, right? You could have a life, a carer, you know, being a quality assurance engineer. It's not something that's just a passive, you know, it's just like same thing, no. A lot of companies that have QA engineers, based on the company, your role could be different, but I think the fundamental is the same, which I'm going to explain to you. I'm going to give you the fundamental of quality assurance engineer, right? So that is the basic of what is going to be similar across all board. Now what can be different from a QA could be the technology, right? So some QAs can say they need a UAT test and I'm going to explain what that is. So they could say, I need an automation tester. I need a tester for this, or even still I need a tester that can test XML. I need a tester that can test this application. So now so you don't have to know everything, right? I don't suggest I'll advise you to know everything because technology is really big, it's really big. So you just need to focus on your own stuff that you need that you wanted to focus on and build your career of it. Maybe you could transition to other things so you could learn other things. You know, but I think that what I'm going to explain to you, I'm going to give you the fundamentals of quality assurance engineer. From there, you can start adding things like, you know, adding software or adding different kinds of scales to your plate, but I mean, in general, I think the role of I mean, the role of quality assurance engineer is to test. You know, so that's I think that's the beginning and genesis to the whole story, like to be able to test application, to to break application to find defects. Because if you are working and they send stuff to your plate and you test and you thumbs up, nothing no error, they're going to look at you like, did you really test this properly, right? So the one you make sure that the testing, we finding defects or like I said error defects, bugs, and how do you go through fixing those errors defects or bogs, right? So these are all the things that is is your responsibility as a quality assurance engineer, slash tester. So we're going to dive a little bit deeper into, you know, what are the artifacts? What are the documents, the Q way you come up with, how do you test? What are different types of testing, you know, all the the rules and responsibility, the day to day task of the quality assurance engineer. 12. Where does QA fit in Agile: So where does QA actually fit in Agile Waterfall SDLC, right? And I think you guys should probably know this answer by now. But, you know, For a QA, you know, like I mentioned your role is actually to test the application, right? So in software development life cycle, and Water Fast lash Agile, you know, where do you guys fall in? You guys fall in under the testing phase, right? So in QA, in the software development life cycle process or waterfall or Agile, you guys are in the testing phase. So when an application is written, you know, based on either business repment document or user storage stuff stuff, the developer develops the application. You are in the testing phase, the testing phase is all about you, right? Before it goes into deployment and maintenance, and in the testing phase, a lot could happen. Like you guys are the leaders, you guys are the boss. You guys are the ones taking the authority. There's so much responsibility. And I'm not saying that to scare you, but to get you prepared or to let you understand what you are going into A that phase, that software. Imagine that whole software that is going to be used by X amount of customers in real life production in real life, at that phase, whatever it is in waterfall or agile. So in waterfall for three, four months, that whole entire application is on you. And I'm not just saying you because the many times you have multiple Q ways, so like four or five Q ways working on a project, right? So you all are responsible for that for that four or five months. So it's a lot on your plate in terms of, people are looking at you, like, you know, if a defect is missed, I mean, it could be an issue like, you know, how come this missed, right? Sometimes, because once you miss it, and the business misses it, I'm going to explain what UAT is, which is the business test, but once you miss a issue and the business misses it and it goes into production and it fails, then they'll be like, the first I'm going to ask this, did the QA test. Right. So I'm not saying to scare you, but I'm saying that this is a big deal. That is why a lot of Q ways make above six figures because of the responsibility of what they have to do. And it's fun, right? It's just, you know, I'm going to show you, you know, how to prepare, how to be more prepared. As a quality assurance engineer, so that most of these mistakes don't happen. You know, you get prepared, you get settled, like, you know, and you do your job well. You know, it's not it's not something that should make you scared or anything, but it's it's a huge responsibility, you know, and it's something that you want to be able to execute because a lot is on your plate, like, there's a lot of obligation on you that you know, once an applic and an application that so many people are going to be using, right? You know, to have that belief that I tested this, right, you'll see it in production, I tested this and it's working. You know, it makes you feel good. It makes your confidence come up like, Okay, I worked on this, right? And it could go positive or negative. So I want to prepare you to sense where when you get to that place, you do a good job and, you know, your boss is happy, you know, company is happy, you know, that you had a successful software in production. 13. Types of Testing: So on this video, we're going to talk about types of testing, right? So there are various kinds of testing. So what I mean, various kinds of testing is like what are you actually testing, right? So I'm going to talk about as many types of testing in this course, you know, break every type of testing down. So, In this as a QA, you know, the and I'm not saying that you have to be responsible or you should know all or be able to perform all the various kinds of testing because like I said, QA is big, you know, you should just need to focus on few kinds of testing. But I'm going to explain all most of it. And I'm going to explain the ones that you should be able to know, you know, to do your job and have a career, right? Because there's a lot of kinds of testing, but the ones for equality as the typical types of tests that once they hire a QA should be able to perform. Right. But sometimes other kinds of testing can be more complex and stuff like that and require some certain kind of skill to execute and those and things like that. But I'm going to I'm going to explain those as well, but I will also tell you which one that you need to focus on to have a carrier, if you're coming into QA, if it's something that you have a little experience and you want to, like, be able to learn no stuff to be able to get a job and do your job before you start improve increasing your knowledge. So I'm going to explain all the various kinds of testing and the one that I feel like you should focus on. 14. Functional Testing: So the first kind of testing and the most important kind of testing is functional testing. So what is functional testing? I mean, functional testing is all what I have been mentioned testing the functions of the application or the software. So I'm going to go back to the Walmart example. So when I said, you want to develop they want to develop an application from scratch to finish. And for example, they want to check test the logging screen, you can add things to your card, you could check out and all those things. All those are functions of the application, what the application is supposed to do or what an application is supposed to perform, right. So the function is typically like, ok, can I enter username password and submit? That's a function, right? Can I add stuff to my car? That's a function. Can I check out of an application? That's a function, right? So all these is functions of an application. So that is actually The I won't use any specific percent, but that's majority of the role of equality assurance engineer. Testing the application function. And I'm going to explain to you how do you test that? I mean, for you to test that you have to prepare to test those functionalities, right? But the functional testing is majority or work of quality assurance engineer. Testing the function of an application. Now, application could be very complex, right? We have various other kinds of testing which I'm going to explain. But the long story short is functional testing is is very important for a quality assurance engineer to be able to perform. So I'm going to show you how to perform or how to test 15. Blackbox Testing: So our second type of testing is Black Box. So what is Black Box testing? Black Book testing is same thing as functional testings. I'm not going to dive too much into this, but Black Box is also another term they call for functional testing. So exactly the same thing test the functions of an application, you know, the functionality and those things. So you could actually you could use Black Box black box testing or functional testing, same thing. 16. Whitebox Testing: So the next kind of testing is white box testing. So white bus testing is mostly testing done by the developers, so the Q waves are not responsible for doing that testing. So what is white bus testing? White box testing is testing the code of the code of the application. So let's say the developer develops an application writes the code. Usually they could have another developer test that code, right? So you want to test that code for certain reasons. You want to see you use the right kind of code, right? You use the code is up to standard. So basically, as a Q way, you are testing the functions, right. You're not going to depend or you're not going to look at the codes and test no. You're actually like testing the front end. So when I'm in front end is like the application, right, you are doing manual testing. So like this course is manual testing. So you're actually entering the user name, you're entering the password, you're clicking some mix. White box testing is you are testing the developer is actually testing the code itself, right? So all those S sharp and java scripts, and all those things, like the developer is actually testing those codes. So they do that before they send it to QA. So I white box testing is also what you call unit testing. So you're going to use that I mean, they don't really use white box testing, you call it unit testing. So unit testing is a must, right, the developers always do unit testing. So once the developer develops the application, the death team do their own unit test. So they test the application, the test the code, right, that they use in writing the application. Once that code is okay, then they send it down to the QA to perform your functional testing or your black box testing or things like that, so all the kind of testing. But initially, like when the developer you know, write the code like they do their own unit testing or white box testing to test, specific like making sure the application is up to standard and things like that. Then they I'll send it to the QA U that will not perform your other kind of testing. And I'm going to explain you know more in detail, what other kinds of testing that you particularly will be responsible for. Why mentioned unit testing was because, you know, it is a type of testing, right? And it's something that comes up all the time, you're going to be hearing all the time, like you're probably like, okay, what is unit testing? What's white box testing. So this is what unit testing is. You are not responsible for that. The deaf team is responsible for that. But it is a facts a kind of test in SDLC, like you know, a lot of companies, like a lot of developers have to do unit testing to test the application. So I'm not going to speak too much on this because it's mostly for the death team that perform that, they know how to do it. It's mostly testing the codes. You know, it's very complex in terms of testing the features. So you're not actually any responsible. We just want to make sure that it has been done. I mean, take your responsibility to make sure, but they will tell you that and we've done the unit testing and everything is whatever and they send it down to you to start doing your own type of testing. So functional testing, black bus testing, that's solely responsible on you. 17. Adhoc Testing: Adult testing is kind of random is random, right? So I I mentioned in Q way, like, everything has to be organized, you know, but when you're doing adult testing, that allows you to just, you know, just be random, you know, many times, that is not your that's not the bulk of your testing. You know, that is not where you strategize the most in your testing. Where you strategize most is your functional testing, your to N testing, black bus, UAT, you know, adduct is just, you know, towards the end. You could just go through everything and see that everything is working. So that's what add. That's what adduct testing is, you know, and that is also the responsibility of a QA. So the QA is also responsible for performing adduct testing. So when does adduct come in place, many a times is where most of all the like the functional testing, the black bus testing has been done, N to N testing has been done, regression testing has been done. Then you do adduct testing just to make sure, before you give your ums of that everything is done, everything is working properly. 18. Regression Testing: Another kind of testing is regression testing. So regression testing, this is another very important kind of testing, right? So what is regression testing? So regression testing is once an application has been tested. So once you've done your functional testing, you've done functional or black bust testing, you've done your N to N testing, you find defects, right? When you find defects, I'm going to explain to you now how the defect process or the defect life cycle works. So you know, when you test an application, you find a defect right now. I then depends, what kind of defect is it? Is a high priority, low priority, medium, low. So high priority is something that is determined by the business analysis with the direction of the business. So if you cannot log into an application, if a user cannot log into an application, The business has said that login page is high priority. Remember when I say the Aj, like, they want to work on this face first. So if they want to work on this face first, you know that that's high priority. Now if you find a defect in that, you know that if you enter the username and password and click the summit, you cannot log in. Then you know that that is high priority because that's stopping the customer from logging into the system. So that is high priority. Any issue you find, like if the submit button is not working, or the password case sensitivity, or longer long characters, those are high priority defects, and those has to be fixed. So once you find that, right, there's a defect there's a wheel of entry in defect, right. So I'm going to show you some of the artifacts or the documents of a defect report. So what a defect or an error is supposed to comprise of. So it's kind of like the defect ID, the description. So the description talks about what the error you're facing, right? The description can be when I click the summit button, nothing happens, right? That's a description, then it's also going to come with the actual unexpected steps. So the actual steps is, you know, what is actually happening. So when you click on the summit button, nothing happens. What is the expected result? The expected results that when I click the summit button, is supposed to log the customer in, right? Also, you can act at the send screenshot. So screenshot is like pictures of what you're saying. And also steps to reproduce because if you just send it to the developer that ok, this is a defect, this is an error that I'm facing. The pass this I click the summit button is not going. The developer is working on so many things, right? So to save time, you want to put steps to reproduce. So steps to reproduce or what I mean steps to reproduce is, what did you do? To get to that arrow, right? So I first entered the user name. I first second I enter password, T thought I clicked summit, and I and when I click summit, nothing happened. So those are the steps you took. So you have to include all this in the defect report. And I'm going to show you like, you know, document of high defect report looks like, you know, but this is just the lungs just saw how like a defect this is what a defect is and how you document it. So once you do that, you send it to the developer, the developer, take picks up the defect, changes the status to open, right? So once you send it to the developer is new, the status is new. Every defect has the status and the pus, so it's parity high status new. The developer picks it, changes the status to open, works on it. When it works on it, it sends it back to you. So once you Once you create a defect, you have to assign it to whoever developer is going to be working on it. So there are different tools, of how you enter defect. You can use Excel, you can use software tools. You know, I'm going to show you I'm going to explain some of the tools that are out there I mean, based on what the company is using, the company will provide you the tool. So once you have to always have a someone, you're going to assign it to the developer, whoever is going to be working on that defect, you assign it entering the steps, defect, I description actual results, expected results, sprintsht, other things. When you send it to him in srtus of new, he's going to open it change the status to open, work on it when it works in it, you send it back to you. When he sensor back to you is going to be fixed. Then what you have to do is once he sensor back to you, you have to go back and retest that functionality. So once it sensor back to you as fixed, you go back to the application. What he means is that he has actually gone to the application itself in dev environment. I'm not talking about life in production. The application in deve environment, and he has gone to fix that summit button. So remember all this application is being hosted in the Dave environment, right? So now he goes in, fix that submit button that in a way that, if you enter in the username password and click submit, right? I should take you he should log the person, the customer in. You should log the customer in, right? So he has fixed it. So that what the defect is telling when he sends it back to you as fix. He's saying that ok, go to the application. Enter in the user name password, click submit and is should log the customer in. So that's what that defect saying that's fixed. So now for you, what you suppose what I'm going to do is you're going to go to the application, enter in the user name password, click summit, once it logs you in, then that defect has been passed. That's what they call pass. So you change that stars from fixed to pass. Now, if, for example, remember when you're testing, you're not just going to test username password summit the summit is working and that's passed, no. They're going to also test now because sometimes when the developer fixes that summit, something else might break. I mean something else my big name another error sword. So you have to test around that feature. You're not just going to go to test the user namessord and click that summit button is fixed. You're also going to test, if I enter the user name, if I enter in the wrong password and I click submit. What if I enter no username password, click submit. Is it going to give me the right error? Maybe n, the summit button is now working, but something has broken the error. So when you click user name, wrong password summit, the error message I'm getting is now wrong. That's another issue, right? So you have to test around that future. You know, so once everything is fixed, you change that defect from fixed to past. So when the defect is passed, then that defect is closed. You know, so you change the status from pass and the change and the status, you can put it as past or you can put it as closed. So once it's passed or closed, that means that defect is done there, like if is loved in. There's the say the people can go and see it, but when you see the status as closed, that means that issue has been closed. So that's what it is. So what I'm saying this is because it brings me down to regression testing. So regression testing now is Once you done all the whole testing and found defects, and the developer send you defects and you fixed it and he has fixed it and, you know, I say you send the developer defects, he has fixed it, he sends it back to you retest other whole back and forth, right. I remember keep in mind, as a Q way, you're going to be having this back and forth with the developer like. Your testing things are failing errors, you're logging you're logging defects, he's fixing it he's sending it back to you, you're testing that whole back and forth. So once you've done all that and I mean, initially, it's going to the defect will increase, will be huge. But you gear keep working, the defects are reducing. So because now it is like he's fixing is fixing, is fixing, is fixing, you are retesting, it fixing, you're closing, you're closing. So once it gets to the end was like, okay, you can't find any more defects. You know, the application is working, you do a regression testing. So regression testing is now what what regression testing is basically they're testing the legacy system vs and the new functionality. So for example, now, a application can see the website less the one mount of com, right? They want to develop an application, but now this is not a brand application. Maybe the application is already existing, but they want to change the logging fature. So the logging feature is maybe they want to change something there. Maybe they want to add two factor authentication, right? But the whole application still exists. So what regression testing is about is that once the developer develops the logging functionality, right and pushes it to your end. They're going to test the second factor two factor aterication. They're going to test the logging feature. You're also going to test the entire application That's what they call regression testing. So you test what he has developed, and you now test the entire application of what they call legacy system. So you test if if it changes x y, and he pushes it. You're going to test A to Z. No. You're going to test S Y, X and Y. I also going to test A to z. So you're going to test everything. So that kind of testing is called regression testing, and that happens after functional testing or regression testing, but before you waiting. So functional testing, black bus testing, you're texting only x y, right? You're only testing the things that he developed. Those two features that he developed. But regression is you're testing X Y, and you're also testing A to Z. You're testing everything, the whole application, whether the ones he did not touch or anything, you're going to test it. And you're also going to test the one that he he updated or he changed. You know, you're going to test that too. So that's what you call regression testing. So this happens. Functional testing in this scenario, you're testing X Y, black bus sing. Then you do regression testing, so they test X Y and Z. Then after doing that, you now do your adc testing to test randomly. Once you do that, I mean, not even before you do random testing, you do end to end. So you do after you do functional, you do black box, then you do end to end. After you do end to end, then you do regression, after you do regression, then you now do UAT. So UAT is the one that once you've done your regression, you can now do sorry adc. When you do ad hoc, you can send it to the business to do the U waiting. So U wait is the last kind of test. That's when you've done your whole testing, then you send it to the business for them to do the U waiting. So remember, functional testing of black box, then you do end to end, then you do regression regression, then you do ad hoc, then you can send it to the business for them to do U waiting. So These are the most for the testing that you perform as a quality assurance testing. I'm going to speak more about different other kinds of testing, and it's going to be more complex kind of testing, which is mostly for specific. Many of time, people that do this kind of testing are mostly people that they're bringing for this specific kind of purpose. It's not something that they will tell you, you also do you need to do this kind of testing, people that are designed or people that are responsible for this particular kinds of testing and I'm going to explain that to you in the next 19. End to End Testing: N to intestine. So what is N to intestine? N to intestine is most times this is done at the end of the functional testing, right? So let's say a function testing can be, you know, test the login page, user name, password, submit. That's a functional testing. You know, test an application. You can put a product in the CAT, that's functional testing. Test customer can check out, you can check out of your cT using your payment method, your preferred payment method, that's functional testing. So N to testing is testing, from the beginning, from when a user or a customer logs in with their user name and password to when they check out of the application using their preferred payment of methods. So you're going to mimic, you're going to run a scenario way, a user comes in, enters the user name password summit goes to the application, enters like picks a couple of item puts it on the card. Goes to check out, pays and checks out and they get an e mail confirmation, that's a full end to n testing. So many of times it's like it's done towards the end, if it's an agile, right, agile like it's done in phases, right? So once all the whole phases have been completed, you want to perform an end to end testing. So from the beginning to the end, because think about it, like in realize scenario. Customers are going to do are going to do that. Like, they're going to log in. They're going to add items to the cap. They're going to check out. They're going to check their e mail for an e mail confirmation. They're going to do all that. They might not do it immediately. Maybe they might log in for us, you know, do some shopping, ad stuff to the cp, the motu, all those things. Then eventually maybe put it in their wait list or something like that, before the days time or stuff like that, they can come to check out, but they did perform all those scenarios for them to actually have a complete cycle, right, for them to for for for a transaction to happen. They eventually they had to log in at some point. They have to add items to their acc. They had to check out, and they actually went to their e mail to send e mail confirmation. So they actually did all this. So to testing is verifying that you are able to do log in, add items to your cp, you know, check out and check e mail confirmation confirmation. So that's what I called an to intestine. So in water for, it's easy because like I mentioned, everything is developed immediately tested immediately. So it's easier for you to do to intestine, right there. So once you do your functional testing and black box testing, you could just do an to testine, you know, to test everything. So I'm also going to explain to you how to prepare to do an to intestine. But I'm just like explaining what an to intestine is. So later down, the course, I'll show you how to prepare or how to perform n to n testing, how to perform functional testing, black bus testing and all of this, right. But I'm just kind of explaining to you what they are, all the types of testings. Remember I mentioned about functional testing. So functional testing is just mostly testing a scenario, right? So just username password summit, you know, like a login page, you know, testing that a the the partial characters are working. That's functional testing. Enter testing is also functions to as well. It's functions, but it's a different purpose, right to functional testing, you testing the scenario. You testing Can you add item to your calve? Can you check out, you know, just functions, functions. Enter these, you are testing multiple functions at once. Multiple functions like a whole cycle. You are testing from the beginning to the end. So functional test is just one function, two function. Ones is multiple functions at once. You know, just make sure that a complete transaction or a complete cycle can take place. So that's what they call to Ns. 20. User Acceptance Testing: Yeah, user acceptance testing. So this is very important. This is a big one because user acceptance testing is something that also takes place. Like in as much as I mentioned for quality assurance, like functional testing is top priority. That's the number one type of testing the QA should perform. User acceptance testing stopped there. And many a times the QA can perform user acceptance testing or a business, the business can perform user acceptance testing. Remember when I spent with the businesses, so the businesses, mostly like the stakeholders, right? Managers say I give an example, manager in Walmart, right? They have the team. It's not the manager that will actually go on test it, but it could be maybe people that customer service or people that are actually going to be interacting with that not the customers themselves, but, you know, maybe people that like, are employees of Walmart, you know, they might be the ones to like, go out and look at the application. So when does that happen? When does this user acceptance test or what we call UAT UAT, user acceptance test? When does this happen? So remember when the application has come to your face, like for you to do the QA testing or the SDLC life cycle. So once you've done, like your functional testing, black box, you know, all these kinds of testing to N testing, I mean, you giving your ms of that. I'm still going to explain more kinds of testing, but you've done all the whole kinds of testing that you need to test right on the application. You reach out to the BA, that's in water in Agile or the PO in water in I mean, the BA in Waterfall or the PO in Agile. I say Okay, this has been tested, right? So now they will take the application and hand it over or the BA or the PO will take their own testing, right? They will they just do it quick, like, just check the functionality. If everything looks good, they will send it to the business for the business to conduct their own testing. So the business will have their own team that would do their own internal testing. So it's not like the public doing the testing. They have their own team, people in working like the stakeholders, right? They are the ones that would get their own team to test the application. Now, how would they perform that kind of testing? So your testing, your testing as a QA, you functional testing is more thorough, right? We test the application, from a technology perspective, like you're testing to break the application to find defects. UD testing is mostly like soft soft testing, just go through like this I mean features like just to check like most they're doing the positive part, right? So you're doing can I log in? Can I ask to my card? Can I check out, you know, this like that? You are testing from to break the application. So if for example, a checkout can say, I want to use these kinds of cards to pay. They're going to use invalid cars that the application doesn't even accept to see if it's going to give you an error, and if it gives you an error, what kind of error. So those are the kind of things you need to be checking out for. So that's so in UAT, they're just going to check the positive part. So they're going to check the logging page, you know, the check in. Can I add salt to the card? Can I, you know, check out, you know, I you know, all those kind of things like the what we call positive parts. But in QA, you are testing the positive and the negative, you're testing everything. You know, yours is more thorough, and it takes longer. You know, but UA is quicker, and they have their own team and they just, you know, just check most of the things, you know, so many times, you can miss a defect, and the business co miss a defect because yours should be more thorough. So if you missed it, most likely the BS might miss it. But again, the BA not the BS, but the business have more knowledge, right? This is something that they've been doing, right? This is something that, you know, they're more knowledgeable about the product. So they might actually have ways of how they can test it better to understand that because they have better understanding. So, for example, business person like the stakeholder in Walmart, has a lot of knowledge about they know how they use the application, how the customers interact with the application. They know how the customer what places the customers go to, how they use their. So you're going to do those scenarios, right? So you're going to test based on the customer what kind of things that the customer do. And it's always a red flag when the business finds the defect that you missed, right? So if you test the application, you see, you found the defect, you fixed it everything. You give the terms of and the send it to the business, and the business finds the defect. It's not a good look on your end because it shows that you didn't do your work properly. So many of times you want to pit out, Okay, you found all the defects, you fixed it. Now, that's what we call known issues. Known issues are like minority, minor issues, right? So example, you could look you can find a defect and error ware, you click you enter the username password, you click the summit and it doesn't take anywhere. The summit button don't work. That's a big Error. That's why we call a huge defect. And you prioritize those defect. I'm going to talk about prioritization and all those things. But that's a huge deal, right? That has to be fixed, like it has to be fixed before it gets in the business. So but there are issues where maybe the look and feel of the application maybe the summit, I mean, like, you know, the graphics and things like that. There are minor issues, right. That's what we call known issues like you know of those things because it doesn't match with what was in the requirement or the s of story. These are known issues, but it's okay, right? Because an application cannot be 100% tested, it cannot be 100% defect or error free. You know, is impossible, right? There's still going to be issues. But those issues are stuff that okay, can the customers still use the application with the few issues. If that's a yes, then those are small issues, right? And no issues that you have to let the business know that, okay, this is what I found, right? The are the known issues that ol slight errors here and there. Known, so they are known. The business analysts will be aware about this issue. So you speak with the business analysts that this is these are the known issues, right? Then the business analysts or the PO will take it to the business that okay, test the application, but while you're testing the application for UAT, these are the known issues, right? These are the issues that low priority. It's not a big deal, things like that. So when the business is testing, the business have it in mind that, okay, these are the known issues that the business, the BA, or the PO brought to my attention, but we're going to test for major things. So the major things are big defects that should be that should be should not be known. So if an issue, like for example, like I mentioned, the user name pass for the summit is not working from the any business finds it is a bad luck on you because like, how come, you didn't pick this up, and I'm not trying to send out to scare you, but I'm just trying to retro that. This is this career is a big deal. It's not that's why many times people end about six figures because it's a lot of responsibility in here and this is something that cost millions of dollars, these applications cost millions of dollars and you don't want to put an application out, they're spending this amount of money and you know, it's breaking or it's failing, you know, so you want to make sure that when you're coming in, like, you're actually taking your time to test properly and do everything well because you cannot just do any slide work and thing that you're push it out to production no. You know, you have to properly test. You have to be real professional in testing the application. So I'm going to speak more about so just this is UAT. I'm going to talk more about other kinds of testing. And this UAT is the business that actually test this application, so they are the ones that, you know, are responsible, solely responsible, but as I can also mentioned, the QAs can also come in as well. So the QAs can also have seen QAs perform td testing too. And when you did perform ate testing, they perform it alongside with the business. So once they're done they're given in their terms of and everything they've done the functional black box, to end testing, all those kinds of testing, they will coordinate with the business analyst or the product owner to perform and with the business to perform the UAT. So sometimes you could support the business in performing UAT alongside with them. But many times it's always the business doing the UAT. 21. Automation Testing: So what I was saying earlier on was like all the whole kinds of testing. So this kind of testing is what we call automation testing. So automation testing is huge because this is where testing is going towards right now. So a lot of testers, I mean, manual testing will never go away. There's always going to be opportunities for a manual tester. But if you want to like increase your knowledge, increase your your dollar amount, like if you making more money, automation, it's kind of like the next thing. So when Q first started, it was manual testing. But as time went by, or the started going going automation and a lot of companies have started adopting automation and start hiring automation testers because it's cheaper, right? Something that five manual testers will do only one automation tester can do everything, what five testers would do. So why would they hire five testers when one automation guy can do everything. And again, manor testing is still going to be relevant. So don't think that okay, if you know about manor testing means I have to go automation to make money. No. Even with manor testing, you could still have a career. But automation is actually the way in the next is the future. And what is automation testing? Automation testing is scripting. So scripting is basically the tools, that are designed for you to be able to do scripting. So automation testing, you can actually do remember when I talked about functional testing, regression testing. All these can be done using automation. Automation is kind of like when I say scripting, is like writing codes. For example, when you say mano testing typically is enter, you go on the application walmart.com, going into login page, enter username password submit, take you to the next screen. With automation, you don't have to manually enter Walmart URL, enter username, enter password, enter submit. You write scripts, you write function code functions on the on the tool, the automation tool that we'll interact with the Walmart website and go to the Walmart website and do those functions. So for example, you'll write a script on the tool. I'm going to tell you some tools that you can use to do automation. You write a script on the tool. And and that tool will interact with Walmart's website and we'll go there what the Walmart URL, enter the username, enter the password, and clicks from it all on its own. You're not going to do anything. So he's going to do it and send you the result. If it takes you to the log if it goes past the logging page, you can tell you that this has passed. If it fails, it will also give you an error. So you don't even have to be there. Sometimes you could rot automation script overnight. And write so many functions. You to test the login page, to test, check the cards. You can get things and you can add things to the card, you can remove things from the cp. You can check the checkout. You can check confirm that you are getting e mails, confirmation e mails to your e mail address. You could test all that. So you just need to program it. You just need to write all the whole scripts, let it run. So now you see what I'm saying that is robust Sad of you doing all these testing training scenarios. You could just write some fuel scripts and allow the automation do it. And many a times they do it because for example, instead of you many a times applications are always built from scratch. They are built from maybe they added fuel functionalities to rate. Now, why would I hire someone that's going to manually test 400 scenarios in doing regression testing, right? I remember me I said you changed x y, so the two factors tication, and you have to test to z. But will I hire someone that is going to take six months to test X Y and A to Z for regression testing. When I already have scripts in automation, where I already have the code to test A to z. So the only thing that has changed is X Y. So yes, I can have minor testing Mal test I do X Y, but I can see write scripts, I can do X Y, but a A to Z, I already have a repository. So where they store all these codes, is what they call the a repository. Repository is like where all those commands are written. So let's go to the repository, pick all those commands and run it. So I don't need to start having someone write all those scripts and start testing every write all those functions and start testing it manually. When I can just pull pull all those scripts that are in the repository and run everything without even like and it's like running to a nice. I can have one person just do the whole regression. Automation is very good for regression. Very good because a lot of companies are founded that is cheaper because regression like I mentioned, is when you're testing the legacy system, you are testing the old feature plus a new future. So with automation, the old feature you already have scripts for it. They've already done it in the past. So it's already sitting in the represent. So you just pick it up. And run it. That's like that way they don't need to hire too many people because in manor testing, if you're going to do minor testing for regression, you have to hire people to test all the whole old functionality and the new functionality. But with automation, the old functionality is the scripts are already there. So you just need to just pull it out from the repository and run it and only one person can do it. So that's why Automation is mostly good for regression. You can also do functional testing with automation, but, you know, a lot of companies have stay going into automation. I mean, if I mean, it requires a lot of scripting, like it's not as complex as developers, but it's also like writing codes, right? It's not going to be like writing hard codes. So it's kind of like scripting like um Some of description can involve like C sharp, Java, java scripts, and other things. So if you are comfortable in those, you know, I think that if you think you can lend Java and C sharp and things like that, I mean, go for it because that will increase the dollar, that will, you know, make you more sort of more in demand, you know, get job quicker, you know, because a lot of companies require or not require the X for automation testers. But man is always going to be there you always going to see mano testers, like you could have a carrier. If you want to have a six figo carrier, being a manual tester, you can as well. But automation is those ones go quick, like the higher, they are more sought after, you know, because they are more past because the automation tester can also do manual and can also do automation. But a manual tester can do automation can only do manual. So that's why people companies prefer automation testing. 22. Performance Testing: The final kind of testing I'm going to be explaining is performance testing or low testing. Performance testing or low testing has to be done with automation. So when I mean automation. Automation test, they do functional testing, regression, but load testing or performance testing. Has to be done with automation using automation tools because how you do load up or performance testing has to do with using an automation tool and that is mostly I mean, the QA does it, but it's not going to be your responsibility, right? Because once you come in, you're mostly doing responsible for like the manner testing. I mean, functional testing, black bus, regression, you know, supporting the business with UAT ad hoc. But they have specific people that they hire to perform load testing. So you see people you can see job person that say, I want to performance testing. You know, they are people that they hire specifically to perform performance testing. So it's not something that is a Q wage responsibility to perform that. But at the same time, when they say, I want a performance tester, those are still quality assurance engineers, or quality assurance analysts or testers as well. You know, they're still we are testers, like, you know, it's all testing, but that role, performance testing is specifically designed for a specific kind of purpose and there are people that are specialized in that specific kind of field. So what is performance testing or load testing? So performance testing or load testing is testing the stress level of an application. So what I mean stress tp is, like, for example, I'll use Walmart site again. When you go to walmart.com, right? You know how many people use Walmart at a certain time. So let's say for maybe a certain hour. You can have over 5,000 people using Walmart. And those 5,000 users are all doing different things. Some are logging in, some are adding stuff to their ct. Some are checking out. So all these scenarios. So that's responsibility of a performance tester. He's going to be or the person is going to be responsible for testing These whole scenarios to see if 5,000 people can come on the application at once. Four people, maybe 1,000 is on the login page. 2000 is adding stuff to the card back and forth, removing stop adding, removing stop adding. 2000 is checking out, entering their card information, checking out, 1,000 is checking their e mails for e mail confirmation. He's going to like there is a two to automation because you cannot get 1,000 people, 1,000 minor testers adding logging in or, you know, this where automation comes in, the tool. So they're going to create virtual users. What they call virtual users is fake users, is a way this is a startup how to do it, create virtual users, maybe 5,000 virtual users hitting that application at the same time to see if it's going to break because if it breaks, that means if the application goes into production, if up to 5,000 people are accessing the application at the same time, the application is going to be down. And I'm sure you probably heard when you say sometimes when a lot of people users are using the application, the application is slow or it could fail. So this is what they do load testing or performance testing to prevent something like this. That way, when you have a lot of people using the application, the application doesn't break, you know, or it doesn't slow down. So this is what they do performance testing or automation testing or load testing to prevent things like happening in production because once they're taken in production, I mean, Walmart already has an idea of how many users use the application. They have the range, right? So they're going to the load tester or the performer tester is going to mimic that scenario. He's going to put the same amount not the same amount, but above the same range of people on the application to see if the application is going to break or how the application is going to perform. So based on that, then you will determine whether the application is good or not. So remember, you've done your functional testing, you know, black box, user regression testing, en testing. All these kinds of testing occur functional testing, right? What he's doing is called non functional testing. Remember when you always use the stem. Non functional and functional testing. So Functional testing are the ones I mentioned, even though still, I mean, talked about usual test, sal spance testing, regression testing, all those things. Even though to test, even though I si see functional is different, but they're still see classified on that functional because the stuff that you can enter in us pass so to test, we're still entering userm password, but you are going through different phases, right? So Different you're hitting different scenarios. Is setance testing, regression tests, everything is all functional to an extent, right Because you are testing functions. Non functional is not is when it's a non function, that's what we mean performance because you're not just it's not a function, right? It's not like a test you engine user in password. Function is the nonfunctional, I can't test the performance. So if X amount of people are using it at at a given amount of time, how would the system perform? That's how you tify? That's why you call it non functional because you're testing the stress level. They're testing a whole bunch of things like, you know, you know, how many people can you use, you know, on the login page, what is the capacity for that and things like that. So other css what they call non functional and the tools that they use to perform holidays. So at the end of the course, I'm going to show you all the tools are how there for Q ways, you know, both testing functional testing, in doing a functional testing and non functional testing. What are the tools, even automation, if you're also interested in automation, what kind of tools you can use, you know, to perform automation. 23. Types of Artifacts: So in this video, we're going to talk about artifacts or documents from testing. When a QA U a performing testing. There are different documents based on the stages of testing that you'll be responsible for, right? So documents. So when you actually before you start to test, there's some documents that you're required to have, wire testing, there's some documents are required to produce. After you've done testing, there's some documents you're required to produce and every document has its propose or what we served in that process. So I'm going to explain to you all the different kinds of documents. Now, typical in realize scenario, you don't have to make all those documents. But I want to prepare you in a way that sometimes interview questions you could ask some of questions like that. And also, like when you get into when you're working, you know, you want to know all this, right? So that way, if may mention two out of the remaining documents, you know that. So it could be anything, right? Because once you perform me once you a Q in the company, you have to follow the company standards like this the way they do things in the QA, you know, some might require this, they might require that. So I want to better equip you. So any which way to come, you'll be able to respond. You know, you'll be knowledgeable in that field to be able to add value. So in the next video, I'm going to explain to you the types of documents for QA should have an QA produces and at what stage or which stage the produce before 24. Test Plan Document: A QA produces is a test plan document. So what is the test plan document? So this is not very common. QAs don't necessarily produce test plan documents all the time. I mean, I can count the number of times I produce a test plan documents. And most of the time is mostly is mostly the QA lead. So when I say QA, a step above QA engineers. So QA lead is someone that manages multiple QA testers. So the Q ended many times are the ones that produced this document. But I'm just sharing it so that you are also aware of what a test plan document is. So sometimes it could fall on you to create a test plan document, you know, and what are you going to do in that scenario. So if this scenario happens, you know, I'm going to attach all the artifacts in this video so that you can see all the types of documents that the QA responsible for. But what the test plan document is kind of like talks about the strategy you are going to use in testing, right? So for remember when I said like the Bs business analysis or the PO writes the requirements, gives it to the developer, right, you know, to develop the application, why the application why the developer is developing the application. You are coming up with a test plan document. And keep in mind, a test plan document is mostly popular in a waterfall methodology. So in Agile, we don't necessarily use test plan documents because most of the times everything is broken in phases and things change, right? So you create a test plan document and all of a sudden in phase two, they don't want this. What are you going to do? You have to go back to the test plan to update. But in a waterfall, which was the old approach, your test plan was very common because everything was developed from scratch to finish. So you actually had a strategy in place to cover the whole testing because everything had been tought through in terms of developing the application from scratch to finish, like already the developers already developed the whole application and everything. So everything was like, you know, there was no much change. So in your test plan, you kind of cover the whole scenes. What a test plan document does is the strategy of how you are going to execute your testing. And I'm going to show you how to execute testing. But test plan document is like a plan of how you intend to test the application. So what the test plan comprises of, first talks about the purpose, right? What is the purpose of the document? Well, the purpose of the document, when is the Walmart example is to test the functionality or the website of Walmart. So that's the purpose. You want to test. And next, you talk about the scope, right? What is in scope. So what is in scope is a remember when to talk about the logging page, you want to test the logging page. You want to test, you can add this to your cart. You want to test, you can check out. You want to test, you can get e mails to your you can e mail confirmation to your e mail box. You want to test all that. So that is what the call in scope. What is out of scope could be? You know, the load testing, right? Performance testing, O like they're not like relevant to you. Those things might be out of scope, depending on what you know, what do you get direction from your QA living test or what is out of scope. So Auto scope could be stuff that doesn't pertain to QA testing, what you're all responsible for. So what is in scope is what you're responsible for testing. Like I mentioned, you're going to test the login page, you're going to test, you can atten to your cart, you're going to test, you know, you can check out from your cart, you're going to test, you can e mail confirmation, all those, is what is in scope, right? Also section in test plan is the strategy, right? Let me strategies like how are you going to test all these features? The logging page, things your car, checkout, e mail, confirmation. How are you going to test this? So the logging page, I mean, the strategy could be, what kind of testing are you going to employ? What kind of testing are you going to develop? So you going to do functional testing, regression testing, user tests testing, black bus testing, and all those kind of things and who is going to do it. So sometimes like I mentioned, UAT is mostly done by the business. So it could be the business that's going to do UAT. So you mentioned that, you know, in the strategy. It could be functional test is going to be done by you or where the QA test that is. You mentioned that. You know, regression testing is going to be done by you or the QAs or how many QAs? You mentioned that, you know, all those things are kind of things like you're going to mention the types of testing. Also in the section is going to be entry and exit criteria. So entry and exit carteras when the developer sends it to you to test, right? What has to be ready or what are checkboxes that need to be made for you to pick it up from the developer says the bonus are testing. So some of the ideas could be he has done his unit testing, right. Remember, I talk about unit testing. Also one of the feature that you want to check that has unit testing been performed. Also the environment, right? Do we have a stable environment? Rmember, when to say sometimes what the environment you testing or the application is developed is different from the application and production. So you want to make sure that you have a stable environment. Sometimes the deaf and the QA share the same environment. Sometimes the deaf can have their own environment, the Q can have their own environment. So all these entry criterias are going to be before I start testing, the environment has to be ready, unit testing has to be ready. And I also missed another kind of testing and what we call smoke testing. Smoke testing is Many times, it's very popular in interview questions, the as word smoke testing. Smoke testing is before the developer when the developer sends it to you and you pick it up to start testing. What smoke testing is is the same thing as random like ad hoc, but he did don't call it ad hoc. Smoke testing is you just look and fill up the application before you start testing. So you want to check, okay, if he says he has a log in page. Am I see the logging page? If he says he has a add stuff to the check check it add suf to the ct. Can I see that? If he says he's going to have checkout. Can I see it e mail confirmation I smoke test is like, visibility like, you can still run some functions, but this is what is very high level. It's not detail, you're not running positive or negative, it's not complex. It's just ok, what the deaf said he was going to develop, did he develop it. So you just looking at it just running through things, then you know that that's smoke test. These are like entry criteria for smoke like entry criteria. These are things that you need to have in place before you can start doing the testing. All this is going to be pushed, is going to be beld in the test plan documents. Ather thing is exit criteria, it criterias. Before I give my thumbs up, what are the things that need to be done? Obviously, you must have performed the whole testing. Obviously, defects that I found should have been fixed, right? So criteria could be okay, no issues, right. Remember when we talk about no issues. So I have maybe three issues that are low priority. Remember I told you that an application can never be defect free, can never be error free. But the business and the product owner or the business analysts need to be aware of these known issues. Many times, exit criteria could be okay, there were four known issues and they are low priority. Remember, you cannot give terms up when there's a defect that is a high priority defect or a high priority error. Is impossible. You cannot say you've done everything. You've tested everything when they see high priority defects. So Exit prior is mostly when high priority, medium priority of fix, and maybe now priority is what is remaining because of the cannot still spend X amount of money hiring folks, just for fixing low issues, because they have other things to work on. They're not going to spend so much of their time fixing low issues or working on low issues. High priority, medium priority, yes, has to be found, fixed, close. But low priorities, those are non issues. Exit criteria can be okay, application properly tested, defects fix, low priorities are what is remaining, low priority defects are what is remaining. That's an X criteria. And also milestones. Another section in test plan is milestones. Milestones going to be, ok, I intend to test this application in X amount of time because like I said, time is money, If you sell it to your page, I not going to spend 88 months testing that application. If the business are probably forecast right when they were doing the whole project and and developing the whole application and, you know, not developing but looking at the planning to develop the application. They red saying the project manager has already like determined how long it's going to take for the developers to develop the application test test. So the milestones is going to be, okay, it's going to take this is going to take four months for an application to go to be tested. In the first month, what are you doing? What's the milestone? Are you creating an artifact? Are you creating a document? Are you creating a test plan? Second to third month? Are you sertin up? Are you making sure that, you know, I create what are you doing? So these are the milestones. So from the first month to the fourth month, what is going on, When you are testing when you test the application number, testing can also require multiple cycles. So you could fest you could do the first cycle of testing, find defects, the fix it. You do another cycle of testing, another cycle of testing before you go into regression. Regression is testing, remember I said X Y and Z. You test everything, legacy system everything before you give your tons. So all these has will be developed like accounted for that milestone. So in the first in the four months, what are you going to what is the plan, right? So this is not going to be fall only on you. The QA lid will also get given the direction in terms of okay, this is what the plan is. So I don't want to scare you anything like it's it's not challenging at all, like once you're in the process, you know, you you will see like things, it's a lot of communication, like nothing not everything is falling on your hand on your hands, you know, like for you to go figure out on your own, no, your Qa lid, QA test QA manager, you know, the work with you on this process, you know, I mean if you would create a test plan document, you know, so sometimes you don't create a test plan document, but that's kind of like, you know, high level of what is entails or what consists in a test plan document. And I also attached artifacts. I also attached a document, a test plan sample of what a test plan usually looks like. You know, sometimes it could be more complex, sometimes could be less complex, but I attached, you know, I gave you a sample in the video of what a test plan should look like. Next, we're going to talk about test case documents. 25. Test Case Document: The next kind of document is what they call a test case document. This is actually the most important document for a Qa. Like you always have to create a test case document. There is no Qa there's no testing that is done without a test s document. Now, how do you create a test case document depends? There are tools that you can use to create a test case documents or you could create an Excel sheet. Attached an Excel sheet of how a test case document is created. Now, if you actually happen to have a tool that creates where you can enter your test cases, right, you're still going to follow the same format of what I attached in the Excel sheet, right? This is in creating a test case document, there is there's kind of like a pattern or a method. So actually, I'm going to break it down. So when I say test case document, right? A test case document is comprised of many test cases. So what is a test case? A test case is a situation that shows how you are going to test a particular scenario or a particular requirement or a particular user story. Remember when I said, a user story can say a user story requirement from the BO P can say verify the user a user should have a login page, you have a user ID. A login page, you have a password. A login page should have a submit button, you should able to enter user name password and submit to go to the next page. So these are all requirements. Now, what the test case is is how do you satisfy or how do you test or cover that test case or that user storage. So let's say say a login functionality, right? You enter a user name password click, so me go to the next page. That's what you requirement. Your test case you say, how you are going to verify that you enter the username, password, submit, and go to the next page. So that's what the test case is a test case is satisfying a user story or a requirement. So the requirements, like I said are written by the BAS, the developer is developing it. Now your test case, you are testing, you're not testing, you're not writing, you're not testing based on the application. You are writing your test case against the user story. So you don't even care about what the developer is doing. If the QA, if the develop, if the BA or the PO gives you ten requirements, ten user stories. Remember, we talk about user stories, ten scenarios. The test case should have ten or more test cases. You test case document should have ten or more test cases. Because remember, a scenario can have a positive part and a negative part. So for example, logging test a logging functionality, sing password. Password can be positive positive eight to ten characters. It can also be 11 to 12 characters. It can also be seven to eight so when it says the password in the requirement says the password has to be eight to ten characters, se sensitive. You positive part is, the going to test eight to ten characters se sensitive. Now your negative part can be, they're going to test 11 to 12 characters case sensitive to see if you to give you an error. Because remember when you testing the requirement, it says eight to ten positive and case sensitive. So when you write when you test on application with the password I enter in eight to ten characters case sensitive. You are doing a positive testing. Members the Q I said, you have to break the application, you have to find defects. You cannot find any defects. It's a red flag. So you're going to test ten to 12 to see what will happen. Remember, the criteria is eight to ten, right? You're going to test ten to 12 to see if he's going to break give you an error message. They're going to test seven to eight to see if he's also going to give you an error message. You're also going to test if it's case sensitive, they're going to use lower case, upper case to see if he's going to give you an error. If he gives you an error, I'm going to verify that error is matching what is supposed to be in the requirement. So when you write your test case is, right, you have to factor in every scenario in the user story. So that's what a test case is. A test case is, how do you cover every requirement. If a requirement I say is that you have a user and the requirement is going to tell you what kind of visa name, it could take any visa name, right? So your test case is going to be when I log onto the application, go to the login page, enter this user name. That is the test case. And you comment can say you so have a password. Like I mentioned, the requirement is going to tell you what kind of password, eight to ten characters. So you on your testc say, When I log onto this application, entering user name, I entered this password, eight to ten characters. I also another test you can see, I also entered ten to 11, ten to 12 characters. Another test case can see I enter seven to eight characters. So that's how that is what a test case is. A test case is satisfying the requirements. You are testing against the requirement. So every requirement should have a test case to cover that requirement. Another requirement can say entering the username password, he submit, take it to the login page. Your testc can be okay, enter username password, he submit. When I go to the logging page, what do I see? You know, ci to the logging page. And tsk that's a positive part. You can write a negative part and enter miss user name, enter password, heat submit and you should get an error message. Enter user name, miss password, enter submit, I should get an error message. And the requirement is going to tell you if you get an error message, let's say for example, you enter you don't enter in the user name, you enter in the password, the heat submit. The error message should say user name, user ID is missing. That's an error message. That's going to be the requirement that requirements is that detailed. It's going to there's nothing like figuring out anything, like the developer is not figuring out anything. Everything has been slated had been documented by the business analyst or the PO. When you say if you don't enter and user name enter password that heat summit, you should give it this error messag that's what the requirements is going to see. In your test case, you sho you should write the test case that says, Okay, I'm going to leave user name blank, enter in password, heat summit, I should get an error message. Does the error message match what the requirements or the user story is saying? So if the user story says, user ID is blank, please enter user ID. When you do that scenario, when you run that scenario, when you're writing the test case, you should write the test down. That is what you're supposed to see. You're supposed to see this error mache that says user ID is blank, please enter user ID. Remember, when you're writing when you're doing test case, when you're writing test case, you're not actually testing the application. No. You are preparing to test the application. So you are writing all these scenarios down to cover. Remember, you don't have the application. The application has not been developed, right? So you are looking at the requirement only. So whatever the requirement is saying, we're writing test cases and it's to be difficult because sometimes some companies now have st coming with they call mako. So Mockups is like For example, the login page, how the logging page is supposed to look like. It's not like the application itself, no. A MCO can be like a PDF, like a PDF document that shows you picture of what you use in pars. You can use that to write a test case. You already know how the application is going to look like. Remember, you're not testing, so you are not doing it because there's no point the application coming out. I you're writing your test case against the application. You will never catch any defect or any error. So you're writing your test case not based on the application. You're writing it based on the requirements. R. So whatever the requirements are stated, you write your test case document. With the help of a markup sometimes, the company gives you marker like a PDF. You look at the pictures, you know, and be able to write more to help you write your test cases. Then when the application has been pushed to your to your assigns. Remember when you've done your smoke testing, you've just done the look and feel, you ser the environment is ready. You know, the developer has done the unit testing, he sends it down to you. Then you can now use that test cases. To test the application. Remember when you're reading, you're ready reting test cases like you should have a user ID. You go on the application, entering user ID, yes. You should have a password. You go on the application, enter in password. The requirements, remember your test cases, you should have eight to ten characters case sensitive. You go on the application enter eight to ten characters case sensitive, or if you can also test negative test test cases, right? So you can enter seven to eight. You can enter ten to 12, you know, to see if it's going to give you an error. If it gives an error, are those errors matching, what is on your test case document, on your test case document, you've written that okay, user name password submit. I don't I don't enter user name. I enter password that he submit. It gives me user name is invalid. Enter in user ID. User ID is invalid, enter in user ID. You've written it on your test case document. Now, when you're testing the application, what you what you should be comparing is what's on your test case versus what you're seeing on the application. So whatever you're seeing on the application, you're comparing with your test case documents. Remember, you got your test case from the requirements. But when you are testing the application, you're not comparing with the requirement, you're comparing which what you go down, the test case document. So any application test any scenario running on the application is the guide using your test case to guide you. And test case can be complex you can be a lot depending on what kind of test. Remember, I say functional testing. Black box testing. That's all the username password he submit. N to n testing to. That is also another process like this but it's still the same capturing right you're writing a test case document. A test case document can comprise a functional, regression, user acceptance, end to end, add ho Addo doesn't really use test case documents. He's just randomly, but functional, black box, regression, user acceptance testing, you know, all these all required to be a test case a test case test cases. So you just don't start going on the application and trying things out right? No. You're going to write the test case document test cases. Once you write the test cases, with the help of the test cases, you're now going to use that to test the application. And may attach your test case you comprise of both positive and negative scenario. So not just only positive, but positive and negative. And I also attach a screen a document and attachment to this video of how a test case usually is. Right? So the test case comes up in So what it comprises of is test ID, which is very unique. You know, so it could be 001 or 002. So every test case should have a test ID, which is unique. I should have a test case name. So the test case name could be verify the login once you enter usam password, he submit you go to the login page. So login functionality. You should also have steps, right? So when I go to worm.com, I go to the login page, I enter usa entering password, click submit. You should take it to the next. This is a positive test. You should also have actual and unexpected result. So what actually is what are you seeing? Similar like a different report to, what are you seeing? What is the expect the actual results is what are you seeing Expected results is what the expected results should be. Mm remember, when you're creating the test case document, we haven't yet to use the application. So it doesn't have an expected result yet. Once you now test it on the application, then you enter in the expected result and just see whether a pass or fail. But when you're creating the test case document before you use before the application gets to you when you're just using the mock up of requirement. You could leave the expected result blank. You could leave pass or fail, you don't need to put pass or fill, but the actual result, you already know what the actual result is because not you leave the actual result blank, but you leave the expect you fill in the expected result because you know what you're expecting, right? When you enter using pars submit, you should take it to the login page. So that is the expected result. You don't have the actual result yet because you haven't run the application live. I mean you haven't yet run the application. So you can leave the actual result blank. You can leave the passel field blank, you know, but what you should comprise of is the defect ID. I mean, the test case ID, test description, actual steps, actual results. Expect I'm sorry, expected result. Actual results should be blank. Parsle field should be blank. And I act also attached like a Excel document of what the test case document should look like. Now there are tools. Many attach, they're going to have be writing test case from Excel. Like there are tools that allow you to like it's already like the test case ID, which is already generated on its own for you. Only what you nes need to do is entering the test case name, description, actual results, and things like that. Other things already there. But many at times like they already have tools, there are tools that are out there that allow you to enter test cases. But I mean, there are also the scenarios where you don't have those tools. You have to actually track it on Excel. So what I cents Excel, what are attached on the videos Excel. But you can same logic. Once you know how to write those test case on Excel, even if they have a tool, you can do the same thing. You can reproduce it's all the same thing. So that is about writing test case documental test cases. 26. Test Data: The next artifact we're going to be talking about is test data. What is test data? Test data is data or information that you use to support your test case. A typical example, like I mentioned with the test cases is enter in username, password, head Submit button. Test data means what information are you entering to support your test case? What ID, what data are you using to support your test case. For example, a typical test case could be enter in user name, password head the Submit button. Now, test data is what user name are you entering? What password are you entering. We're going to go back to the example, again, the Walmart example where the password could be eight to ten characters, and when you actually testing the positive path, you're going to create a test data for the parsle where it's going to be eight to ten characters long. That's a positive path. You're also going to create a data, which is going to be seven to eight or six to seven characters long to see if it's going to fail. You're also going to create a data that's going to be 11 to 12 characters long to see if it's going to fail. Based on what the criteria for the password is, you could create test data. It's nothing complex, it could be anything generic, it could be anything that comes to your mind or based on what the requirement is stating. It doesn't have to be a crazy kind of data or anything. It's just something random. Most of these datas are fake or dummy datas. So many a times the developers support you with this data, and if they don't support you, you have to create your own data. Now there's no repository or any tool that you can use to store data. Many times, you store this data on Excel sheets, so you have your own Excel sheet, you create where all your test cases, where all your scenarios, this is on the tool or Excel or any application install your test cases. You could actually fill in your test case, your test data into the test case. So for example, when you're writing your test case, you could cc the requirement could be verified, you can log in. When you write your test case, you could be enter user name password he submits. Your test data can actually be filled into the test case. So you could say enter user name, whatever the name is, John Smith, enter password, whatever the password is, hit the summit button. That's actually another way you could actually create your test case. So you could create a test case with test data in it. Sometimes it could be generic where it's just enter user name ter password it summit. That's a typical standard test case. But you can also enter in the data along with the test case. So you could say enter user name, Charlie, enter password, the information, hit the summit button. So you could fill in your test data into your test case, you know, and also tools, like I mentioned, where you can actually store your test case. So I'm going to explain what kind of tools you could use to create test case to create test case aside from Excel Excel documents. So those tools, you can actually enter your test case and enter in your test data along with your test case, which with your test cases. So test data is very mandatory, you know. When you actually hit testing the system, testing the application, it requires to use data. How are you going to query the database? How are you going to query the application. So when you're actually logging into a system, when you're logging into an application, what user name and password are you entering? You have to enter something, right? So definitely, so you need test data in order to support your test case. Test data is very important now. You don't have to create it all the time. The biologist and for data that will be giving to you to test based on the kind of testing you're performing. There are actually different kinds of Maybe some tests can require maybe this privilege. Maybe this user has access to this. This other user has access to this functionality. I mean, those kind of testings also come up. Those kind of testing will require what kind of data you're also going to get support from the developer in terms of creating this test data. Sometimes if it's complex, if it's a data that requires a specific kind of creation or what maybe you need to create a specific kind of data. You always have support from the developers in creating this data. Sometimes you don't have to do it on your own. But if it's something like, very simple in terms of the just creating a standard user name and password and that I mean, that's something that you can just randomly create anything you want. So what I'm explaining this is that test data is very crucial in supporting your test case, and test data also can determine In terms of creating a test data, that can determine what kind of functionality or what kind of application you're testing. So there might be some sensitive kind of applications or stuff that you have to create a specific kind of test data. So you cannot just create a random test theta. It has to be a test data that can fit the purpose, and all this is going to come from the requirements. It's going to come from the user stories. All these instructions are going to come depending on how you want to create test the aa. 27. Defect report: And the final artifact or document is a defect report. You know, have you mentioned about defects and, you know, what is a defect. You know, just to reiterate a defect is an error, a mistake, you know, a bug. So that's what we call defect. What is a defect report, right? So a defect report is is a document that shows the status or the current situations of your defect or your errors or your bugs. Remember when I told you that when the developer tests the application, I mean, develops the application and sends it to your plate for you to to start testing. You're going to be coming across multiple defects. You're going to be coming across multiple errors. You're going to be finding issues with the application. Is natural. Remember I told you that if you're not finding issues or defects, you're not doing your job. So your job is actually to find defects and break the application. So we're going to be coming across multiple errors, bugs, you know, issues that are not matching requirement and not matching the user story. When you come across this issue, what do you do? That's what we call a defectiad. There's actually a process which I explained earlier in terms of how you address issues, errors or bugs you come across. So typical example, you find an error in the login page, you hit the submit button, it's not going, nothing is working. That's a bug. What kind of bug is it as a high priority because customers won't be able to log into the application for them to update their card and check out on stuff like that. That's a high priority. So I can also explain how a defect a general defect is like what it consists of, right? So the defect ID, the description, steps to reproduce, actual steps, expected results. So all of this, right. So a defect report. Many times, you could use Excel, but I don't really I'm not really fond of Excel because this is a defect report has to be a live document because it's constantly updating constantly going back and forth. But just for the sake of simplicity, I did attach a defect report Excel for you guys to take a look at. But the actually tools that you use in managing defect. A lot of tools that you use entering test cases, managing your test case document and stuff like that. They also have a place where you can actually enter defect and manage defect. I'm going to explain again, the defect or the defect life cycle. When an error is found or when a defect is found, right? You enter it, the defect ID, the description steps to reproduce, expected result, actual results. Screen shot. Screenshots is also very important. Screenshots is what you're seeing. That way, when you send it to the developer because the developer is very busy he wants to see your stuff and be able to point point where the actual stuff is failing. You don't want to start racking your head. Once you send it to the developer, the status is new. The developer picks it, changes the status open, works on it. Sends it back to you as fixed as stars as fixed. Once you pick it up, you retest it. Remember I said when you were re testing a defect, you test across other areas as well. You just don't test that issue. You test multiple things. For example, if this says the summit button is fixed, you also test what if the user ID is missing, the password is there and you hear the summit. You test other parts across that. You don't just test only the summit button. Once you test or is fixed, you change the defect stays to close and that's done. If you're still having an issue, you re open it and send it back to the developer. Many times defects to have comments. If you're actually using a tool, which I'm going to explain the types of tool. If you're actually using a tool, right? There are quiz where you can have enter in comments. And that way you and the developer and also the BA or the PO can be exchanging communication. For example, if you have any issue, maybe you log it, you log the defect in the you assign it to the developer and you want to place a comment on the defect. You could say, you could communicate with the def if you want to say anything. Necessarily, there's actually a defect format, and there's a tool that you use in entry in defects. The same tool is the same tool you use in entering your test case your test cases. So it's all 12. But in the defect section, you create a report. There's actually a template where you click on defect. I everything will populate and you just need to enter in the defect is already generated auto generated. You just enter in the def the name, the description, steps to reproduce arts. Everything is all the template is ready laid out for you. So you just need to enter the information, attach your screenshot and that's it. In that screenshot that template, when you send it to the developer as new There's also where you can enter in comments. I'm saying that is because that's a way for you to communicate with the developer. Sometimes developer can say, Oh, I'm not able to see what the error is, stuff like that. That's the way you can be the developer and also the BA also and PO can also exchange communication for traceability to see what's going on. Once you enter it in, that's how you keep going back and forth. The stars keep changing. So why I attached a document in Excel, is just for you to see how a defect report is. Many times, very few cases where you use an Excel sheet, where to manage. But in case where they don't have a tool, I attached an Excel sheet to s let you see how a defect report usually is in Excel. But generally, there are tools where the same tool using creating a test case is also the same tool using an entry or defect. Defect is also very key in terms of the defect life cycle. You're going to ask you. So that's an interview question the action. Explain to me a defect life cycle. A defect life cycle is basically when you test an application, you find an error, you find a bug or a defect, and how you work on the bug to make sure that from when you open a defect to when the developer picks it send it back to you, you retest, you close, that's a different life cycle. F the life cycle means from when the defect is found to when the defect is closed, what happens in that. It goes from membrane and the one the interger was one here the staus, Sus is very key. The one here when I open the defect, you know, I put the starus as new. Assigned it to the developer. He opened it, put it as open, worked and sent it back to me as fixed staus. I retested it once everything was done, I closed it. So the one here the staus. A deferent life cycle, emphasizes on stars. So how it moves from you to the developer back and forth, you know, back and forth until the defect is closed. When a defect is closed, that is the end of that life cycle, that has been addressed. Many atms like I mentioned, sometimes you could send it back to you, you see having issues, you reopen it, send it back to him, so you keep going back and forth and the staus keep changing. The status is very important and we assign it to Because when the developer is working on it on an application on defect, The only thing he's looking at is the staus. Is this new, then he's going to work on it. If it's close, he doesn't care about it because that's ended. Sus is very key. When you're explaining to your interviewers, Sus in terms of defects, they want to hear the staus, how did it move? What was the sterus? When you opened it, you find a bug, what sterus is it? New. When you send it to them is open, the developer opens it, they send it back to you as fixed, then you work on it, you close it. That's what they call a defect life cycle. That's also very key. That's very key in your role as a quality assurance engineer, how you manage defects. Also with the priorities like every defect, you have a priority, High medium low. I mentioned that high priority, medium priority have to be fixed. They have to be worked on. Remember, also going to explain to your exit criteria in the test plan where you can't have medium or high defects, and you give the terms of that you've done your work. No. Every high and medium defect has to be closed. Low priorities is okay, but they are known issues. Remember, I talked about known issues. You could highlight it to your Q way lead or the BA or the PO, that these are the known issues. For the sake of time, they might not have to fix every defect, because time is money. But the high priority medium priority has to be fixed and has to be closed. Low priority is okay, you could keep that you could let that be because it doesn't affect the customer from doing what they do. High priority medium high and medium are show stoppers. Te are blockers. Those are things that will affect the customer from doing what they want to do. Yeah, so In general, you know, defect reports defects is very crucial in your day to day work. You know, it's very important in terms of how you work as a quality assurance, how you handle your defects, you know, making sure that before you give your thumbs up, you know, you want to make sure that all are actually address the higher medium priority and also who you assign your defects. So every defect, remember when I said when you create, you find the bug or you find an error, and you go to the two and it's actually a section where you say you click on defects, the template or auto generated elderhood information. Who you assign also is very important. Because because whenever you assign that defect to that will determine who is going to work on it. If you assign it to the developer, sometimes there can be a specific kind of developer that is going to work on that defect. When you assign it, you just don't assign it to anybody or you don't assign it at all. There's particular people that we are working with that you need to assign that defect to. All those is kind of like what makes up and actually have a screenshot, I mean, I have a report, a defect report that you can look at to see what is the standard in terms of creating a defect. All this information there are actually going to be auto populated for you to be able to enter in your information and log the defect in. 28. Introduction to tools: Now we've concluded our section in Q. So I've talked about, you know, SDLC, the software development life cycle process, the methodologies, Agile, waterfall, what do quality assurance do what types of testing do they perform? You know, what are the artifacts? Or what are the documents? You know, quality assurance you're supposed to have or make and what process do they make all this? And also, you know, what types of testing again, so kind of like giving an elaboration in terms of what Q way does and where does Q way fit in the SDLC, where do we fits in the phases, both in Agile and Waterfall. So Next video, I'm going to be talking about the tools, you know, what tools do quality assurance do to do their daily day to day activities, and also what are the tools used for, you know, and also how you can get up to speeding, learning those tools. It's nothing complex, very easy to navigate. I'm also going to be talking about various kinds of tools, just only for manual, but also manual and automation as well. So I'll be discussing all that in the next video. 29. Types of tools: For tools, for mano testing, there's a very popular tool. And when I started my career, I used to use the tool a lot. It was called Quality Center ALM. So I'm not able to show you the tool, but you can find you could Google Quality Center AM. It's going to be you'll see the PDF within where you can actually find a Google that tolling. So the tool is actually specifically for quality assurance. You know, this tool is designed solely for quality assurance testing. So, you know, it talks about how to enter in your test cases. So in Quality Center ALM, you can actually go in and create a test case, create a test case is there. You could enter in defects errors. You can use the tool to manage the defect lifecycle process. You could enter in defects and assign it to the developer. The developer also has access to quality center ALM, where they can actually work on those defects and send it back to send the memory about the defect lifecycle process. Quality center ALM is good for managing defects, you know, and also entering test cases, entry manual test cases. So Quality center ALM is for manual testing. You know, I there are actually adding features where you could do some automation as well, but it's solely based for manual testing. Another tool is Jira. So Jira is kind of like the new thing. So that's kind of like the new application or the new tool for for a whole bunch of things. Jira is mostly used for Agile where the PO, scrum masters, and the lights developers, you know, it's a very robust tool. But Quality center and testers can also use Jira as well, but for them to actually access ira theined to get an adding called X ray. X ray is an adding feature to Jira that allows you to write test cases and enter in defect. I think that's actually the new tool out there. Quality center has been B, I mean, it has been there for years. When I started my career, that's all we're using. But now Jira is like taking over like because of agile, Jira is very popular and agile. So I think a lot of companies are navigating towards Jira. You know, and for you to access Jira, you need to plugin called X ray. And I mean in terms of entering test cases, managing defects, the process is all the same. Quality center, Jira, is all the same. Every test case, you have you know, test ID, description, test name, actual expected results, same thing with Polity Center AM and gia. So the document I attached will show you how As case is supposed to be entered, how a defect is supposed to be entered. So even if you're using any tool quality center ALM or Jira, you just need to plug in those information. So it's very much self explanatory when you access the tool, you will see all the information for you to just ate in. So you just need to know what you king, what you're king. So assign, priority, you know, high medium loss, all those things. So it's pretty much standard across the board. Now for automation testing, right, remember when I talked about, that's a new thing. That's where a lot of companies are navigating towards, where the industry is going every industry is going automation because the far like it's cheaper for them, right? So a role or a task that ten Q testers will do. Only two or one automation tester could do everything. So even though manual testing will never go away. So don't be scared like manual testing will never go which is always going to be there, you know, But automation is kind of like if you want more money, if you want to advance your current, if you are good with coding because automation is kind of scripting, there are different languages so you could script on Java, C sharp, and all those things. So if you want to advance your career and get a job quicker, get more money, automation is kind of like the future. But what I ought today was manual, a manual will always be there. There are actually companies that always have manual testers, and you could actually have a livelihood being a manual tester. Don't be scared, manual, I know I'm out of business or I'm out of work. No, you always get a job and a good job. For automation, the two very popular to the selenium. Selenium is a IDE that allows you to script. Selenium interacts with the application with the front end. For example, like the typical example worm.com. You write your scripts on selenium and you link selenium to the Walmart website. Any code you're writing, you're writing your code on selenium. You're writing your scripting on selenium. A Selenium is interacting with the Walmart page to do whatever you want to do. For example, typical example, I just want to test the logging functionality, the user name, password, submit button. I will write I'll program this in selenium. Selenium will talk to Walmart and say, Okay, Walmart, go to the login page, enter the user name, enter this password, enter it the submit button. What do you see? So whatever happens when the user name password and submit is clicked on on the Walmart, Selenium will read that information and display it and send it back to you. So you go on Seleu and you see, this pass. You took me to the neck to the to the log in inform I took me past the log in information access, I have access to the customer account now, or you could say he failed. The password was invalid. You'll see. So it is a very cool tool, you know, and automation is interesting, actually, it's quite interesting, you know, so it's a lot of fun. You know, I think Mana is also very interactive, very analytical. You know, you have to always be thinking outside the box and thinking of ways. But automation is also a very cool future to learn. You know that way, you will never look for a job because in terms of SDLC, in terms of IT, in terms of software development life cycle process, and building an application from scratch to finish. Quality center is as important and relevant as developers because we have to test. You know, everything they they test everything. So not just only application right, even hardwares, you know, aircrafts, cars, are being tested. So when we develop the tested. But what I'm teaching today is on software, applications, soft tools. So those are the things that I'm kind of like talking about, so that's quality assurance testing. But in general, everything has to be tested. Anything that you put out there has to be tested because if you don't test it and there's an issue, they come back and sue you for a lot of money and damages and, you know, high out risk in your lives. So co testing is very important in life. What I'm actually teaching now is software applications, and every application has to be tested. Imagine every quality assurance, there's actually a position or a rule for quality assurance engineers because the application need to be tested. Developers cannot test their work. It is actually is actually saying that it is not proper in the IT world for developers to test their work. Be imagine when you write your code and you test it, of course, you're going to be biased. So that is why they always have an independent people. They always have quality assurance people to actually test their work. So QA is very important. QA is very relevant. They will always need Q ways. I boat manual, automation automation better because an automation can do manual as well. But Manual is also very relevant to, they don't go away. Think about it like this is a good career to actually do because it's not something that you feel like maybe in the next ten years or 15 years is going to go away. No. Q will always be in demand. It has always been in demand for. Since when I started my career over ten, 15 years ago, Q is still in high demand and to always be in high demand. 30. Where the Industry is headed: So in terms of where the industry is heading, I know I talked about SDLC and the whole phases of requirements, development, testing, deployment, maintenance. So that's like the standard, and how he moved from waterfall and went to Agile. Now a lot of companies are going to the Cloud, and a lot of devo DevOx engineering and CICD pipelines and how data is actually stored in the cloud and how people or the application interacts with data and the Cloud. In terms of quality assurance, right, I feel like you should always adopt this mentality of continuous learning. So you just don't redis course and get a job and be like, I'm done, I mean, quality Q engineer. No. It doesn't end there. You always have to keep learning. Industries keep the industry is always changing. New things keep coming up. You have to keep advancing yourself, learning things or less you're going to be out of date. It's like when you actually try to advance yourself, if you're not learning stuff, you're going to be stopped in a hole. And I'm sure you're probably going to be bored out of your head. Always always keep learning. Always keep learning, always keep advancing. You know, I think even though still you still want to remain in let's say you might have a church, you want to remain in manual testing, you don't want to go into automation, but you can still advance in manual testing, and the way. For example, I explained about, you know, testing the Walmart website, that might be a standard web page. Now in IT, there are different kinds of things you are going to be testing. You're not just going to be testing websites. They have CRMs, you know, they have CMS, content management system, you know, client relationship managers. Different ways of what you could test. You know, you could test MLs, you know, the differents not just only web pages. So on the interview question, you can come of like, what did you test. Is the a web page, I hardware, you know, those are the kind of things that interviews my actual, like in terms of what kind of applications you do test. We are different kinds of applications. You know, they are, you know, typical standard like websites. You know, that's typically walmart.com, you know, test the front page, you know, login page. You can change you can add things to your card, you can check out that's typical, you know, a web page. But they are actually different kinds of applications and things that Q ways do test. So don't just think that you know, you're only going to be testing just a website. No. You know, they have MLs, they have soap UI. You know, they have so many things that they want you to test. And I'm not saying this to overwhelm you, but just to get yourself prepared QA is dynamic, right? It's a dynamic position where you don't have to learn everything, right? You could just focus on what you're comfortable with and what you can challenge yourself to do. You know, I think that also one thing is also backing database. I I I talked about data, but a lot of data stored in the back end, and there are tools that you use storing those data, so it could be Oracle SQL and stuff like that. Now most of those data are actually moving to the cloud. Sometimes they could tell you to do backend testing. Ben testing is actually when it's here backend testing, Ben testing is testing the database. Remember when I say Walmart, walmart.com, login page and all those things, that's what they call front end. Front end is what you can see, like what the customer will see. B end is what is happening at the back of the application. The data that is moving. When you enter in the user name, enter in the pass will hit the summit. That's the front end. What's going at the back end is that that user name, where you enter the data, you enter in the user name tab, is going to hit the back end, where the data is actually stored, and it's going to verify, does this user name exist? If you enter in Charlie as a user ID, it's going to enter in the password. Let's say you enter the password information, and you hit the summit button. What happens at the front end is that you enter the username C char password information, it the submit button. Now at the back end, that Charlie information password summit is going to trigger the back end and verify. Is there any charlie, and if there's a char, what is the password? Is the password information, and if the password this information, grant access. Right? So that is the back end. Now the customers are going to see that at the back end, that the whole username password and all those things. I mean, at the backing was going on at the backend. So that what they call the back end testing. And that is very crucial because a lot of interviewers who asked, you know, they look for backend tester. So backend tester is right for you to actually test the back end, right? You don't just you write SQL queries. SQL queries like you query the database to. That's an another kind of testing too. B end is also very important because that's also sometimes as a Q, they can hire you to do front end and back end. When you hear front end, front end is just testing the front side of the application. So use in password, submit, go to the card, adding card, remove card, check out that front end. Back end is now quering the database, so there can be so many issues at the back end. So you know, and for you to query the back end, you need to be able to be comfortable writing SQL queries. SQL query is also very important as a role or as a skill for quality assurance engineer, being able to query the database. For you to query the database, you have to write s, structural query language. It's it's not that complex, but it's a way of how you interact with the database because database don't know what is, how do I verify the user name. That's not a language that the database will understand. So you have to be able for you to interact with the data at the back end, you have to be able to write the language that the data at the back will understand. If you're trying to verify what is in if Charlie exists, or you want to verify how many user IDs are in maybe New Orleans in Walmart. For example now. You want to verify how many users use the Walmart application in New Orleans. You go to the back end and you write a query. You're not going to enter in how many user user name or user ID use walmart.com. The database is not going to understand that. There's a way you interact with the database or there's a way language you enter in so that the data at the backend will be able to understand what you're saying and produce how many user IDs are in New Orleans that are using walmart.com. So Data, what I'm mentioning this is that data back end testing is also very key in your role as a quality assurance engineer. So what I explained so far was types of testing, functional testing and those likes. But back end testing is also very crucial. I didn't really touch on I didn't explain much about back end testing because that's also another topic on his own. That's also Because for you to be able to perform back end testing, you need to be able to know how to write queries. You need to be able to be good in S QR. If you want to learn more about back end testing, I suggest like you could look up courses that talk about how to write queries, how to query the database and stuff like that. Once you lend that and you know fronting, front end is typically like just manor testing like the whole functionality, all those things. When you know fronting and backend, you'll be better equipped to be a full round Q ten Qa tester. So I think back end is also very important. 31. How to make a QA resume: So how do you make a Qa resume, right? So I also attached a typical standard Qa resume. So that's kind of like a standard QA resume. I mean, of course, resumes is all different, but for you to make a resume standout. And I can tell you because I have a good amount of experience making resumes, right? One thing you always want to highlight is that you always want to look at the job description, right? So every job description is different. Even though I'm going to be specific with QA, the fundamentals which have explained or touch you guys is similar across all the board. 80% of the roles and responsibility require all what I explained. But now some positions could differ based on the role. So the job description can require a certain kind of steel. Let's say it could be, I just want a back end tester, like what I thought about testing, the database. Another position can say, I want a front end or I want automation. You know, I want manual, you know, based on if they say they want to test, they want automation and you're talking about manual skills. There is a high chance they might not select you for an interview. So you want to look at the job description to see what are they actually looking for. Once you look at the job description, see what you're actually looking for, you don't actually have to make every resume for every job description. That's too much. You want to include a lot of things in your resume that covers a lot. To start with, You don't want to talk about create a resume for automation, where you're not an automation tester or where you don't have idea you don't want to do automation, that's defeating the purpose. Anything that you're creating in a resume is something you can be able to justify and something you can you can be able to defend and want to do. You just don't put automation in your resume and you don't want to do automation. Anything in your resume is something that you can define and you want to do. Now how do you make that resume? You look at the job description. You always have a standard resume that covers a lot. But now every position you want to apply or anyone that you're very interested in, you could add some features on your resume that shows what the job responsibility is looking for. Anything bullet points on your resume that covers the job responsibility you're looking for, the job description you're looking for. On your resume, now you don't have to say, in terms of creating that resume, what are things you've done in the past that can be able to translate into that role. So you know, in terms of, you know, making that resume, you could talk about, for example, I'll give an example like I think I mentioned about help help desk, and if you're trying to transition into Q way. As a help desk, you're very analytical, right because you're problem solving. You have a ticket, you know, an issue. You know, how do you fix that issue? How do you get to a resolution? We're being resourceful, we're being problem solving. That can transition into QA where you are query the system or the application to find defects. You're thinking asking the application or the system questions. What if I do this? What if I do this? What if I do this? Because when you get a help, when you get a ticket, automatically, you don't know how to solve it. You try this, you try this, you try this, you try this until you fix until you fix the ticket. That's the same thing with QA. In Q way, you don't look at an application and this is where the bug is, no. You don't know, you have to try and try and try. Moment you keep trying, keep trying to find the bug. That's s help this you keep you know trying to fix stuff, what if I do this? What if I do? That's the same way you problem solving, you resourceful. Then now when you close the ticket, you know you've resolved it. In Q, you also resolve defects. Once you go through the whole defect life cycle. Remember I talk about the stars, and you open and all the stats with the death team. And you close it, you resolve that defect. So you also resolve issues too. You are good at resolving issues. These are the kind of things you can put in your resume because you don't want to put that you have 20 years of experience in QA because when they ask you those questions, you're not going to be able to defend yourself. So you want to play safe whereas like you put all those skills, in your resume that can show the skills of a QA engineer for that position or just in general. So you want to talk about highlight, think about things in your past. Think about things in your past that are you good in communication? You are you a communication analyst because Q way requires communicating with the dev, knowing how to manage relationship? Because many times the typical issue might be, I find a defect a send it to the dev. The def says this is not an issue that is not breaking on my system. I don't see the issue. You go back and forth. Do you lose your cool? How do you manage your relationship with the developer? How do you manage your relationship with the business analyst? How do you manage your relationship with other QA members, your communication skills, your problem your conflict resolution skills. When a conflict arises between you and the developer, how do you fix it? So that's in the past to you can also draw examples of how you manage conflict or how you manage issues with your co workers or whatever, and you can tailor it into the responsibility of a QA engineer. You just have to draw out things from the past. You don't want to put irrelevant things on your resume that doesn't save any need. Please take it out. Anything you're putting on your resume, you don't have to you don't have to just because you want to overshine, put irrelevant things. They're not going to pick you for an interview. You want to put things that are meaningful for that job description. Anything that says, even if you had an award, doing something that even an award is great, but if you have something that you feel that is not relevant to that propose for the Q job description, it doesn't need to be there. Everything that needs to be on when they're looking at your resume, there are so many resumes. You're looking at someone that can be able to that has that skill to do this job position. When they see things that you highlight that matches the skill to solve the need they're looking for on the job description, then you have a high chance. You have to be strategic. You have to be very strategic in terms of what you put on your resume. I feel like a lot of skills are very transferable. A lot of skills we see we have in our day to day lives, even our personal lives are very transferable. Because Q IT work requires a lot of interaction. Requires a lot of communication. Could be stressful. I'm going to be honest with you. You could be very stressful because you're working on deadlines, how you can put on your resume. How are you able to solve or fix x y z in a very specific time frame? You know, how are you able to multitask? Because sometimes you could be working on multiple applications, you know, you have multitasking skills and all those things? Are you time time resolution time oriented, when they give you something, you get it done quickly. All the things are good skills. You know, you can highlight on your resume. On the next video, I'm going to show you how to answer interview questions. What kind of questions do they come up with? Now it's the next step is getting once you get into the door. Once you get that interview, what do you do with it? We talked about your resume, making that good awesome resume. Now what we're going to talk about is when you get that interview, how do you that interview? 32. Intro to how to get a job: Now, in the next video, I'm going to be explaining, you know how to get a job, how to learn that dream job, right? So it's not just only about I know you watching this course. It's not just okay, I read all this information, what am I going to do with it, right? Okay? I have an idea of Q. You know, I'm very familiar with QA now. What do I do? I know everybody that is watching this course wants to learn that dream job. I want to have a career in quality assurance engineer. So in the next video, I'm going to be showing you how to you know, make a resume and also how to answer interview questions. 33. How to pass an interview: Welcome to the video of how do you pass an interview. I guess now you've been selected for an interview and now it's going to the question, now you sitting with the interviewer and you think, how do I pass this interview to get a job. I think first thing is that you have to practice. You have to practice before coming into the interview. I can tell you that from experience because whenever you do practice before your interview, Your interview is always better, always better because you've done your research, you've trained, you practice, your confidence is up. One thing in interviews is that you always have to be confident. You always have to be confident because confident is key in anything you do. Even if you say the wrong thing, you have to say the wrong thing like and you say it very well. If you say the right thing and there's no confidence, you might not even get that position. Confidence is like almost everything because you could even say the wrong thing, but with so much confidence, let me give him a shot. Also, you have to have the mentality of you're willing to learn. Not just willing to learn because in QA or IT, they mostly look for experienced people. But they want to see that that you want to pitch in a way that you are resourceful. You don't need training, you don't need tutoring. You could pick up things, you could get the ball rolling, that mentality. Because in QA, in IT, nobody you're not self managed. They're not going to hire you. Although they're going to tell you a role, but they're not going to like, you have to do this to do this tomorrow. Because they're paying you a lot of money. They're not paying you a lot of money to sit down and wait for people to tell you what to do. You have to be the one setting up meetings, you have to be the one initiating. This is like you calling a lot of shot in your space, in your Q way space. You're sitting down with developer, you're testing, you trying to make sure that the environment is ready. So you're doing a lot of things, you are being proactive. That's the thing they want to see. You want to talk about how proactive you are. In terms of, you don't sit down, be be told what to do, you move. You set up meetings, you test, you do this, Tse the things that confidence and being proactive. Those things, anyway, you want to highlight that to your interviewer. You could draw experience in the past. A lot of interviewer questions is going to be what do you do do in this scenario. Also the terminologies, the IT jargons, like I mentioned, others, back end testing front end testing, SDLC phases, all these IT terminologies, is something you want to be familiar with. You want to understand what they are. You know. Also in terms of what questions they ask. I know the typical question is always tell me by yourself. Tell me by yourself is a way for you to showcase for you to. You don't have to start saying irrelevant things, but you can mention you know how proactive, you know, how you get things done relating to that job position. You just don't say anything. You see everything you say, your proactiveness, your resourcefulness, your communication is related to that job position. No one cares about if you did anything in the past that doesn't relate to what they're looking for. So anything anything that you can say that can draw you closer to that job description, what they are looking for. Actually when they want to see your confidence, your proactiveness, your communication skills, other things, all those good things relating to your job position. Also another thing our advice is going on YouTube. You can go on YouTube and you can google in Q way interview questions and how they answered it. I think that is basically 70%. I want to say 70%, but that's a lot aside from your confidence and those proactiveness and communication. Being able to know how to respond to questions. You will see a lot. So I'm going to be honest with you. Quality assurance interview questions is pretty much standard across the board. So there are a couple of questions that you're going to hear all the time. You're going to hear a specific kind of question. IT. The questions are always the same. So if you just go on YouTube and just spend X amount of minutes or hours, listening to interview questions and how they respond, and you now thinking about how you can also respond to get a job is not going to be difficult peal when you have that confidence because the questions are the same, the same, the same, the same. So Google on YouTube, interview questions and answers, see how they answer those questions, and see how you can draw from your pass to answer those questions. I can guarantee you that if you watch not just only one YouTube, multiple ones, see the similarities, most of the questions that are coming out. If you prepared for those kind of questions, how you can answer those questions, you have a closer chance of your confidence getting that job because the interview questions are all the same. It's not something that will actually something that is totally out of the ball, something that is imaginary no. The questions are very sand standard questions, and most of the response is always the same. But being that you don't have that much experience or that experience, you could draw from your past that will relate to those answers to those questions. And when you speak with confidence, you know, you'll be able to execute or get that position, you know, because most of the questions, like I said, are all the same questions. So just have to prepare prepare, prepare prepare for the interview, some confident, you know your ions, know your stuff, and be able to execute. You know that smile, very important, smile friendly. You don't have to come very hostile, no. You don't have to put that smile in your face that approach it because one thing interviews are looking for Aside from the knowledge, aside from the knowledge, So the intervene. She knows or he knows what he's doing, they might not lecture because they want people that can fit into their culture. So you want to see that you are approachable, you know, that you are, you know, like you are a team oriented person, you can work in teams. So that smile being a personable, you know, is also very important in IT, because you're going to be working with a lot of people, and I are going to be working with a lot of people under tight conditions and stress. I'm not saying IT is that stressful. But they're not going to pay you above six figures to not be stressed or not to do anything. The higher the pay, the more responsibilities. These are like you're doing a lot of responsibilities. Interacting with a lot of people. You're testing, you are reading documents. All this is like you're going to be working with a lot of people. How is your approach? Do they want to hire you when they see that they can work with you, they cannot comfortable working with you. You have to show they are very personable. You have to show they are very team oriented, confidence, and proactive, and also along with able to answer those interview questions. Sometimes even the interview questions, even if you don't have that experience, but you ansite in a way that the interview likes what he hears. You like we draw stuff from your past that relates to that answer and you have other things working for you. There are so many things. There are so many things pluses that makes you stand out. Aside from the confidence, your proactiveness, your personable skills, your team oriented skills, and what you're saying. So there are so many things. And the more you don't me discourage that you don't want to interview, you don't pass, is always like there are multiple Q wave positions out there. So there are a lot. I must say there are a lot, but they keep coming, and the industry is also competitive. But don't be scared because there are also people that are coming in as you. There are people that have very little or no experience as yourself. So The more you keep practicing and learning your stuff, you know, and also that team or rental skills interpersonal skills, that good smile. You know, that smile on your face, you know, doesn't hurt, being approachable because people are going to be working with you. You're going to be working with people. So all this should set you up to be able to lend your dream job. So I'll see you guys in the next chapter. I'm going to talk about certifications. 34. Certifications: In this video, I'm going to be talking about certifications. As a quality assurance engineer, it's always good to have certifications. Now when do you get those certifications, people say you get it when you get in because there is going to be easier for you to pass the exam because you're more knowledgeable and certifications can be quite expensive. It's not cheap. You won't just want to start spending money when you're not even in, but also they do help your standard on your resume. Because when they see that you're certified, even though it's not the N of BO, but it's an added advantage and also to your credit, because you want to be catisfied. You want to feel that I mean, I got this, I'm a certified quality assurance engineer. It feels good. So getting certification is very important in your area in quality assurance and in the IT because even though you know that sometimes we have bachelors, our masters a PHD in IT certifications. You know, a lot of people that when you come in, when you start working in IT, you understand that certifications is very important. Like, you know, it makes you feel good, it makes you like, you know, something that you attain, you attained, right? So even though when you put it on your resume, yes, they look at it, why it is okay, this person, you know, has the certification, but also for you to like, okay, I'm a certified quality assurance engineer. There are m multiple bodies that do do offer certifications for Q way engineers. I put the list online for you to go and look at, you can research which one you want to do. Any of them is good. All of them are all good for you to most of the time, what you should be looking forward because as a manual tester is the manual quality assurance certification. You don't need to go into automation. But if you're also very familiar with automation, there's also certifications for automation engineers as well. Manual testing have the certifications for those. When do you take that Any time to be honest is awesome. If you can afford it, so if you read up and you understand it, and you're able to pass the certification. There's a very high chance you could land that dream job because everything they're going to ask you on the job is going to be in those certifications. You're going to certification will cover every interview question. If you can actually pass that interview and those certifications, you have a higher chance of passing an interview. By the same time, you can still get that dream job without a certification, and once you get in, you can eventually get that certification. But either way, at some point you have to pick up or get that certification. 35. Thank you: Thank you, everyone for joining me in this journey and in this process for being able to total you on quality assurance. It was a pleasure, you watching my video, and I'm happy and I'm glad I hope you guys were able to learn a thing or two and prepare you for quality assurance. You know, you just have to believe in yourself, know that you got it, you know, watch the videos, if you have any questions, you know, you can comment below, and I'll definitely respond to you. Like, I'm here to guide you towards getting that dream job. You know, I did explain a lot in detail. So you know, a lot of the videos, a lot of the message I sent I explained is very helpful in landing that dream job. You know, so I'm here, like if you watch the videos and you're confused on anything, you know, on any material, you know, just send me a message. You know, I'm here to, you know, guide you in the process in landing that position. You know. So any questions you have, you know, let me know, I believe in you guys, I know you guys got it. You know, you have to put in that work. So the more you put in, the more you're going to get out in that standard. So you don't just do things passively and just, you know, for you to actually be watching this video, you actually had an intention, right? You had an intention to pursue this career. So you just don't watch the video and don't do anything. You watch the video, you go on YouTube, interview questions. You know, you study the material. So a lot of the artifacts I sent to you understand all those artifacts, you know, related to what I'm saying in terms of what the quality assurance does. You just have related to your resume, your past experiences, you have to fill in the dot, you have to create your story, and you have to be knowledgeable. Also with all the whole soft skills I mentioned about your confidence and personality and being approachable. Is a process and I'm not saying it's easy. It's not easy. But it is a process and it's a process that's going to be watered because this could change your life forever. Once you get in like you're in, the biggest challenge is getting in and I've yet to support you to get in. Once you get in and spend one, two years in QA, you're good. You could transition to something else. You could do any other thing you want to do because it's all the same SDL, it's all the same process. The biggest challenge is taking that first step, starting, and I believe we can start. Once you I'm happy that you're able to watch this video. You know, once you watch, it doesn't end here. It doesn't end here. You have to continue this process. You have to continue this journey. You have any questions. I'm here to answer I'm here to support you, and you have to continue. You know, you have to keep improving yourself, learning more things, you know, more knowledgeable, the more practice, practice, practice, you become better, you know, so you know, you have to be intentional. And, you know, I'm here to answer any questions. So if you have any questions, reach out, and if nothing else, thank you for joining. Thank you for watching my case, and I will definitely be in touch. Thank you for watching Good luck. I believe in you and I know you got it.