×
THANKS FOR SIGNING UP!
We’ll make sure to share the best materials crafted for you!
4 minutes read
Leveling Up Your QA Engineers
Written by Ismail Egilmez
Business Development Manager @Thundra
An application is only as reliable as the testing it undergoes. While anyone can throw together a quick server application and call themselves a web developer if there are too many bugs, users will vote with their feet. Finding and retaining users, on the other hand, requires quality software.
By introducing testing into your development process, you can ensure that your users find the value that you provide—not the bugs that creep in.
Testing, like everything in software engineering, grows in complexity as the product evolves. In order to facilitate your SDETs and QA engineers as they manage this increased complexity, you’ll need to focus on their skill sets as well as the tools that let them observe your application in the wild.
In this article, we’ll look at the challenges that test engineers face as their applications grow. We’ll also discuss strategies to mitigate those challenges while enhancing your organization’s testing excellence.
Expanding Focus
Junior test engineers typically have a narrow focus. They become familiar with small applications quickly, identifying and documenting holes in the system through rigorous automated and manual testing. This works well enough until an application reaches advanced levels of complexity.
Growing applications can have complex interactions and be hard to understand. These interactions can be contained within a single repository, or they can be spread across multiple component services, each of which contributes to the product that the user eventually sees. As these connections and interactions grow, the ways in which they need to be tested also grows, making system issues harder to track.
Furthermore, as the software engineers add complexity to the application, they also add institutional knowledge that can be hard to communicate. This complicates the system diagram and makes the job of test engineers far more challenging.
We can’t expect every SDET and QA engineer to understand the code base as well as the software engineers who wrote it. That’s why the testing organization should be exposed to the code interactions, allowing them to verify and troubleshoot CI test failures at a more technical level.
Observability Is Key
The key to solving the problem of growing application complexity is observability.
Smaller systems are self-contained, and their tests cover a clearly-defined set of API interactions and HTTP responses. This allows test engineers to have a deep understanding of the application and its idiosyncrasies, effectively testing all of the system’s edge cases without extensive assistance.
More extensive applications, however, end up with multiple services, each of which may rival the complexity of a simpler application in their own right. In these systems, it’s the flow of data through the application that’s being tested. This means that test engineers need visibility into the underlying components of the application to verify its performance.
By improving the observability of both the application’s automated tests and its distributed transactions, your SDETs and QA engineers will be better equipped to troubleshoot test failures effectively. This increased observability allows your test engineers to be more thorough and accurate in their bug reports, improving their time-to-resolution and decreasing test failures.
Finding the Right Tools
Enhancing observability into your test suite will require implementing the right tools. While being able to test the application in production is crucial for test engineers, the real improvements to observability happen behind the scenes.
To get started, exposing the output of your automated tests will allow QA engineers to quickly identify which tests are failing and why. This is generally handled through CI tools such as Travis or Jenkins, both of which offer the ability to report on automated test failures as they occur. These tools also provide access to the failing builds, allowing for technical troubleshooting and log analysis so your team can identify the root cause.
Observability into distributed transactions is the best next step. SDETs and QA engineers with the right visibility can quickly identify problematic microservices in a complex transaction and narrow down the cause of an issue. Luckily, Thundra’s in-depth distributed observability tool, Foresight, provides this visibility into your CI pipeline, as well as the remote debugging and tracing capabilities you’ll need to maintain your application going forward.
Gaining full observability into your distributed application requires effort from your development team and is an added cost to your organization, but these tools directly contribute to your team’s ability to fix issues as they arise. Ideally, your engineers will work observability and automated testing into the development plan. In the event that testing is neglected during development, however, the need for tools that analyze application behavior becomes critical.
Over time, the added expense of this observability is eclipsed by the resources saved through an efficient and effective testing organization. Spare your team the headaches that arise from poor resources and plan for improved observability—your engineers will thank you.
Levelling-Up Your Test Engineers
In addition to providing improved observability for your application through proper tools, you can improve your quality assurance by developing the capabilities of your team members. Below are some suggestions for improving your test engineers’ skills and helping them grow their awareness as your application scales:
- Teach your SDETs and QA engineers about the architecture of your system. Show them the design docs and UML diagrams that led to the current product, and answer questions about why specific choices were made. This will help them understand why things behave the way they do and improve their knowledge of how the system functions at a base level, giving them more tools for debugging integration tests.
- Improve the ability of your test engineers to observe requests as they move through the system. This includes both implementing tools to allow for distributed tracing, and training your QA engineers on how to use them. Additionally, pairing testing engineers with software engineers to walk through system interactions can help your team gain the knowledge necessary to identify and classify bugs.
- As your application grows and the architecture evolves, involve your test engineers in the design process. This helps provide progressive exposure to applications of increasing complexity, training the test engineers to handle larger systems more effectively. This also encourages test engineers to invest in the end product and helps them troubleshoot its behavior.
- Implement a mentoring program. Pairing more senior SDETs and QA engineers with their junior teammates helps transfer knowledge, tear down silos, and improve teamwork. This also gives your more experienced engineers an opportunity to provide leadership and build a team rapport, helping to reduce flaky tests and drive the troubleshooting of failed test cases.
The final key to leveling up your test engineers is to be agile. Work on recognizing when an approach is working, and be prepared to change processes and people if it’s not. A flexible organization that knows when and how to change its approach is a powerful thing, leading to competent engineers and a rock-solid product.
Conclusion
Software testing is only as effective as the engineers performing the tests. As such, it is important to level up your SDETs and QA engineers to ensure that they are able to manage the complexity of your application as it grows.
By providing tools that help test engineers understand the flow of data in your application, you’ll improve the efficiency and efficacy of your testing organization. This saves your team frustration and leads to improved resolution times when issues inevitably occur.
Thundra Foresight improves observability for your distributed application and will help your testing team take ownership of your product’s quality. Get started with Foresight and give your team the visibility they need to find failures fast.
An application is only as reliable as the testing it undergoes. While anyone can throw together a quick server application and call themselves a web developer if there are too many bugs, users will vote with their feet. Finding and retaining users, on the other hand, requires quality software.
By introducing testing into your development process, you can ensure that your users find the value that you provide—not the bugs that creep in.
Testing, like everything in software engineering, grows in complexity as the product evolves. In order to facilitate your SDETs and QA engineers as they manage this increased complexity, you’ll need to focus on their skill sets as well as the tools that let them observe your application in the wild.
In this article, we’ll look at the challenges that test engineers face as their applications grow. We’ll also discuss strategies to mitigate those challenges while enhancing your organization’s testing excellence.
Expanding Focus
Junior test engineers typically have a narrow focus. They become familiar with small applications quickly, identifying and documenting holes in the system through rigorous automated and manual testing. This works well enough until an application reaches advanced levels of complexity.
Growing applications can have complex interactions and be hard to understand. These interactions can be contained within a single repository, or they can be spread across multiple component services, each of which contributes to the product that the user eventually sees. As these connections and interactions grow, the ways in which they need to be tested also grows, making system issues harder to track.
Furthermore, as the software engineers add complexity to the application, they also add institutional knowledge that can be hard to communicate. This complicates the system diagram and makes the job of test engineers far more challenging.
We can’t expect every SDET and QA engineer to understand the code base as well as the software engineers who wrote it. That’s why the testing organization should be exposed to the code interactions, allowing them to verify and troubleshoot CI test failures at a more technical level.
Observability Is Key
The key to solving the problem of growing application complexity is observability.
Smaller systems are self-contained, and their tests cover a clearly-defined set of API interactions and HTTP responses. This allows test engineers to have a deep understanding of the application and its idiosyncrasies, effectively testing all of the system’s edge cases without extensive assistance.
More extensive applications, however, end up with multiple services, each of which may rival the complexity of a simpler application in their own right. In these systems, it’s the flow of data through the application that’s being tested. This means that test engineers need visibility into the underlying components of the application to verify its performance.
By improving the observability of both the application’s automated tests and its distributed transactions, your SDETs and QA engineers will be better equipped to troubleshoot test failures effectively. This increased observability allows your test engineers to be more thorough and accurate in their bug reports, improving their time-to-resolution and decreasing test failures.
Finding the Right Tools
Enhancing observability into your test suite will require implementing the right tools. While being able to test the application in production is crucial for test engineers, the real improvements to observability happen behind the scenes.
To get started, exposing the output of your automated tests will allow QA engineers to quickly identify which tests are failing and why. This is generally handled through CI tools such as Travis or Jenkins, both of which offer the ability to report on automated test failures as they occur. These tools also provide access to the failing builds, allowing for technical troubleshooting and log analysis so your team can identify the root cause.
Observability into distributed transactions is the best next step. SDETs and QA engineers with the right visibility can quickly identify problematic microservices in a complex transaction and narrow down the cause of an issue. Luckily, Thundra’s in-depth distributed observability tool, Foresight, provides this visibility into your CI pipeline, as well as the remote debugging and tracing capabilities you’ll need to maintain your application going forward.
Gaining full observability into your distributed application requires effort from your development team and is an added cost to your organization, but these tools directly contribute to your team’s ability to fix issues as they arise. Ideally, your engineers will work observability and automated testing into the development plan. In the event that testing is neglected during development, however, the need for tools that analyze application behavior becomes critical.
Over time, the added expense of this observability is eclipsed by the resources saved through an efficient and effective testing organization. Spare your team the headaches that arise from poor resources and plan for improved observability—your engineers will thank you.
Levelling-Up Your Test Engineers
In addition to providing improved observability for your application through proper tools, you can improve your quality assurance by developing the capabilities of your team members. Below are some suggestions for improving your test engineers’ skills and helping them grow their awareness as your application scales:
- Teach your SDETs and QA engineers about the architecture of your system. Show them the design docs and UML diagrams that led to the current product, and answer questions about why specific choices were made. This will help them understand why things behave the way they do and improve their knowledge of how the system functions at a base level, giving them more tools for debugging integration tests.
- Improve the ability of your test engineers to observe requests as they move through the system. This includes both implementing tools to allow for distributed tracing, and training your QA engineers on how to use them. Additionally, pairing testing engineers with software engineers to walk through system interactions can help your team gain the knowledge necessary to identify and classify bugs.
- As your application grows and the architecture evolves, involve your test engineers in the design process. This helps provide progressive exposure to applications of increasing complexity, training the test engineers to handle larger systems more effectively. This also encourages test engineers to invest in the end product and helps them troubleshoot its behavior.
- Implement a mentoring program. Pairing more senior SDETs and QA engineers with their junior teammates helps transfer knowledge, tear down silos, and improve teamwork. This also gives your more experienced engineers an opportunity to provide leadership and build a team rapport, helping to reduce flaky tests and drive the troubleshooting of failed test cases.
The final key to leveling up your test engineers is to be agile. Work on recognizing when an approach is working, and be prepared to change processes and people if it’s not. A flexible organization that knows when and how to change its approach is a powerful thing, leading to competent engineers and a rock-solid product.
Conclusion
Software testing is only as effective as the engineers performing the tests. As such, it is important to level up your SDETs and QA engineers to ensure that they are able to manage the complexity of your application as it grows.
By providing tools that help test engineers understand the flow of data in your application, you’ll improve the efficiency and efficacy of your testing organization. This saves your team frustration and leads to improved resolution times when issues inevitably occur.
Thundra Foresight improves observability for your distributed application and will help your testing team take ownership of your product’s quality. Get started with Foresight and give your team the visibility they need to find failures fast.
An application is only as reliable as the testing it undergoes. While anyone can throw together a quick server application and call themselves a web developer if there are too many bugs, users will vote with their feet. Finding and retaining users, on the other hand, requires quality software.
By introducing testing into your development process, you can ensure that your users find the value that you provide—not the bugs that creep in.
Testing, like everything in software engineering, grows in complexity as the product evolves. In order to facilitate your SDETs and QA engineers as they manage this increased complexity, you’ll need to focus on their skill sets as well as the tools that let them observe your application in the wild.
In this article, we’ll look at the challenges that test engineers face as their applications grow. We’ll also discuss strategies to mitigate those challenges while enhancing your organization’s testing excellence.
Expanding Focus
Junior test engineers typically have a narrow focus. They become familiar with small applications quickly, identifying and documenting holes in the system through rigorous automated and manual testing. This works well enough until an application reaches advanced levels of complexity.
Growing applications can have complex interactions and be hard to understand. These interactions can be contained within a single repository, or they can be spread across multiple component services, each of which contributes to the product that the user eventually sees. As these connections and interactions grow, the ways in which they need to be tested also grows, making system issues harder to track.
Furthermore, as the software engineers add complexity to the application, they also add institutional knowledge that can be hard to communicate. This complicates the system diagram and makes the job of test engineers far more challenging.
We can’t expect every SDET and QA engineer to understand the code base as well as the software engineers who wrote it. That’s why the testing organization should be exposed to the code interactions, allowing them to verify and troubleshoot CI test failures at a more technical level.
Observability Is Key
The key to solving the problem of growing application complexity is observability.
Smaller systems are self-contained, and their tests cover a clearly-defined set of API interactions and HTTP responses. This allows test engineers to have a deep understanding of the application and its idiosyncrasies, effectively testing all of the system’s edge cases without extensive assistance.
More extensive applications, however, end up with multiple services, each of which may rival the complexity of a simpler application in their own right. In these systems, it’s the flow of data through the application that’s being tested. This means that test engineers need visibility into the underlying components of the application to verify its performance.
By improving the observability of both the application’s automated tests and its distributed transactions, your SDETs and QA engineers will be better equipped to troubleshoot test failures effectively. This increased observability allows your test engineers to be more thorough and accurate in their bug reports, improving their time-to-resolution and decreasing test failures.
Finding the Right Tools
Enhancing observability into your test suite will require implementing the right tools. While being able to test the application in production is crucial for test engineers, the real improvements to observability happen behind the scenes.
To get started, exposing the output of your automated tests will allow QA engineers to quickly identify which tests are failing and why. This is generally handled through CI tools such as Travis or Jenkins, both of which offer the ability to report on automated test failures as they occur. These tools also provide access to the failing builds, allowing for technical troubleshooting and log analysis so your team can identify the root cause.
Observability into distributed transactions is the best next step. SDETs and QA engineers with the right visibility can quickly identify problematic microservices in a complex transaction and narrow down the cause of an issue. Luckily, Thundra’s in-depth distributed observability tool, Foresight, provides this visibility into your CI pipeline, as well as the remote debugging and tracing capabilities you’ll need to maintain your application going forward.
Gaining full observability into your distributed application requires effort from your development team and is an added cost to your organization, but these tools directly contribute to your team’s ability to fix issues as they arise. Ideally, your engineers will work observability and automated testing into the development plan. In the event that testing is neglected during development, however, the need for tools that analyze application behavior becomes critical.
Over time, the added expense of this observability is eclipsed by the resources saved through an efficient and effective testing organization. Spare your team the headaches that arise from poor resources and plan for improved observability—your engineers will thank you.
Levelling-Up Your Test Engineers
In addition to providing improved observability for your application through proper tools, you can improve your quality assurance by developing the capabilities of your team members. Below are some suggestions for improving your test engineers’ skills and helping them grow their awareness as your application scales:
- Teach your SDETs and QA engineers about the architecture of your system. Show them the design docs and UML diagrams that led to the current product, and answer questions about why specific choices were made. This will help them understand why things behave the way they do and improve their knowledge of how the system functions at a base level, giving them more tools for debugging integration tests.
- Improve the ability of your test engineers to observe requests as they move through the system. This includes both implementing tools to allow for distributed tracing, and training your QA engineers on how to use them. Additionally, pairing testing engineers with software engineers to walk through system interactions can help your team gain the knowledge necessary to identify and classify bugs.
- As your application grows and the architecture evolves, involve your test engineers in the design process. This helps provide progressive exposure to applications of increasing complexity, training the test engineers to handle larger systems more effectively. This also encourages test engineers to invest in the end product and helps them troubleshoot its behavior.
- Implement a mentoring program. Pairing more senior SDETs and QA engineers with their junior teammates helps transfer knowledge, tear down silos, and improve teamwork. This also gives your more experienced engineers an opportunity to provide leadership and build a team rapport, helping to reduce flaky tests and drive the troubleshooting of failed test cases.
The final key to leveling up your test engineers is to be agile. Work on recognizing when an approach is working, and be prepared to change processes and people if it’s not. A flexible organization that knows when and how to change its approach is a powerful thing, leading to competent engineers and a rock-solid product.
Conclusion
Software testing is only as effective as the engineers performing the tests. As such, it is important to level up your SDETs and QA engineers to ensure that they are able to manage the complexity of your application as it grows.
By providing tools that help test engineers understand the flow of data in your application, you’ll improve the efficiency and efficacy of your testing organization. This saves your team frustration and leads to improved resolution times when issues inevitably occur.
Thundra Foresight improves observability for your distributed application and will help your testing team take ownership of your product’s quality. Get started with Foresight and give your team the visibility they need to find failures fast.
