Here at PSL, one of our secret weapons for delivering world-class software is performance engineering, a discipline that requires a broad focus on product performance during the entire software development lifecycle in nearshore outsourcing.
The approach is different from regular quality assurance and testing, which is mainly centered on functionality. Instead, performance engineering is about improving how well that functionality operates, the costs of the platform that runs it and its stability when the number of users is scaled up.In a nutshell, our developers are always thinking about the quality of what will be delivered, not just fixating on which feature or service to include.
Our performance engineering team consists of 25 experts, including myself. When the team starts a project with a software outsourcing client, we determine the number of users the solution will have, the volume of data, and the cost of the necessary platform or tools. These factors must be outlined to allow for the automation of performance testing, which is core to the performance engineering process.
Performance testing helps to gauge the effectiveness of non-functional requirements, like the app performing at a certain speed or similar aspects that are not generally visible to the user. For instance, once an app has gone live it becomes very difficult to emulate high user traffic loads, so it helps to automate certain testing scenarios beforehand, such as how the app handles 500 users at once or 1,000 transactions per second.
Continuous performance testing helps us run these scenarios on a regular basis, allowing us to execute them more than once a day, or whenever there are changes to the code. The benefit of this approach is that we can see if the app's performance is improving or getting worse, and make adjustments straight away if necessary.
Performance testing is not without its downsides. Managing data is a huge challenge as it usually involves millions of records. We've also found that online testing tools are expensive, often charging per individual test, which can mount up quickly when performing these tests multiple times a day.
Furthermore, we have found that these tools are not very good at managing performance numbers across multiple apps, modules, or transactions, so after a few months, it becomes difficult to view or analyze the thousands of scenarios that have been tested.To get around these challenges, PSL has developed dynamic tools that can manage performance data, keep track of daily changes, create a scalability model of the application, and fill gaps in the automation. Not only does this solve all the issues we have with online tools, but it also helps us pass on the benefits and cost savings to our clients.
In the markets that we serve, we often find that customers haven't heard of non-functional requirements, or they don't become a concern until their customers are using the product. Non-functional requirements are not normally considered features o
We've found that by implementing a visualization capability into our performance testing tools, we can show customers the status of the product's performance and show them results in the first 2-3 weeks of execution. This allows them to see exactly which non-functional requirements are performing well, giving them the knowledge they need to request specific improvements to an app.
This is the first stage in the performance engineering delivery process, with the end goal being an overall improvement. This visualization and sharing of results have helped clients to establish realistic non-functional requirements, ask the right questions, make the right decisions, and set realistic goals.
Once customers have seen the results of performance testing and agree to fix any issues, we start working with the development team on a "shift left" process, which involves applying performance engineering to the beginning of the product development life cycle.
The shift left process provides the product owner, architects, designers, developers, QA testers, and operations team with the best practices and tools they need to build the proper metrics. With that, we can show everyone the numbers we are getting from the performance testing, help them understand the metrics, work with them to analyze the source code, and explain how they can approach the technology from a performance perspective.
By analyzing performance in this way with diagnostics, developers can determine which part of the code is producing issues, and identify where they need to work to improve the application. Without this approach, they would often have to rely on a trial and error process to uncover issues. Performance engineering and testing help them work in a more sophisticated way and fix issues much faster.
In the end, software will always have bugs, but performance engineering and testing practices are helping us take a more efficient, proactive approach to fixing them, vastly reducing their impact on the solutions we are developing.
Want to learn more about leveraging performance engineering with PSL? Give us a call!
By Carlos Zuluaga, Head of Performance Engineering at PSL