 So yeah, so these are a few things that I'll be talking about Yeah, shifting left is something that most of us would have heard so we'll talk a little bit about that and about continuous testing So what do we exactly mean by continuous testing and how continuous? Can it can it be and from where could you start this continuous testing? So these are few things that I really want to talk about Yeah So a little bit about myself. So I'm with the quality engineering team at GitLab and yeah, I'm passionate about designing and developing test frameworks and tools and simple and powerful is something that I totally believe. Also, I'm with the women who coach in a chapter. So Chennai is a city in India and I'm one of the directors there and I'm really excited to see the other communities from other parts of us as well. Alright, so yeah, so get up. I'm sure most of you would have heard of GitLab rate. So it's the DevOps platform and yeah, it is cloud agnostic. You could use it in your own cloud providers and yeah, it could be self managed or you could also go with the SAS solution as well. Security compliance are all built into the system and yeah, open and always improving. So the main GitLab, it actually works on open core model wherein like the community in addition is actually open source and the enterprise edition is actually open core, meaning like all the code is available to you and you can actually read as well. So yeah, so these are various features that are in GitLab. I wouldn't be going through all of these just wanted to give a snapshot of what are available, the various capabilities that are there at GitLab at every stage of the SDLC. Yes, so to talk about the, it wouldn't be complete if I don't address the contributors as well. So we have around 3,660 open source contributors as of today and around 2,000 plus team members across 65 countries. And yeah, so mentioned here a few open source partners. So you can read more about what it actually means to be an open source partner that benefits when you are an open source partner. So I can read about it more here. So I thought it would be relevant to mention these details here given it's all about open source and yeah, and there's also this program called open source program, which is actually it also has to benefits meaning like if the project is a qualifying project then you get to use the GitLab ultimate features. And yeah, there are a few other benefits as well. So again, you can either Google about this or you could even contact the email mentioned here. All right, so getting into the topic for today. So this is about depth test ops. As I mentioned, when we talk about DevOps, we often hear this word called continuous across every stage, right? So continuous development, continuous testing, continuous integration, deployment, continuous monitoring. So my focus here would be on continuous testing. So as you see, like there are multiple tools that could be used across different stages to attain these things. And so when we talk about continuous testing, like how continuous can it be? So, for example, if you've seen this DevOps cycle, right? So you have a stage called test and so what does it actually mean? Does testing come after a particular stage or does testing happen across different stages? So that's something that I really want to emphasize on. And before we get into it, I just wanted to talk a little bit about this shift left. So have you heard a term called shift left? Yeah, so basically it's about shifting the testing left, right? So it's all about failing early on and failing fast so that the feedback faster and you improvise on it earlier. So that's what this whole thing is about. So what does it mean? So from where can I start testing? Can I start testing right from the planned stage wherein the requirements are being discussed? And can testing be done at a design phase itself where the UI and UX designs are all discussed? So where is the appropriate place to start this testing? So these are few questions that we'll answer as we go through the various slides. And yeah, when we shift left, there are few benefits attached to it as well. As I mentioned, failing fast, early detection of errors and yeah, it's cost effective and yeah, those are few benefits when you shift left. Alright, so that test ops is all about ensuring quality early on and at many points as possible. So as you hear, we test at different points in different ways. Maybe it's not exactly the same way how we test at every stage. You might not even, it might not relate to test cases per se. Actually, what I mean by testing is ensuring quality is what we are talking about. Alright, so the step zero or the bare minimum that needs to be agreed upon by the team members is that quality is everyone's responsibility. It's not, it's normalized in the hands of the quality engineering team or the testing team or whatever it's called. So quality is everyone's responsibility is something that all of us should agree upon, unless this is, I mean, this is a change in the mindset, right? So I think without this, I don't think we could achieve what we are trying to with whatever tool is being used. Yeah, as mentioned here, quality is a continuous process. It's no more a phase in SDLC. So yeah, this talks a little bit about what we do at GitLab. Yeah, the process is something that that most of us could be aware of. So this is about involving the various stakeholders during the initial phases during requirements analysis and stuff like that. So yeah, the product team, the quality team and the development team, they come together and discuss about it and don't be afraid of what you see here. This is actually the kind of key based on which the GitLab logo is based on. So yeah, so as you see here, like there are four different stakeholders who are involved in these initial discussions and we call that process as the quad planning process. So yeah, these are few things that we do at GitLab and the tools, as I said, we use GitLab to build GitLab itself. So yeah, the GitLab issues, milestones, epics and bit of features specific to planning. So all of those are being used and yeah, and can testing be done at the design phase? I think yes. So that's something that is done here as well. So we have this feature called design management feature wherein the designers, the UI and UX designers, they could add their details to the GitLab issues and the other stakeholders could actually collaborate on the issues itself. So this is a way of getting the quality engineering team involved and in the discussion itself. All right. So when you move on to the code, we build the code and the code and during code review, like there are certain features. So basically we need not think of, I mean, we could ensure quality. Not just by means of testing and test cases alone, but by various other features, which could be part of your CI pipeline itself. So that's what I'm trying to emphasize. So these are few things like code coverage feature is again available in GitLab and I'm sure like we could incorporate it in any of the CI pipeline as well. We have Gens and NPM modules which take care of code coverage and they could be used the CI pipelines to ensure the quality. And yeah, so static code analysis is another way of ensuring the quality of the code itself. Again, the example that I mentioned throughout the slide is all that's used in GitLab, the various features that are available which enables quality at different stages. But again, this need not, if you're using any other CI pipeline, it could actually be achieved by the various other modules that are available as well and it could be incorporated into your CI pipelines. So yeah, as you see here, so this is a snapshot of the MR widget. So MR is merge request in GitHub. It's called pull request, right? So it's an equivalent feature here and this widget contains, I mean, it could be configured based on what you need to see in the CI pipeline and the MR widget, it could actually show the quality and the degradation in the quality of code as well. And yeah, accessibility testing is again part, it could be again configured in the CI pipeline and these could be actually added in the MR widget. So what I mean by this is that even before your code could be merged into the next stage, maybe into the mainline branch, you are entering the quality of your code itself, right? So I think that is the biggest advantage. You get to see all of these defects or failures early on. Yes, security testing is again possible. You could actually add that to your CI pipeline as well. And yeah, again, this is an example from the MR widget again. So all of these are configurable in your CI pipeline. If you're using GitLab, then the GitLab CI.yaml could be configured in such a way that all of these are enabled and run every MR request, merge request. All right, so apart from all of these features that helps in ensuring quality. Yeah, of course, we do have end-to-end tests and other tests which helps in ensuring the quality as well. And testing permit is something that we follow and we try to adhere to. Unit tests are non-negotiables. No feature is complete or it cannot be merged without a unit test. So that's something that we have as a non-negotiable thing. And end-to-end tests are more of journey tests wherein it doesn't test every detail of a feature. It's more of a blanket which tests the user's journey from end to end. All right, so yeah, so apart from this, at the release stage, how could you ensure quality? Of course, we do have tests that are run in different test environments as well. And these are reported through these Slack channels. Again, this is a very useful thing wherein you can add it to your way of collaborating within teams so that it helps in quicker access and taking, I mean, it helps in better monitoring as well. And yes, sanity tests are run again on production environments and also we do have tests run on a subset of users alone and of course the feature itself would be, it could be controlled, meaning like we do have feature flags which helps us to deploy for a percentage of users and it could be increased. So that's something that helps in better quality as well. And in terms of exploratory testing, we do have some, there's a feature called review apps which I didn't mention here, but it helps in spinning up a dynamic instance. Even before your code is actually merged, even when the code is in the merge request stage during code review, you could actually spin up an instance which has your code plus the current state of code itself. So that way you could do some sort of exploratory testing and you can take a look at how your feature is actually looking even before the code is actually merged to the main branches. So that way it also helps in the quality of the code. Alright, to summarize, all that I'm trying to say is quality is everyone's responsibility and I think that is the mindset that we need to have and work towards it. And then what is the responsibility of quality engineering? Quality engineering is actually responsible to facilitate this testing and quality at every stage. And yeah, and testability is something that all of us right from the designing and the development phase, everyone should be mindful of to build a product in such a way that it is easily testable. And yes, quality should be baked at every feature of the pipeline itself. That's pretty much it. Any questions? Yes, the issues are used throughout the life cycle wherein the issues are used for the initial discussion as well. And again, if, as I said, like fully remote and most of the discussions happen async and having it all in the issues that facilitates this as well. And it doesn't end there. Of course, we do have the other features mentioned there as well, right? The milestones and epics. So milestones, basically we have a monthly release. So milestones help us to plan the upcoming releases as well. And all the, and also there are features specific to release, like wherein you could just tag a release and pick the changes that you want to release. So all of that happens based on these issues. So all the features are actually tied. The issues are used not just for discussions, but it's used until the end, until the code is actually deployed. You can, when you look, take a look at the issue, you will see the complete state, like we do use labels as well. You can see the different stages through which it has gone. What it is in, is it in the planning phase or in development or has it been deployed and stuff like that? Yeah, I have my colleague here as well, Albert. So yeah, that's something that we constantly keep trying to. So in labels, there are, there is a specific type of label called scoped labels, which actually has helped us a lot. Meaning like, for example, if there's a bug, you want to call it a bug, but there are different stages in bug, right? Maybe it's a valid bug or it's a bug, but it would not own fixed bug and stuff like that. You could actually have scopes on kind of a label within a label kind of thing. So those scoped labels has helped us. And yeah, I think that's one of the main things that comes from. Yeah, label hygiene is something that we constantly keep working on. Thank you. Thank you.