Operations | Monitoring | ITSM | DevOps | Cloud

One of the most important phrases of DevOps practices is “Test early, test often.” It’s crucial to perform functional testing early with unit tests and integration tests. But it’s equally important to perform non-functional testing. That means you should have performance tests. As markets become more saturated with each passing day, you no longer have the luxury to postpone performance testing until all features are developed.

Performance testing measures how well systems perform when subjected to various workloads. The key qualities being tested are stability and responsiveness. Performance testing shows the robustness and reliability of systems in general, along with the specific potential breaking points. In this tutorial, you will use k6 to do load testing on a simple API hosted on the Heroku platform. Then you will learn how to interpret the results obtained from the tests.

Many development teams start their CI/CD journey with a local build box (or six) that run their tests. In several mobile teams I worked on, for example, we had a few Mac Mini boxes with physical devices plugged in that we used for running local UI and unit tests. Eventually we migrated to a cloud-based solution, which brought us much greater stability and many new features. But moving to the cloud also meant our local hardware was obsolete.

Testing early and often throughout the software development process (shift-left testing) helps teams stay agile and reduce the time it takes to validate and release new updates. Datadog Synthetic CI/CD Testing enables you to implement shift-left testing throughout your CI/CD pipeline so that your team can prevent faulty code deployments from degrading your end user experience.

gRPC is a remote procedure call framework that has been widely adopted among cloud native applications. It is an attractive choice for engineers needing more capabilities than what REST APIs provide. However, observability and testing tools for gRPC are few and far between. Because of this, triaging or understanding application behavior is potentially time-consuming and overly burdensome.

Modern-day applications aim to cover a wide range of users’ needs in a flexible and scalable manner. The software development landscape is moving at a fast pace, and the competition is so fierce that a business simply can’t afford to offer a low-quality product. Thorough testing of both functional and non-functional aspects of a software application has become an essential step in the software development process. It ensures that users get the best version of your product.

One of the common challenges when doing performance testing is the difficulty of correlating the metrics of your application with your testing results. Having available QA, infrastructure, and application metrics together allows engineering teams to better understand the behavior of their systems during the testing, helping to detect and prevent potential issues in their applications.

Many of the multi-faceted applications development teams deploy every day are loosely coupled and every service exists to power another service. Most teams developing fullstack applications know that testing the communication between these services essential. Part of the process is testing HTTP request endpoints, and this tutorial focuses on exactly that. I will lead you through learning how to extend the k6 framework to test our HTTP endpoints.

When your development team is under pressure to keep releasing new functionality in order to stay ahead of the competition, the time spent on quality assurance (QA) activities can feel like one overhead that you could do without. After all, with automated CI/CD pipelines enabling multiple deployments per day, you can get a fix out pretty quickly if something does go wrong – so why invest the time in testing before release? The reality is that scrimping on software testing is a false economy.