Hi, everyone. Uh Thank you so much for joining this session. Uh I hope you are all safe. Uh My name is Emma Kor. I have around seven years of experience as a software engineer. Uh My expertise are uh uh uh licensed software testing.Uh First of all, I would like to thank Rotech Network for providing this uh amazing platform uh where we can share our knowledge as well as we get to learn from different presenters across the globe. So in today's session, we are going to discuss about uh quality assurance and uh how we can achieve it. Uh Let me quickly share my screen as well and we'll get started. I hope you all can uh view my screen. Mhm. All right. So uh what is quality assurance uh in general Q A? It's to uh make sure that the products that we are going to deliver are free of any sort of damages and uh those satisfies the customer expectations as well. So let's take an example uh say in a restaurant, uh customer has asked to ask for a specific dish with the 3 to 4 ingredients to be added in a certain amount. Uh Now, in order to uh prepare the dish, the chef needs to keep in mind all the specifications that the customer has asked for. Uh Now the chef has added three ingredients but forgotten one or did not add the exact amount that the customer specified.

And when that product or the dish is delivered to the customer, the customer is not gonna be happy about it. Uh Now what if we had someone uh to ensure that the exact ingredients are added in the exact amount in that dish? Then uh uh we would be in a uh like we would be able to deliver the exact uh product or the dish to the customer. Now that uh person is our uh Q A person or the quality engineer, the same uh uh role of Q A is exactly that you make sure that the software that uh we are going to deliver, it meets the expectation of the customer and it is defect free. Now, uh moving on to the purpose of quality assurance and why it is so important. Uh It is important because it provides the confidence that the quality requirements will be fulfilled. How would that is achieved? It is uh uh by going through each and every requirement. So most of us are working in A G and we are getting new stories each uh sprint. So uh we need to make sure uh that we have gone through the requirements. Understood. The requirements and verified that those requirements are fulfilled during our SCLC. It also ensure, ensure that clients expectations are met in all aspects, whether it is uy, whether it is uh design, whether it is functionality, security or performance, each and everything should be uh met as per client expectations. It saves us time and money.

Uh Now, without Q A, most bugs would potentially be bigger and maybe only caught in the testing phase after, uh, or after the, uh, you know, uh, the project has been released, uh, then fixing these bugs would, uh, definitely cost uh a lot to the customer and business. So this is how quality assurance is saving us a lot of time and money as well. Uh And the most important is customer satisfaction. It is meant to, uh, to deliver a defect free software as well as to make sure that the software that we are delivering is, uh, requires no maintenance or the least maintenance required for that particular software. Next. Uh What are the different, uh, stages involved in testing?

So, in our software testing life cycle, we need to follow certain steps or we need to go through phases, uh, to, uh, accomplish our software testing. Uh, first of all, it is a review of requirements. So whenever we are getting new stories or new requirements for customer, we need to go through those requirements and understand the customer expectations. And, uh, we need to, uh, if we are having any doubts or questions or clarifications. We need to reach out to the business uh to get those clarified. And also in this phase, we uh identify the types of test to be performed, gather details about testing priorities and focus. And also we uh need to analyze that. Uh if we need to set up certain type of test data or what is automation visibility, what are the test cases that are automat that are not automat? All these things we can identify in our uh uh requirement space. Next is the planning uh de planning is done by mostly by the team or the manager and it is done uh once and it is followed throughout the uh life cycle of the uh software development. Uh It involves the test plan strategy along with the efforts and cost estimates for the project. Moreover, uh uh how many resources are required, what will be the test environment, test limitations and the testing schedule. All these things are covered in test planning.

And it also involves the test tool selection, whether it is for setting up any data or it is for uh selecting the automation tool. And even if the resources are required to undergo certain training uh for before uh getting into the test execution phase. Uh Next uh once the test planning is done, uh we have test designing, writing test cases and a review of those test cases. So we need to identify what are the different types of uh use cases uh that can be there uh uh for our application, the happy part, the case scenarios and the different uh negative uh test cases as well that need to be executed. And uh we need to send out those test cases to the business as well to uh and if there is uh any change or updates are required, we can review those and then they can get back to us and we can accommodate, accommodate those changes. And then again, we can uh send for review once we have finalized the uh test design document. Next, we have test execution, test execution is the most important uh phase of uh uh that is involved in testing. Uh It is carried out by the testers and uh uh they are uh going to carry out the testing of the test plans that they have uh created in the last phase.

