Upgrade Best Practices?

Hello Champions

scot1967​ TNeuschwanger​ Hassan_Ballan​ 

There is a Articles/Blog space in the Champions Group -  Champions Articles | SmartBear Community 

If you have articles that you would like to publish, please feel free to add the articles in the above space. We can help to promote it in various spaces based on topic, context & quality.

Note: Most of the champions will have the permission to publish blog post, if you are facing any permission issues. Please DM me.

Regards

Tanzeem

Hi scot1967​ Hassan_Ballan​ TNeuschwanger​ 

This is such a great discussion – really appreciate you sharing your expertise here!

I've been thinking this thread deserves way more eyes on it. It's packed with valuable insights that could help so many people across the community.

A few ideas I had:

• We could feature this in a special tips & tricks area
• You could turn this into a blog post in the Champions Articles section (if you're up for it!)
• Or we could highlight it across other product boards to get more traction

What sounds good to you? Happy to help make any of these happen!

-Tanzeem

Hello scot1967​ 

I don't know if I should stay in my lane or not, but my only Smartbear tool use is ReadyAPI and it looks like the discussion is based around TestComplete.  All of the above/below suggestions seem spot on.  I will just comment on my experience with ReadyAPI...

Since I/we (the team I work with) have never been bit by an upgrade bite (yet), when new versions are released, we upgrade.  Maybe just because we don't want to answer daily nag screen that annoys until upgraded :).   We have developed a simple batch file to invoke that loads our common libraries to the install location of new version and away we go.  Download to restart in working condition is about five minutes down time.  This is for our local usage... Only after a period of time (months) do we upgrade the CI/CD machine however (unless new feature usage is mandated).

We might have a different usage scenario for ReadyAPI also... We are highly dependent on the scripting capability within ReadyAPI which is a little more protected from change than the product itself.  Because of that usage of scripts, we use ReadyAPI not only for our bread and butter API testing, but also user interface testing of Web, Mobile and Windows Desktop applications via ReadyAPI integration with Playwright and Selenium, Appium and Winium.  That allows for no context switching to achieve a test case in any paradigm.

Hi all,

This fits well with this topic....  

How the Technology Adoption Curve Influences Strategy
https://productschool.com/blog/product-strategy/technology-adoption-curve

Which one of these are you?  I so wish we had polls in this forum...

Hi scot1967​ , thanks for starting this important discussion!

You're absolutely right—frequent updates across the stack (Windows, browsers, TestComplete, and the tested application) can wreak havoc on automated tests. For small teams, full-scale change management can feel like a losing battle—it's often too slow, expensive, and heavy for the pace of change.

That said, shifting to lightweight change tracking and adopting a few best practices can go a long way in reducing breakage and upgrade risk. 

🚫 Delay Upgrades If You Don’t Need Features

Unless a new release includes a feature or bugfix your team really needs, it’s perfectly fine to wait a few weeks or months.
Let early adopters (and the community 😄) surface any serious regressions first.

🧾 Track Changes with a Shared Log

Use a lightweight change log (even a simple spreadsheet) to track:

• OS and browser updates
• TestComplete or application releases
• Known issues and workarounds post-upgrade

Assign someone to monitor scheduled or automatic updates and record when things change. This gives you traceability without the bureaucracy and helps spot patterns over time.

🧊 Freeze Test Environments

To reduce false failures:

• Freeze browser versions used in automation (use portable browsers or disable auto-updates).
• Turn off auto-updates for TestComplete, and your tested application if possible.
• Use VMs or containers with a fixed image to ensure consistent environments.
• Designate a “pilot” machine to test upgrades before rolling out to the team.

🔎 Always Check Compatibility Before Upgrading

Before installing a new version:

• Review TestComplete Version History
• Double-check TestComplete System Requirements
• Scan the community for upgrade-related issues (TestComplete, Browser, and OS)—you'll often find early insights from fellow users.

💾 Backup Before Upgrading

Always back up. This ensures you can roll back safely if needed.

🔥 Smoke Test First, Full Test Later

Before running your full regression suite:

• Run a targeted smoke test to quickly detect major breakage.
• If smoke tests pass, proceed with the full suite.
• If they fail, stop and investigate before wasting time on debugging noise.

🚀 Staggered Rollout

Once your pilot machine is stable:

• Upgrade one machine at a time across the team (especially if you use TestExecute on multiple nodes or Network Suites).
• This isolates issues and prevents mass disruption.

It definitely feels like a losing battle sometimes, but these lightweight strategies can help small teams stay agile without giving up on test stability.

Would love to hear what others are doing—this kind of knowledge sharing is one of the best parts of the community!

🤖 AI-assisted response.
💬 Was this helpful? Click Like to show appreciation.
✅ Got the answer you needed? Mark as Solution to help others find it too.

This is a great discussion: I usually just install the new version and use the upgrade option from the installer. This has never really caused a problem with Test Complete install. The issues I've ran into have typically been related to Chrome updates that break some part of Test Complete.