 Hey guys, welcome to this video about conquering Kubernetes test-based challenges. So for those of you who don't know me, I'm Bruno, I'm the product leader of a really interesting project called TestQ, which is a test framework for Kubernetes. My background is in software development, the science, and DevOps as well. And for the past years, I've been managing Kubernetes products. Mainly, the biggest one is TestQ, but we are going to talk just a bit today. But mostly on this video, we are going to go over today's challenges in testing Kubernetes and what are the big advantages of adopting a more cognitive approach to testing, which is not commonly adopted today, like these processes are a bit old still. And by the end of the video, we are going to have just a quick look into TestQ to give an idea of how can you improve your testing in the cloud. So we can start with the challenges of testing in Kubernetes. The first one we can go through and you can analyze is that the large majority of testing frameworks are not built with Kubernetes in mind. What does that mean is that each testing tool, like for example, we can give an example of these ones, they are made to solve particular issues with testing, like for a certain use case. In the case of Q6, it's really built to solve load testing, so I press like UI or end to end and Postman API. These tools do a job and do it very well. She's no do their own type of testing. Postman is really good at API testing. But the common pattern we see here is that they are not built exactly with Kubernetes in mind. So after you create the tests, you have a big issue on making the transition into OK. I wrote the test, now I need to run them. And that part of running an orchestration gets more difficult because the tools are not meant for them. So what happens is that when you try to automate and make these tests as part of your development lifecycle and you build your code, you want to test it, and then you want to release it to your customers. When you see and you think about automation is, you think of CICDs, and they can really increase in complexity the more tests you have and the different tests workflows you have there. And it can become a point where it's very difficult to manage. You can have many people just to manage the automation of tests. So you become less willing to try new tools, to change your workflows, to expand a bit, and that can really become a blocker and also impact your quality. Because when companies don't feel very willing to implement these workflows because the cost of implementing them and maintaining them, it's high compared with the perceived value, especially from business, then people won't do it. And that's, no, the cost of the software is going to be poor. And another issue is that then the test gets hard to debug. So imagine in a cloud environment where you have multiple environments with multiple tests and many different microservices, right? Then the test fails. And then you want to know what happened, which environment, what are the logs, what might be the issue. It gets very hard to track as your project goes more in complexity. If you have just one application, simple application running on a container, it might be fine. But if you have Kubernetes clusters and or multiple ones, especially in many microservices, that's definitely an issue. And the other thing is your environments usually are not accessible everywhere, right? You have sensitive information that you don't want to share either public or even with all of your organization. Maybe it's just a thing you don't want to give access to everyone, that environment, it can be for the data issues or you just don't want everybody to mess up the system, right? So you just give some people access to that environment so that you don't have anybody that might not know how to use it properly break it, right? So you sometimes just receive the access and just put it on that side. And another thing is, those environments are not easy to set up, right? Especially because they need different nodes, different configurations. So it's not that your testers can do this. Usually it needs people that make their job creating clusters and environments and set up the environments. So it's not a straightforward. So let's go into what are the three pillars of cloud native testing and what they mean. So there are certain advantages of having a good mindset when you start implementing testing on the cloud. You can use the old days of having everything on the pipeline, creating custom scripts, and do everything from there. And sometimes you might think of testing as an afterthought, like something that you can do just a bit just to make sure that your code is tested just as a sanity check and you don't care much about what goes to production. Of course, that's the implications. And if you implement testing from the ground up in a good way and you have a good methodology and processes, you are going to find that you gain time. So the earlier you implement a good testing process, the more time you save along the road. Of course, you should not go crazy with it. Otherwise, you might spend more time on thinking about testing than actually building your product to your customers. So that's why the cloud native approach is good, because it's supposed to be scalable. You are supposed to have an easier time integrating it with your testing tools. So your testing tools should be something that works seamlessly on the cloud. You should not spend a lot of time just making your tests work in a cloud environment. And of course, they should run fast. It should be fast to create them and integrate them into your development workflow. The second pillar, let's say, of cloud native testing, it's orchestration. So one thing is just executing the tests right in a scalable, easy way. The other one is the complexity of your workflows. So having one test is one thing. Having, let's say, a test that needs to execute before several different tests. Let's say you might do load testing, then API testing at the same time, and then you do UI testing, and you can have different workflows and different tests running at the same time. Adding things like advanced test orchestration, it's super important to have it figured out on your cloud environment, right? So it should be quick. You shouldn't spend a lot of time here. The more time you need to spend in testing, the less time that you spend developing a better application. Of course, you just want the results of having good testing, but the time you spend there, you shouldn't take a long, a lot of time here. And it should be flexible. You shouldn't see big blockers and obstacles in trying new tools. One thing that we observe in the trains that the companies that talk with us at TestCube is that they have some tools that they use to test their code, but the notion of having another testing tool means that the testers need to know how to use it. They're automation engineers and DevOps people need to know how to automate it and don't integrate it on the pipelines. So it's not as easy decision, right? When you take a cognitive approach and everything is containerized, that won't be an issue where you can adopt new testing types, new testing tools and do work flows in a way that is not costly for your company. And regardless of testing type, things work similar, almost the same thing. And the thing you need to see is that all of these tests and all of these process should speed up your deployment process. You shouldn't add testing steps to your pipeline and then realize that you deliver less times and your development life cycles increase. So instead of delivering, let's say every week because you are so focused on having to test these things that then you release less steps to your customers. You should test more, yes, but without making your life cycles or release cycles longer, it's possible to have both. So that's something that you can take into account. And the last one, last but not the least is observability. So you have these complex workflows with many tools and different environments, different microservices, and it runs in the cloud, right? So you need to give a really good access to everybody on the team to see what's the status of the test, what's the status of the applications, the environments, everything, you know, running well, is anything broken. It should be easy to debug what happens. So if a test fails, if it's having access to the logs, having access to the pods, like see what happened there, it's very important. And also on top of that, not only for development environments, but for production itself, you should have observability on all your production environments are actually running. So you should have also some tests there. Of course, they are not the same ones that you do when you run them on staging or development clusters, but you should have some there, definitely encouraged. And analytics as well. So especially if you have testing teams that have been creating tests for your product, like for several months, you arrive into a time in place where you want to analyze basically the performance, like is your test making your development life cycle longer, like as I said before, can we improve our test somehow, which tests are flaky or not flaky, like you can definitely analyze all your testing and their performance. So that's also something that is very important because it's not just about running the test, you want to know exactly how they are running and the time they take and et cetera. So with these characteristics in mind, it is a challenge that we spoke about. That's why we created TestQ was to solve basically testing in the cloud and to be the Kubernetes native test orchestration and execution framework so that developers and testers are not blocked with testing and they can test in the C on the cloud. So if you are a developed person, that is just wants to automate your system and give everybody in your company access to creating tests, running them in Kubernetes and have visibility on it. This definitely like something that you can take a look. So yeah, we are a CNCF Silver member. We have more than 30,000 downloads and now each week more and more. So yeah, if you want to give us a try, let me explain a bit how these concepts of no cloud native tests work, especially on if you have an automated system, like you run your test from a CICD, the traditional method is that you build and you have different steps even before you deploy, right? You can do links, you can do code analysis. So at some point you are going to, you want to deploy to an environment, to a cloud environment where you can run test them. So, and what you do is after you deploy on the traditional way, you run several steps where you have scripts that kind of orchestrate to them, prepare the data for the environments, they do a lot of stuff around the test. And then of course, if the test pass or fail, the pipeline will fail too. But everything, all the complexity is implemented on the pipeline and then the cluster is just have the application and then all the complexity lives in the pipeline which is very, will be hard to change with time. So the cloud native approach is that your tests become kind of part of the cluster so you run it kind of in a GitOps manner. So it comes from your, the states of your tests come from your repository and your cluster and your pipeline just says, just this size, is they want to run the test or not and they are not in charge of having all the complexity there on the pipeline. In case of test queue, you will start the test in the cluster, the test has started the Kubernetes CRD and then from your pipeline, for example, you can just trigger the test. So basically your pipeline talks with test queue and test queue runs everything for you. And because test queue runs inside the cluster, you can run in a more secure way because you don't have to expose your applications, you leverage test Kubernetes to scale everything because everything runs as a Kubernetes job. So you don't have to worry much about scalability or performance issues there. So the best way to understand it is basically to have a look at it. So I'm gonna do a quick demo for you. So this is the test queue dashboard that you can experiment. So you can just go here, like if you have GitHub or GitLab can just log in using your credentials. So I'm gonna continue. So here I already have one organization prepared for us. So as soon as you log in, you have an organization prepared and you have like an environment that you can deploy. So you can deploy these to your cluster using an L command or RCLI and then you have like a pod running on your cluster that is going to run all the tests for you. Here I already went ahead and deployed these on one of our clusters. So now I have these environments. So I have these UI connected to an agent running on your cluster. So we just come here and add a test. So here I'm just gonna create a simple key text test except ABCB and then a selected pipe. So here, test queue already provides support out of the box for many different kinds of executors like different test types. Just gonna select key six and then gonna select where's my test file. So you can select test queue to go into your Git repo and then fetch the file from there. You can upload a file or you can even place a string like a really a JavaScript code. So because of key six because it's a scripting language I'm just gonna, for the demo sake I'm just gonna paste the test. So I just wrote some JavaScript code that tests an endpoint and it fails after the time. So just a simple thing that I can create. So I just created a test. Now let's go ahead and run it. So as you see here, now test queue just scheduled a Kubernetes plot and now the Kubernetes schedule is probably putting the pod in one of the nodes and then running it. So here you get the logs in real time of everything that happened. So you get the logs directly from the testing tool and then you can click see what's happening there. You can run it multiple times. So you get to them all the insights about the pass file ratios, the execution duration and along if your tests passing or failing. So you can run as a lot of them all of them and all at the same time and test queue just makes sure that everything runs seamlessly and gets the results for you. You can run this from your CICD system. So if you want to trigger the test we have integrations with any CICD system. And from there you basically connect to test queue and you can run this from your computer you can run this from CICD system as well and you just trigger the test and do everything. As you see here, all the tests are defined as CRD. So if you copy this and deploy to a cluster it will show up here. And we deeply encourage all the people to start the tests in their Git repos and apply them. So you can provision or the provision Kubernetes clusters at will and you can just deploy the tests and you have all the tests set up always prepared to run things. Another example is like, so this is like how do you, is it good test, right? So here I'm going to give you an example of how to run a test suite. So my test suite, ABCD. And then when you have more complex workflows you might want to have like different tests like one after the other. Let's say you want to run multiple tests in parallel. This one is like just to put a lot of testing and then you can have like one test after the other. So this can be any type of test, can be no API test, UI test, et cetera. So here I'm just going to add a few. I'm going to add like a few more steps here and then I'm going to press save. So now we can just come here and you can run the test suite for us. And now everything is running like being orchestrated by Test Cube. So you can see that these three tests are running in parallel. Then when these three finished we are going to run these two ones and then we are going to run this one. And then of course you can click on any of the tests and you jump right into it. And you see like all the tests in size, like what happened here. And yeah, you just see all of the executions at time gives you a really good overview of what is happening basically on your cluster. And for any test type that you don't see supported here you can just go to our docs and create a container executor. So what you have to do is just create a docket image with your testing tool added to Test Cube and it will work for you. So yeah, so that's like the quick introduction to Test Cube. We have like a lot more features here that you can use even like one recent one that we released where you have AI inside. So we allow people to see like what's happening there. So for example, you can just click here instead of going to the logs and basically tells you that the status codes is not returning 200 and gives you suggestions on what to do. And you have like many more features for integrations like webbooks, like status reporting and all of that. So yeah, it's pretty much a tool that is easy to use for any testers, the DevOps people that really wants to test in Kubernetes and wants to speed up their development workflow. So yeah, like give us a try, go to Test Cube.io. If you have any questions about Test Cube and how to use it, go to our Discord channel. We pretty much are there all the time answering questions or if you want just send me an email or book a call with me and I'll be pretty happy to answer your calls.