 Hi, hi everybody. Yeah, so thanks Michael for introducing me. So today my topic will be on a day in the life of a QE. Okay, but technically I'm not going to go through my day. I'm just going to talk about some tools and some things that I do. So, okay, let's start. So today I'll be talking about these things, which is my role as a QE, the different types of testing, the different testing frameworks, and then I'll go through some tools that I use for automated testing. Okay, so the first one. So I'm not sure how many of you have experienced as a QE or with testing. So I'll just summarize. So basically what a QE does right in the name quality engineer, we try to ensure the quality of the product. Okay, so there are some different ways to do that. For example, test plans and test scenarios, we'll design them, create automated test scripts, performance and security testing, exploratory and manual testing. So that one is, for example, trying to find bugs with the system, trying to find out things that break the system, monitoring and automation pipeline. So for example, every morning we push code, developers push code, they will run against all the tests that the testers have written to make sure that nothing breaks. And then last one is release and deployment support. So when you deploy code, we need verification. When you deploy code, you need tests, stuff like that. So that's generally what a QE does. So for all of you guys, I know you're quite familiar with what once it's like. So as a product backlog, it takes stories, then you take the stories into your screen and then you plan, you implement and there's review and retake. So when can a QE actually be involved in this whole process? Yeah, one might think that maybe it's just after implementation and then we test, right? So obviously the answer is not just there, that's why I'm putting up this, this infographic. So the idea is that actually a QE can be involved all the way at the start. So these are just some stages inside a spring, not limited to this. So for example, during backlog refinement, a QE can actually include testing efforts in the backlog item estimation. So we can decide how much time we spend on this item, how many things that we need to test, etc. And then in the next step, in spring planning, we can come up with test scenarios together with the devs to decide what is required for this story based on the ACS acceptance criteria. Then during development, we can actually write the automated tests concurrently with development. So you might think that you need to finish the dev code first and then we test. But actually with some of the tools later that I'll go through, we can do it concurrently. Then this way, it's kind of like test driven development, which I will talk a little bit about later. And after development, we can start doing more exploratory testing. So instead of testing what the developers develop based on the requirements, you can actually save some time because we are testing during their development and instead doing more edge case testing after that. So this is just some ways that we can be involved during a spring. So next I will go through a bit about the different types of testing. So I'm sure you guys have seen this pyramid before. So this is the testing automation pyramid. So how this pyramid is designed is that at the bottom, you can see we need a lot of these tests. So unit tests are the tests that you should write the most of. And it should also test the small components. Then as you go up, you should write less of these tests because it costs more to test them. It takes more time, but it tests more things. So unit tests are only tests like your function, how your function is supposed to do. Integration tests is how this test interacts with, how your feature interacts with external components such as external APIs, database, web services, etc. And then end to end test, you use a test environment to check that all your features are running correctly. So this is just the different types of testing. Another way to visualize it is also through this testing quadrant. So you can see there's like a scale like this and like this. So business facing is like what the users want to see. Like if I want to design an app to transfer money, then they must be able to transfer money. Then technology facing is like performance. So if I'm going to design an app to transfer money, how fast can the body be transferred? Okay, this is just an example. So on this scale, you can see the different types of testing. And it's not that one quadrant is more important than the other. It's just that it helps us visualize the different tests we need to make one feature. Yeah, so okay, this is just a visualization tool. Okay, then next we will talk a bit also about the different frameworks. So on top of these tests, we can actually have another layer. So for example, behaviour driven development. So just now we were talking about business requirements. So tests can be written such that we explain what the business owners or product owners want the product to do. So for example, I want to transfer money. So then I write the test in a way that I literally say, I want to transfer money. The test has to do exactly that thing. So it helps the developers focus on what's requested helps document the things that the app's supposed to do also. There are enough framework is also test driven development that you guys are more familiar with where you write the test first, and then you develop, I mean you write a failing test first and then you develop until the test passes, then you refactor, then you write another test and you develop. So the cycle is here. You can see you're right. It passed the refactor. So the thing that I wanted to raise here is that it's not just limited to unit tests. I know developers are more familiar with writing unit tests first, but actually automated tests, we can also write a failing one first before it passes. So one example could be, for example, I want to click this button to go to the next page. Then you can actually automate this clicking process. Well, first it's going to fail because the button is not there. But after you go to the button, then it will pass and then it will move to the next page and then you can test. So that's the same idea. So after we go through these things, we can go and talk about the tools. Some of the tools that we use for automated testing are here. I will talk about each one of them. So first one is Selenium. It's a browser automation tool. It executes remote commands across the network and the Selenium suite consists of these three things. The IDE helps you record and play. Then there's the Selenium grid that allows the test to run on different browsers in different OS. So you can run in parallel in code, Firefox edge, and it has a hub and several nodes. So you can run it in parallel. And the last one is Selenium WebDriver. So I'll explain a bit about how Selenium WebDriver works. So Selenium WebDriver architecture is like this. So we have our Java code that is written for our test scripts. Then the Java code will actually, because the code cannot communicate with the client, the browser directly. So what happens is Selenium actually uses this JSON wire protocol to transfer data from here. So if the code is like, hey, click this button, then the protocol will have an endpoint to call. Then they will click the button. So it's like then. So the idea is it's a bit slower because you have to go through this thing and it's accessing from a remote place instead of accessing the browser itself. But this is the general idea. So after using this, there's some pros and cons that I have come up with. I guess you can also ask chat GPT. You don't just have to ask me. Then the idea is that the Selenium is open source. You can write it in any scripting language. I write it in Java. So anything can be done. And then you support different browsers. You can do parallel testing with it also. And it's also compatible with different OS. But the thing about Selenium is that setting up the framework takes a lot of time. And you can't actually use it for testing. Yeah. And also we need third party libraries for other features. Like if you want reports, you need to install stuff. Okay. So that's Selenium. Then we'll move on to APM. So APM, APM, okay. I don't know how to pronounce it. But yeah. So it is actually the same thing but mobile apps. So Selenium, I mentioned just now that you cannot use it for mobile apps. And that's because the protocol doesn't allow us to access those extra API methods that APM created for the mobile apps. So this is just like an add-on. And the benefit of this is that on top of Selenium is that you can do mobile app testing. And then the next one is Catalon. So there's a screenshot later. But Catalon in general is a low-code browser automated testing framework. So it's like a studio. I'll just show you. So you can see it's a UI kind of thing. Then you can actually record test cases and access all the code that you want from here. It's more for those people that do not really want to learn how to code. Then you can use this. Yeah. But there's also a scripting function. So if you really super-duper want to use this and you really super-duper want to code or so, then I guess you can, you can script in groovy. But they only support one language. So the benefit of this is that it's low-code, user-friendly. It has an intuitive dashboard. So it has built-in reports. You can just like generate reports from the UI also. And it also has integrated CICD. But the bad thing is also that you can only be done, scripting can only be done in groovy. And it's not open source. So you can't pay. So if you if you reach or so, then, you know, okay, I'm kidding. So lastly, because how Catalon works is that it actually has, it is actually on top of Selenium WebDriver. So Selenium WebDriver is ready a bit slower because it's it's remote and it accesses the browser through the protocol. So this one is like one more layer on top of that. It's definitely a little bit more slow compared to Selenium. And then I'll go through this one Cypress. So Cypress is Java script-based. So just now we're talking about Java like Selenium. And we're talking about a studio that you can just click, click, click. And now Cypress is only a Java script-based. So what it does is that it manipulates the browser directly using, so basically it runs in the same loop as your application. So you don't need to access the browser remotely. It just runs in your browser. So because of that, right, it's actually a lot faster. So the, where Selenium, right, we're running from a remote place into the, through the browser. So one of the benefits is that Cypress is easier to set up. If you are using Node to develop your apps, then it's just running in the same loop. And okay, I don't know if you are familiar with Selenium, but sometimes for Selenium, if you try to click on stuff, click on them. You can't click on them because you need to wait for the element to show up first before you click on them. So there's problems like this, but for Cypress, there's really inbuilt weights for you. So then you don't have to automatically, I mean you don't have to code the weights yourself. So it's just a lot more convenient. But the bad thing about Cypress is that if you want to do tests in multiple browsers, it's not possible. So if you want to like open one browser, click and then you close, you can't do that. And if you want to run tests in parallel, you also can't do that unless you download certain plugins. Yeah. And lastly, if you're very good at JavaScript, then good for you. But if not, then this one only supports JavaScript or TypeScript. Okay, then lastly, I'll talk a bit about playwright by personally haven't used it myself. So it's up and coming. It's a new library, uses browser library to access the browser. So it's actually also within the browser itself. So it's faster than Selenium. But it's up and coming. So the community is not as wide and there's not as much help as the rest. But there's still help. Yeah. So it's a good tool for us to try. Yeah. Then one of the benefits of playwright is that they can take automatic snapshots at each point in the testing run. So as a test run, you can actually see what the browser looks like at that instant. And then inspect the browser. So that's something that's cool about it. I personally haven't tried it. So I cannot really say my experience using it. So now we're just I'm just listing some tools. But previously I mentioned behavior driven development. So there's actually another tool also that can help with it. Okay. So I'll talk a bit about cucumber. So how cucumber works is that it can integrate with any of these things that tools that I mentioned below. So you can actually have cucumber together with Selenium or cucumber with Cypress or cucumber with Catalan. It's just how you put them together. And how cucumber works is that it helps support behavior driven development. So it reads executable specifications in English and then it runs code based. So let me show you somewhat of an example of this. So we write written text based on user requirements and it's written in Gherkin. So Gherkin is the language that supports like given when then. And then each step is mapped to a function. And then after that, after you run your test, you can also see the reports. So here's one example. So for example, so the left side, the left side of your left side, my right side, your left side is the Gherkin language. So this is the step we have given today is Sunday. Then on your right side, you can see the function. So I will, for example, set a variable to be Sunday. Then let's say I have another line say when I ask whether it's Friday yet, so then you will map literally a sentence to the function. Oh yeah, okay, it is Friday. And then the then sentence will be an assertion. So what I expect this test case to do, then I'll map it to, yeah, I said that it is gonna tell me no, no or yes based on whether it's Friday or not. So this is just a general gist of what cucumber does in how it works. Yeah, so some of the benefits of cucumber is that we can express our requirements in human readable form. So instead of writing testing code, like a click this click that you can need, you can tell in English what we're supposed to do. It helps with usability because let's say I keep needing to log in, I log in, log in, log in. I don't have to keep coding log in. I can just write the English word I need to log in like a few times. But the bad thing is that because it's written in English, I mean, it's kind of redundant sometimes. If I want to write too many things, like, and a user clicks this and does this and does this, it's not as efficient as writing code. Yeah, so here's some just some pros and cons. So ultimately, a testing tool, there's many different testing tools, and there's many things you can choose from. But ultimately, a testing tool should be decided based on your project requirement, your team's technical competencies. So for example, what language are you more comfortable with, whether you want code or you want to code, and you have to determine which of these pros are more important to you. So based on what you value, you can therefore choose the testing tool. So in summary, this is what I plan to go through. So in summary, a QA's role, you can actually start as early as backlog refinement in the spring. For the different types of testing, you can't just focus on one test, you can't just do unit tests and then like, oh yeah, I'm going to do like 25,000 unit tests and my app's going to be successful. But the idea is you need different types of tests. Then for your testing framework, it's another layer, so you need to decide. You can actually have multiple testing frameworks together, but you can decide based on your requirements what you need. And lastly, for your tools, it should be chosen based on what you need and what you're more comfortable with. Okay, with that, it sums up my presentation. Thank you.