 This is Mario Casquero. I am a software quality engineer from Red Hat Spain. And, well, this is my first time at DEF CON here in Brenno. And also my first time delivering a topic in a conference. So I hope you all will enjoy this lightning talk as much as I will do. Let's start. Today's agenda includes first quality testing, the basic concept, and some different types of tests that every quality engineer runs in the day to day. Next is how carbon emissions and clean electricity are directly related to a developer's work and how can those emissions be reduced. Next is what is carbon-aware software, how does it work, and the two main solutions used by retail companies. Finally, I'm going to present one of those solutions and how it is possible to make use of it in order to make not only quality testing carbon-aware, but basically any other task. So quality testing is mainly what we do as quality engineers. We keep some continuous control onto a product with the idea of reducing or even better eliminating the possible errors before this one goes to the market. The way we follow to achieve this is through a bunch of different tests that includes stress and regression testing, smoke testing, negative tests, sanity testing, and so on. So let's go with a little introduction for each one. Stress testing, it consists in performing any supported operation by the product in conditions of insufficient resources such as memory or disk space, high coherency, denial of service attacks, etc. For regression testing, the idea is to run tests over one or more features already existing in the product because they have been modified. Depending on the resources, the priority, or just the time, it is possible to test all the existing cases or prioritize some of them according to the changes that have been made. Smoke testing is simply the necessary set of preliminary tests that covers the critical functionalities of the product. First of all, starting the application. In case of failures, the software release of the product may be affected, so they are quite important. Testing ensures that a system handles properly, for example, unwanted data input and unexpected user actions. And sanity testing is similar to smoke testing, but it goes deeper because it covers more than the critical functionalities. Doing this over a stable build, typically related with the new or fixed functionality. It can be also understood as a subset of the regression testing. So, as everybody knows, carbon emissions are one of our current and biggest problems. A lot of companies are trying to reduce them, as it is the case with Red Hat. We will intend to reach net zero emissions by 2030. Nowadays, it is possible to reduce this carbon footprint inside a different time or location for running things. Because most of the electricity is produced by burning fossil fuels, but there is a percentage getting bigger and bigger, produced by renewable and cleaner sources such as solar and wind. So, if we make our software conscious to do more when the electricity is clean and do less when the electricity is dirty, that means produced by fossil fuels, then that's called carbon-aware software. If we are looking for our software to be aware of the carbon emissions, we need to start thinking about real data emissions and probably the most important forecast. Keeping in mind the provenance of electricity that is already measured in grams of carbon dioxide per kilowatt hour, it will be possible to select a time in which this amount is the lowest in order to run, for example, some stress testing, as I mentioned, that usually consumes a high amount of energy. If it also keeps the possibility to run things at different locations, the real data emissions or the forecast can be checked depending on the source selected. All of these are actually possible by the two following solutions, this time on electricity maps. For this lightning talk, a city's only 15 minutes, I will be focused on electricity maps. And the truth is that it is not totally free, they provide a free month trial, so it is enough at least to give a try, as is my case. Electricity maps work through an API, and the following endpoints are provided. Those are carbon intensity, power breakdown, power consumption breakdown, and power production breakdown. The last two ones are merely forecasts, so they do not offer real data. For today's purpose, the most interesting is the first one, it is carbon intensity. First of all, we will be obtaining the sound code for the region we want to know the current carbon emissions or to read the forecast. This is a public API, okay, registration is not needed in this case, so everybody can trigger it. If we take a look to the response, it is composed by a huge list of the supported countries and regions. I've summarized this one a bit, and we have to look for the one we are interested in. In this case, we have Chica here. As a clarification, we are only interested in the sound code, so for Chica it will be CMZ, not the sound name that is already Chica. Once we know the region, reading the real data emissions from the carbon dioxide will require the following endpoints. You will see the latest at the end of the endpoint and the sound code obtained previously. Taking a look to the response for the selected sound, in this case Chica, we have this carbon intensity value. This number will be lowered when the electricity is cleaner, that means produced by renewable sources, and higher when more fossil fuels have been used. This is actually measured in grams of carbon per kilowatt hour. One more thing, if you want to disable estimations for this kind of endpoint, you can just include the query parameter in the request, so include disable estimations, set it as true. To obtain a 24 hours forecast, the following endpoint has to be used. You can see the forecast at the end of the endpoint, and again the sound with the region we have obtained before. A real application for this could be to prepare an automated process that given a region, as it could be Chica, it will select the desired time based on the API results for sure, when the carbon intensity will be the lowest. Taking again a response during all the 24 hours forecast, this has been summarized again for sure, a real response will be so much bigger. We have 337 grams of carbon dioxide per kilowatt hour at this daytime, so that is the ideal time for running something like a stress test. That's it, that's a proper way that we can contribute to make our software aware of carbon emissions. One more thing, they provide cold snippets for making it easier to the final use to integrate these kind of endpoints. For example, you can obtain the cuckoo man, JavaScript functions, or a Python script among many other things. That's all, thank you so much for your time. If you have some questions. You are asking if the forecast changes a lot. Actually, it's true then because it uses estimation that is actually providing data in real time. It could change from maybe 10 hours or 12 but in the near time it should be quite confident. I'll just give you one try. Providers, how to go and so on, match the basic life. They take control of their variables like traffic, because I know in Google that they provide weather data, for example, to enrich the whole CO2 perspective. I don't have as much as experience with electricity maps as for this case, but I think not all variables are included in the estimation procedure. I also saw that it changed between America and Europe. For Europe, there are some extra data that you can keep in mind in order to provide those values. For America, it's not. It will depend on the region, and I am not sure if all the variables have the traffic or the way the electricity is produced are included. I am not so depth in electricity maps. Any more questions? Yeah, because that way you are consuming energy when it is produced from something like the sun or the wind. So you are not directly contributing to provide more CO to the atmosphere. We are out of time, we can discuss outside if you want. Thank you so much.