And if we have already prepared our test scripts, also automation test scripts, we need to execute that. We need to execute the test cases. We need to modify the test scripts if required. And we need to uh most important thing. We need to, if we find any issues, we need to create bugs for that defects. For that. We need, we can, and we need to assign those defects to the developers as uh uh by assigning the appropriate priority and what impact it can make. And then once uh those are fixed by developers. Uh re this will come back to Q A uh for the retesting, we need to retest. And once we see that those issues are no longer present, we can just go ahead and close those defects. So this test execution, uh the activities that uh we carry out is uh executing the test as per plan then and document, then document the test results and the uh logging defects and uh retest the defect fixes uh and uh track the defects to closure. Uh So uh let's say we can uh come across a certain use case which was uh which was uh not anticipated uh by the business also before. And we have come across only while we are actually testing the application. So for these scenarios, we have made a defect, move it to development, but even the developers are not sure about what they need to do.

So we need to follow up with business and we need to get the clarity that whether this will be fixed now will be implemented now or this will be taken up as a separate enhancement or story at a later stage of development. So as a deliverable, we'll be delivering the test case results after our test execution is done and we'll be delivering uh uh the defect reports, we'll be sharing it with the management, then we have uh performance testing and security testing. Now, these two are uh nonfunctional type of testing. Uh But these are also equally important like uh performance testing is done to validate the speed, the responsiveness, the memory utilization or how our application will behave under a certain amount of load. All this is done uh in performance testing and it is carried out by a specifically skilled uh tester uh thoroughly. It needs to be done next insecurity testing. Uh It's a testing uh technique uh which we need to perform in order to check whether there are any risks or threats in our application or uh there to make sure that there are no security vulnerabilities in our application. Again, this also needs to be performed by a security uh tester separately. Next cross browser testing or cross platform testing. Now, this is an optional uh uh kind of phase.

Uh It can be done along with this execution or it can be carried out separately depending if our application is having more of a UX uh you know U I uh experience, then we definitely need to carry out this activity. If uh we are just checking out something in the back end, only the functionality, we might not uh carry out this process like testing our application across different browsers or different platforms. So it kind of depends on the product. Uh Next is regression testing. So uh regression testing is all about uh uh retesting the functional and nonfunctional uh test to ensure that the application is still working fine, even if the, there, there, there are some changes that have been made to the application and the functionality has not been uh broken.

Uh uh It is uh usually done before moving to broad in the prep broad environment. Uh And it is preferably done using automation because by this time, uh our automation uh scripts are also almost ready. So uh it is uh suggested to uh perform regression using our automation only. Then these are, these are the steps that the different stages that we need to uh like perform while doing the uh testing. Uh Next one we have is a role of automation in testing. So automation certainly uh plays a crucial role in testing. Uh It has huge benefits and uh nowadays, we cannot even imagine uh doing performing uh uh quality assurance or testing process without having automation in place. So uh first one, you can see it increased uh test coverage.

It allows to cover uh lengthy test cases in less time. So automation testing uh can significantly improve the test coverage because of the speed of the automation uh test. It can cover more test cases in less time. And uh there are tools automation tool which can run or perform a test unattended, which uh results in better utilization of uh time. So it saves time also, next is improved accuracy. So uh by manual testing, there is always a possibility of uh uh having human errors. Uh uh But with automation, uh no matter how minimal those uh you know, uh errors can be uh those are completely eliminated with the help of automation testing. Next is uh faster testing process. So automation testing is faster, uh definitely faster than the manual testing because it involves the use of tools and it gives an additional uh advantage to curate teams. It helps them to execute the test uh with ease uh and in in a quickly manner and also meeting the deadlines at the same time. Next is uh increased scope of software testing. So automation testing can execute the test cases that are difficult to uh you know, achieve with manual testing. For example, we are going to, we need to test a certain uh test case which, which, which is having a different set of data input.

