 Right great. So welcome to our first tutorial for Q3 hackathon. Happy to turn things over to Ramya Ramya, I'd like you to introduce yourself to the community and then you'll feel free to share your screen and we'll go from there Sure. Yeah. Hello everyone. So this is Ramya and I'm with the quality team and I'm actually managing a team or the just which comes under the depth section and In this meeting, I'll just go over a few things which we want to highlight as part of our contributing to the Quality team. So let me just share my screen Cool. Yeah, and therefore for people online, this will be posted on the hackathon page and shortly after the After the sessions over so So in GitLab just to give you an idea. We have a bunch of tests written So we definitely have the unit tests which comes as part of the development itself and apart from that we also have integration tests and feature tests and we also have something called end-to-end tests so these are basically tests that cover the end-to-end flow and You can find these tests inside the QA folder in the GitLab C project and There's also a read me in that folder. So that gives you All the days about how these tests are structured and where you can find different things and These end-to-end tests as it's specified It's it comprises of both the UI tests and as and the API tests as well So the UI tests which captures the end-to-end flow and the API tests These are not the tests of testing each API end-to-end per se. It's more of Testing the API workflows. So all of those tests are categorized and they are part of these end-to-end tests and Yeah, there are a few best practices we follow as part of our development and one one such thing is to use APIs for creating any results that are needed as part of this setup itself and so that is one and another thing that we actually follow is to use page objects and We have the page objects and the actual test code separate and you can see an example, which is given here So basically the page object contains all the details about About the elements and the selectors and the test code. It has the actual logic to test the radius Yes, and if you're going to add a new end-to-end test Then this would be the place and these are the few things that you might have to create like You might have to create a new page object or you could even reuse an object that is already present and just write your test logic alone So moving on to the next slide So this is about how to name your branch. So it actually matters how you name your branch because If the name starts with QA or it could ends with QA Then we have a different workflow defined for the entire CI pipeline. So what does this workflow do? It actually sits a few jobs, which are not relevant for the test code and There are there is one more job, which is run as mandatory for these QA tests. So I can talk about the mandatory job later on. So it is always good to Follow these naming conventions so that your CI pipelines are quicker and you can get a quicker feedback and How do you run the existing tests or even if you add a new test? How do you run it? So these are like I've just highlighted the basic things that are needed. Obviously, you would need the GDK to be set up So GitLab development kit and once you set it up and once you have Once you give a GDK run, meaning you have started your server, your local server Then you can actually visit this local host colon 3000 and you should be able to see your GitLab instance up and running at that port and To run the tests. So this is the command that you can use but the exact VQA and then in test instance all Means that it's going to test the instance that you're going to provide So the instance here is the local host colon 3000 itself. So that's the address which it would use So you can also run individual spec files. Like I've also mentioned an example of that here So say for instance, I want to run a particular The tests under a particular folder Then I can just give the folder path or I can even specify that spec file itself and You can also read a lot more about these These things and you can also see what are the various ways in which you can run the tests and What are the various environment variables that are being used which you could set to run the test? So there are say for instance one variable which could be of use for you Would be the username and password. So There is a default username and password But if you want to give a different one, then you can actually use the environment variable GitLab underscore username and GitLab underscore password as part of this Bundle exec command and it would take that and use it in your test so Though there are a bunch of information in those links in the readme file again So you should definitely take a look at that The GitLab QA gem. So this is something that I want to talk a little bit about and it's good to know about it So this is basically a gem that we have written and Why is this gem used and what is the purpose of this gem? So this is basically an orchestrator So if you want to run your tests on your local then it's good enough If you just have your GBK setup But if you want to run it against any other instance, say for instance, if you want to run it against a Docker image Which is already built and you want to run it against that you want to run your test against a GitLab Docker image Or if you want to run your test against a live instance any other instance so in that case you can actually use this GitLab QA gem and Just again the commands that you can find here are very much similar to whatever you see You saw in the previous slide, right? So you can actually specify so the The URL of the instance and then you can also specify specific Spec files as well. So those can be given as command line arguments Yeah, the example that I've given here is actually an instance where it's actually fetching the GitLab Docker image which is of version 10.8.1 So it would just fetch that Docker instance and it would just run your tests on top of it Yes, and this is just an example of a CI pipeline how it would look like when you run your tests So there are a couple of manual jobs Called package and QA manual and review QA all so you can see these two jobs specified here like under the QA Stage if you see there are like there is this dust and followed by package and QA QA and then it's followed by packaging QA manual and It has a bunch of things. So what's the difference and what does it mean? So basically the package and QA manual job is It's run only when you trigger it So if you see there is a An arrow mark right like a play button that you can see in your packaging QA, right? So what it means is unless it's triggered it would have the Tests would not run so you can trigger it manually and then the tests would run That's the same with the review QA all as well. So once you trigger those jobs, it would start running But there's one job which is auto-triggered only for QA branches and that's packaging QA So that's that's why you actually see it looks like there are two packaging QA jobs But actually the one the first one is packaging QA and the second one is packaging QA manual So so the first one runs by default for all the QA branches meaning any branch that starts or ends with QA And what does these are? What does it do? these actually run all the tests that are present inside the QA folder and Yeah, so that's what it does and what is the difference between Q review QA all and packaging QA manual So or any packaging QA job. So basically review QA all it runs on top of the review apps If you know what a review app app means. So basically, it's just an instance and a Dynamic environment that is spun up with all of your changes in it And you can actually run all your end-to-end tests on top of this dynamic environment. So that's That's what review QA all does But then packaging QA basically it does everything you are using omnibus and All the tests are actually run after that Yep, those are the few things which I really wanted to highlight and yeah, all of those instance I mean all of these details are actually there in the handbook as well So you can take a look at that and these are few links which you can which will help you to get started quickly and Yeah, all of the issues for which we are accepting contributions are listed here and the quick start guide and we also have a style guide and best practices guide which would help in not Understanding the way this best practices we follow as the quality team and you can take a look at them as well So it looks like there is a question. I Just added a piece of the link to the to the issues Yeah, actually if you don't mind like clicking on that link, so I wanted to a couple of questions if you don't mind what to ask Sure So in which one right from the side? No, it's just on on the list of issues. Okay. Sure. Yeah Oops Yeah, I noticed that like the first couple actually has a weight of one So, I mean, I think those are should be good for like a relatively newcomer as I would assume, right? Yes. Yeah, I don't know if it's wall wall mere who put the weights there So, I mean, maybe this is dumb question like I was looking at those issues Is I mean, is this like more like document documentation of what testing needs to be done like in the markdown file Or is this is something that requires people to like Write code in like Ruby for example, but yes, it's the second one like it needs people to write Code in Ruby and these are basically test scenarios, which Can be automated like rather than doing a manual test these tests can be automated. So these are a couple of scenarios Okay, so they just need to create a merge request here in this project and then You know, they can ping, you know, either you or me to get our attention Yes, so the merge request can still happen on get lab see itself. Okay. Yeah Okay, we have the code deciding there only right. Yeah, okay. Okay So that definitely helps and then obviously having this, you know If people have other issues that they want to open, you know, obviously people are welcome to do that they shouldn't I mean this is sort of a I think what I like to call a starting point of Where people can get started but if people can think of other issues or other things that they want to work on They're obviously people are welcome to create new ones Cool. Yep. So that is all I had. So any other questions? Yeah, if people have any questions and you can like go off mute and verbalize them or feel free to type them on the chat We'll give it a few more minutes. Make sure that People are able to ask questions Cool. And I also find the documentation to be I think from if you let me add a link Here if I can find it Give me a second. It's off of the tutorial session Section of the hackathon page people if people haven't read this yet, I thought this was a good overview It's basically in in the docs for end to end testing. I think a lot of these stuff Rami you already went through but this is a good reference material. I think Any other questions or Yeah, I thought like because I know there are people that are very interested and passionate about testing. So I Rami, thanks for coming and I think this is somewhat long overdue but Thanks for Thanks for your presentation and then yeah If after the session or people are watching the recording people have any questions Let me feel free to find either me or Rami. We're obviously on the team on the team page and they get about gitlab.com and Happy to help you out Right. Cool. All right. Thanks everybody. I guess happy hacking. Yeah, right. Cheers. Bye. Yeah Thank you. Bye. Thanks