 Hello, hello, and welcome to my presentation on my Kubernetes applications require a new approach to testing. A little bit about myself. I'm Bruno Lopes, I'm the proud leader at Tescube. She's a Kubernetes native framework. We are going to show to you a little bit later in the presentation. My background is in software engineering. I was a researcher in the data science space for some time. It also, a lot of DevOps work and further past several years, I was focused more on product management but always in the space of Kubernetes. So I guess I can say, I've seen a lot of different solutions in Kubernetes. So we can talk today about what are today's challenges of application testing in Kubernetes. I think the first one we can discuss is that the large majority of testing frameworks are not built with Kubernetes in mind. So it's not that, it's not a good or bad, it's just like basically our tools are designed, testing tools are designed to test specific scenarios. For example, load testing for Kisex or Postman is built to test the API. So they are not a tool that solves all the problems for you, there's a lot, you need to integrate them with your CICD pipeline. You need to understand like, how are you going to run those tests or what's the authentication like and a lot of different aspects. And they were running Kubernetes always an afterthought, not something that it's always designed like from the ground up for the tools. The second issue is that our plans always tend to get complex and they'll get too complex if you don't constantly think about basically how to design it. As the business grows, there's more teams, there's more test use cases, you'll find the need to change your pipelines at more steps doing a lot of things. So they'll get too complex. So that's really can get out of control. So something that you really need to take into account. Another issue is the restricted access to testing environments. Not just testing environments, but also production. So any environment that you want to run tests on is not always the case where you have access for everything basically to the applications that you are testing, the data, the logs and everything. So also is an issue that especially in big corporates that happens is that getting that access might not be as easy. And another one is synergy. So if you are really serious about testing and you do load testing, you do UI testing, test the API and do really care about the quality of your solution. You'll use different tools for that. And there's not a lot of synergy between them. Each one, let's say you need to create, if they're running Kubernetes, you need to create Docker images with all those dependencies. So you need probably to create the Docker image for each one of these tools with different configuration files, different scripts, different steps of the pipeline. And there's like everything will be done by you, but it's not a lot of those synergies. Most of them report the results of the tests in different ways, because there's not really one good way to do it. It's like everybody has their own opinion on how to report the results. So you don't see a lot of synergy there. So what could be a solution for these challenges? And so the new approach we are calling is cloud native testing and it sits on three principles. So first one is scalability, flexibility and automation. What you think of scalability is that you are, if you run your tests in the cloud, in the cloud basically, you expect them to scale. You expect that as you do more tests and your testing needs also increase, so you will be able to scale. It's not like that will not be an obstacle, a big obstacle of sorts. And so in this case, if you run in Kubernetes, Kubernetes is really made to scale things as you know. So there's like an advantage if you choose to use Kubernetes for example, but the cloud native test does not necessarily mean that underneath is Kubernetes. Another thing is flexibility. So you are supposed to adapt to different testing needs, be it integration test, end-to-end test, load test, security tests, all kinds of tests. And based on the business, you might choose different approaches and different ways to do it. So it should be flexible in the way that you can basically design that architecture. And yeah, these should adapt to you, not you that should adapt basically to the tool. Then the other part is automation. When you think of automation, you can think of CACD, right? It's probably one of the biggest tools or frameworks people use to automate things where the development lifecycle is, you can see them, you can see it in the CACD pipeline. So you basically build a code to test it, to deploy it. And then if you have testing in some environments, you run tests there and if the tests are okay, you might promote them to different environments and CACD frameworks are commonly used for that purpose. So this part of automation should not be complex. So that's why I gave the example of CACD earlier. CACD frameworks get really complex, but the automating tests on the cloud should not have that complexity. So with that in mind, with these principles in mind, we will test Q. And the goal really of test Q is to make your other test cloud native. It's a Kubernetes native testing framework that you can use to run your tests, to see the results and basically to manage everything for you where you start the tests as part of your Kubernetes cluster. And where does it take care of the heavy lifting? If you run tests in the cloud right now, you might, I'm gonna guess that you have a Docker image with all the dependencies of the test and then basically you have the test files that are imported and then the CACD basically takes that Docker image, takes the test files, run it and then you have a step in your CACD where you see the results. So you need to containerize, right? In test Q, you basically don't need to do that because it's already native. You don't, in fact, it is native. You don't need to spend effort to make an image and containerize it so that it can run in the cloud. It's, yeah, it's already done for you. The other aspect is scaling. As I mentioned, like Kubernetes is really good at it. So that's why one of the reasons it was chosen that for registration, right? So basically test Q leveraged all the capabilities of Kubernetes so you can scale out all your tests. The other aspect is restricted environments because sometimes testers don't have access to everything on that environment. As I mentioned, you could, you can basically put test Q in a cluster. So the test Q ball is running in the cluster and then instead of having access to the applications, you just have access to test Q and then test Q, it's your administrator for to run all your tests. Test Q will basically have the access that you don't have and then you can just see the results in test Q. And yeah, and you don't need to write scripts or code boilerplate to run anything. You just, everything comes working out of the box. And it's like very flexible too because it's like, it has good defaults and it can run all the tests, just take them, but it's also configurable. So edge cases and like really specific use cases also always possible, of course. And so right now you can take a lot of different testing tools that we already added support or support for Cypress for UI tests, Q6 for load testing, Postman, you can create your collections, test the APIs and some checks there. You can then import that collection to test Q and just run that and it's that easy. For SAP UI, we have many more. Some of them, I think most of them actually were contributed by the community. We have artillery, Q-Pag, Ginkgo, a Ginkgo executor as well, Maven and Gradle. So it's very easy to add. You can just check this link here on the bottom right and you'll be able to see basically what's the executor like. So it requires just a little bit of coding, YAML programming and yeah, it will be the good to go. So continue on the topic of improvements to ICD. As I mentioned, it can get really complex. On the left side, you can see a diagram basically that just shows some steps in the pipeline where you build, deploy and then you want to do some integration tests. You have API test one, API test two and yeah, a UI test, for example. And as you want to add more tools or more tests or they are different flow to your tests, you need to change the CI-CD. You need to add steps and conversions there. So it means that they are coupled. The tests that you are testing and CI-CD are coupled. So basically the complexity of your tests make the complexity of your CI-CD also grow. In the example you see on the right, so basically it's like a ERC-ICD with test queue. That complexity gets removed. Like so testing is not really a big part of your CI-CD and all your tests start living in the cluster with test queue. So because the test queue is there, it starts your tests, your tests are stored as components resources actually. So it's something called CRDs. And so then you can use your pipeline to trigger the test if you want to and then just basically a call the test queue saying test queue run my test. And that's it. Is that easy? And you just test takes care of the whole thing. And after that, so you can basically orchestrate everything, get the logs, the configurations and you also have a UI where you can see all these equations and basically it's like you're a plane of glass. You can see what's the state of your cluster. So let me quickly show it to you. Here you have basically all your tests. So this is a live environment, demo.test.qbio. You can check it out right now if you want to. So here I'm gonna add the test. Let's say I can call it open SS like test queue g6. You can see here a list of all the different types of tests that are supported. But again, it's very easy to add more. And it is a sample I'm gonna use g6. And then here you can select the source. Your tests can come from Git. For example, you should version track our test of course. So it's most of the cases you are going to, especially if you want to use g6. Most of the cases you are going to specify a Git directory. For example, if it's like a group of tests, imagine to have a folder with a lot of test scripts, you can just import the directory and define it like that. And then basically if it's a private repo, you can define the token, the Git token, and the repo and the branch and the path and then test queue will fetch that goes from there. You can say a Git file, a file directly from your computer or for example here, just really a string. And for this example, I'm gonna use the string example. So I'm gonna copy and paste some tests that I already have here, which is just a simple load test that is going to do some load testing on this URL. And we are going to create it. So here now you can see, yeah, we see noise equations. So I'm gonna press run now and you'll see basically that it's running. So now it's scheduled, there's a shopping component that took this file that we added and just running it because there's a key six executor. So basically it's an executor that has key six dependency there and runs as far as. So now it finished. You see the logs here produced from key six and yeah, you can see basically everything. So here you can see basically the list of all the tests. So this one on the right was the one that we just created right now. See all the tests, the past all the tests that failed. See the icon for different testing tools like this one is for postman, key six, so I press here. It's also possible to have test suites. In this example is a test fit that it's always failing. So you can specify different steps in the test suite. So you can have tests running in sequence and yeah, basically you can specify if one of them fails your test suite fails. And yeah, it's also integrates with webbooks and Slack. So you can basically plug this in into your Slack channel, into other tools that you use and just get notified when things are failing. So that's what you can use the UI for at this stage. So I think that's it for the demo. Yeah, thanks, thanks a lot. So as I mentioned, we are open source. You go check out our code that you shop, github, slash, github, slash testcube. We have also this course channel, basically our community and engineers are across almost all time zones. So just shoot the message there. Somebody will reply to you shortly. If you have questions or just want to say hi. And also follow us on Twitter. We pretty much post a lot of news that we test you when we have a new testing tool or a new challenge that we tackle. You usually write a lot about that. So we also, it's very good to check that out. Cool, that's a lot. See you next time.