I manage development teams that support a legacy app with a SQLServer backend. The app is deployed on-premise so our customers maybe run any version SQLServer (minimum 2008).
We have an on-going challenge of certifying that our app runs on new versions of SQLServer or any new service pack. It's very time consuming for our QA to run a full regression of our suite of products so I'm wondering if anyone faces the same challenge and has found another way to certify new releases of SQLServer as they come out.
We've though of turning on profiler and then hammering the app to capture SQL and just replay that on a new SQLServer instance with the new version. Is there a better way?
BTW, we use a lot of SQL features such as triggers, procs, views, defaults etc.
Thx
Best Answer
Answers originally left as comments
I think you identified it in your question, regression testing. You maybe able to thin down the testing to just corner cases of the functionality. However if you are looking at more than “does it run” and wanting to test “how well does this run” a full test maybe your best option. – Aaron
To me, this is less of a question about the database, and more of an issue with your regression testing. You may want to explore ways to make your regression testing less labor intensive. – AMtwo
Also there aren’t that many things that work in 2008 and break in newer versions; the exceptions are limited to lists documented on Microsoft’s site, like this one for SQL Server 2016. So outside of those items, you should generally expect that moving to a new version should just work. Performance testing is something completely different, of course, and there aren’t any magic shortcuts aside from testing. Baselines are a good start. – Aaron Bertrand