So if we try to do that manually, it will take a lot of time or we can say it is practically very difficult or impossible to achieve. But with automation testing, we can just give our data inputs uh different data input in our data source and we can just run the same uh test case uh over and over again. Uh Then we have this earlier detection of uh bugs. So automation uh testing makes it possible to detect works during the early stages of the software life cycle. Uh Whenever there is a change in the source code or the test can be run automatically to detect any bugs. Uh If there are any changes more about the simultaneous running of uh test cases, makes it possible to detect uh to generate the detailed reports for easy comparison. Like how the repo uh how the uh application was working before and how it is work uh working now after there has been some modification in the application. So uh next up, we have, we have like multiple tools available for automation testing. I have just mentioned a few that I have personally worked on Selenium E PM, Deplete, Deplete and Catalan Studios are uh studios like uh these are I DS uh where we can just drag and drop.

So any person with having uh uh uh very less coding skills or uh even though coding skills, they even they are able to write automation uh scripts and perform automation testing with the help of these automation tools. So you can explore multiple other automation tools as well.

So next one, we have how we can achieve a quality assurance or what are the things that we need to keep in mind when we are uh you know, when we are trying to uh start with the quality assurance process or a testing process. First one is uh create a purpose testing environment which involves building a robust testing environment means choosing uh the correct test platform or choosing the correct test environment like a Q A, whether it's Q A or uh it's a preload environment. We need to keep in mind that it should be exactly like uh a production environment. It should be a replica of the production environment. It also involves uh choosing the correct browser or all the pro uh possible browsers that we need to test our application on. Even the operating systems are all the different devices if we need to test our application or devices. Uh then uh it also involves the ability to decide the priority dependency of the test like which uh test should be performed first, which will be performed at a later stage.

All these things uh are part of this uh defining the test environment. Next one is uh we have a select release criteria carefully. Now release criteria can also vary from project to project, but there are certain points that are I think common in uh for all the projects. Uh basically, almost all the projects will follow this. Oh this criteria. So first thing is obviously the code should be working fine for the pla uh platforms. Wherever it is meant to be working, there should be no high uh priority defects open. Uh And even if there are any open defects, there should be walk around what are defined for those bugs. Uh Then we have all the plan Q A uh testing should test should be running fine and uh features or whatever features we have planned for that. Those should be tested by the developers during their unit testing phase should be tested by the Q A and should also be tested and verified by the business or end users on a high level. Uh And then uh it should be ready for the release and it should be ready for release by a specific date that we have already decided uh before even starting her project or development. Next is uh allocate time appropriately for each process. Like we have already uh gone through all the different stages of uh uh quality assurance that are involved in this process.

So we need to properly allocate time for all those uh like what test designing like uh by this time, test designing should be complete or by this time, we should start this execution and this much time should regression testing be take, taking. Uh So if we don't define those timelines, we will like never be able to achieve our deadlines uh on time. Next is uh prioritize bug fixes based on software usage. So like earlier, uh we have discussed, we need to clearly mention the priority of the and defects that we are creating uh whether it is a high or moderate or low one and assigned to developers accordingly because developers will be fixing those defects in order of the priority.

So high uh priority B should be uh fixed first and then the low ones then form dedicated uh security and performance testing teams. So uh for security and performance testing, we should have dedicated teams. Uh because for these types of testing, we need uh separate skills also and this should be performed thoroughly. So once our functional uh testing is completed, we need to hand over the application to the performance team though it won't take much time, but it is equally important to have our uh performance and uh security aspects tested. Uh Next one is uh simulate customer accounts uh similar to a production environment. So whenever we are testing uh in Q A environment or pre broad or in any staging environment, also, we need to make sure that uh we are testing, we are always testing as an end user. Uh We are using the same like uh kind set of test data that an end user will be using. And we should never be testing in any dev environment.

We should be testing in an integrated environment and this holds uh for all types of uh uh I mean environment testing environment. So we should always be testing, you know, as an end user as an end user perspective. Yes. So that was it uh about this session? Uh If you have any questions? Hi, Shona. Hi, Carolina, you can ask in the chat you have. Yeah, definitely. I will, I will check for the online course and I will uh let you know Carolina. Sure. Thank you. And you can get in touch uh on this uh linkedin chat. Yeah. Thank you so much. If there are no questions we can just close our session. Thank you so much for joining. Thank you so much guys. Any hi colette. Thank you. Thank you guys. Uh, bye bye, please. Uh, be safe and take care of yourselves and your families. Uh Hope we'll see you again. Thank you so much. Bye bye.