Recently on LinkedIn, I spotted the following poll in one of the software testing groups I follow:

I didn't get a chance to see which option was ahead, but polls like these tend to be somewhat divisive within the testing community. Some people will argue that one selection is the best option. Some will even say that one of them is The One and Only Solution and everyone else is wrong. There's some merit in all of the poll's choices. In almost any software development process, it all depends on a team's current situation when it comes to their project and the people involved.

In my opinion, however, this poll was missing the option that I consider the most valid one that teams should consider: All of the above. In this article, I'll explain why continuously performing different test-related activities during development, before deploying, and in production is essential for any organization focused on delivering a high-quality product.

Testing during development

Jumping into testing a software product that's in the middle of active development can feel overwhelming. There's a steady flurry of activity happening every day, with changes coming left and right as the development team works hard to deliver on their work. The constant revisions happening at this time can make it difficult to do any extensive testing, but that doesn't mean the team can bypass testing at this phase.

During the development phase, the software developers should take the lead with testing by adding automated tests—typically smaller unit tests—as they build the product. Since they're the only ones at this point with the knowledge of what each new component does and how it interacts with the rest of the system, these tests will help guide their efforts and make it easier for the entire development team to continue expanding the product in the long run.

A typical argument developers make is skipping testing while developing because they believe their code will change and make their tests useless. But from personal experience, this is rarely the case. I've written code that I thought wouldn't stick around, only to have the same code running untouched in production for over five years. One example that stands out is when a former employer recently told me their company was still using an internal tool I developed for them in 2006. There's a good chance that what you build will last far longer than you think, so there's no excuse for skipping this essential part of the development process.

Testing shouldn't fall squarely on the shoulders of developers at this time, though. QA and other stakeholders should also help with the testing process during development. Ideally, the organization will have easily accessible staging or UAT environments containing the latest updates of the application. If your team doesn't have a place where anyone on the team can quickly check out the most recent version of an app under current development, it's worthwhile investing in getting something set up. Testing from people beyond the developers tends to yield critical findings early in the process when they're easiest to correct.

Testing before deployment

As the bulk of a development cycle for a sprint or project winds down, there's still plenty of work that developers and testers have in front of them. Teams need to make time for testing between when an application is considered feature-complete and when it's ready to ship out to the world. The excitement of being so close to delivering new functionality to customers can make teams minimize the importance of testing before going live with their work. This trap can become disastrous when last-minute issues sneak by undetected.

Given that no new functionality should get added so close to deploying to production, the focus of testers at this crucial period is to shift their energy towards manual and exploratory testing. A feature-complete build can expose previously-undisclosed bugs after integrating with the rest of the system. It also gives QA the opportunity to get better acquainted with the new functionality and how it affects the entire application moving forward. The time taken for testing at this time will pay off, now and in the future.

The development team should also pitch in with testing before deployment. They'll still have to fix bugs, improve performance, and tighten up loose ends during this time. But they can also boost the application's quality through integration, API, and end-to-end testing to ensure their work remains healthy in the future. It's also an excellent opportunity to add missing unit tests now that the codebase is in a stable state.

If developers have been writing automated tests and the organization has been helping with testing throughout the development process, this phase won't require much of the team's time or energy. Still, it's an important piece that can't be rushed through like many organizations tend to do towards the end of this cycle. Hopefully, the team won't have to run to put out last-minute fires in their work and will have the capacity to focus on these critical checks.

Testing in production

Once your application gets deployed and lands in the hands of your organization's customers, it can feel like the testing phase is now over, and testers can move on to the next task. In my experience, most teams immediately jump into the next sprint or cycle, all but completely forgetting the most recent deployment. Testers don't need to spend dedicated time focusing on something already pushed out the door, but there's still testing that can help the overall quality of the application in production.

There's a growing movement towards Shift-Right testing—continuously testing an application in the same live production environments that the rest of the world uses. Shift-Right testing is beneficial since it uses real systems and data that are difficult to replicate in staging or UAT environments. It can help expose real-world issues like slow performance, security vulnerabilities, and other scenarios that the team can't test for before deployment.

Besides performing manual and exploratory tests, teams can continue with test automation by focusing on regression, performance, and other kinds of automated tests against their production environments. Another area gaining steam is observability—keeping track of what's happening in the system through telemetry, logs, tracing, and other metrics. Combining different tactics like these can yield tons of information you otherwise won't detect during development or before deployment.

While Shift-Right testing is an excellent idea, it can take time to pull off in practice. Careful and thorough planning is necessary to ensure that any testing doesn't affect other customers or your organization. For instance, creating lots of fake data that remains in production databases can look like spam to your customers or make business analytics useless. Another example is having performance tests slow down or even crash your servers, causing the company to lose money and customers. Testing in production is very beneficial, but be aware of potential issues that can arise.

Summary

Teams have the opportunity to allocate their testing efforts at different times throughout the software development cycle. You can mainly test during development through unit tests and early application testing as the system gets built. Like many teams, you can also do most of your testing before deployment, focusing on manual and exploratory testing plus automated tests like end-to-end testing. Another helpful approach is to "shift right" and test in production using real live systems, directing your attention to performance, security, and observability.

Any of these solutions should work well. Every situation is different, and what works well for one organization won't work everywhere. Your team might achieve higher quality when testing during a specific period in the development lifecycle over the other. But that doesn't mean you should spend your time only testing during development, before deployment, or in production. The bottom line is that every team will significantly benefit from continuous testing throughout the entire development lifecycle.

If your organization struggles to find the right balance of testing while working on your products, I can help! Building reliable products in a fast-paced environment takes a lot of work. I assist startups and small teams with improving their existing development and testing processes so they can focus on rapidly delivering high-quality applications. To learn more, visit my website: https://dennmart.com