That sounds like a pretty basic question, yet it's a pretty big one. I will try to cover at least just one aspect.
I can't speak for others, but it might be helpful to go through this:
https://en.wikipedia.org/wiki/Systems_development_life_cycle#Testing
Could you please share how you test your software before you release it? What works for you and what does not?
What methods do you use? Are there any Software Quality Assurance protocols that you follow or any standards?
Do you use any software tools? For example performance / stress testing tools to see how a busy big board would handle your software?
How do you account for different browsers? Or for different stacks?
For XF2, you would mostly just assure that everything's escaped, filtered and using as many resource optimizations as possible. At the end of the day, XF2 is a big framework and most of the work is done by that framework. Try to avoid overriding methods where possible, follow basic rules like MVC, KISS and DRY, extend correctly and you're on the safe side.
All of this works towards one goal: minimize the amount of time spent with testing and minimize the impact on everything else. Because XF2 is already a heavily tested framework, extending that framework saves a lot of time. Extending correctly saves everyone's time.
That being said, the most benefits apart from properly coding come from a proper plan. Preparation is key to success. We used to work with the prototyping workflow where you create a lot of prototypes and integrate them step by step, evolving into an ultimate release candidate. We still use that workflow sometimes, mostly when it's some small work, but working directly with customers can be tedious, so rapid deployment can backfire pretty hard pretty fast.
Our experience is that waterfall typish workflows are way better - you integrate once when you are ready for it. This ensures that everything's working in theory, thus already raising code quality by default. Obviously, the downside is that integration is pushed towards the end, which could be a huge drawback. But as I said, XF2 is a really great framework, so integration should be easy if everyone follows the rules. And yea, obviously, customer feedback can't be considered that often either. So you need to communicate a lot and prepare a lot.
Performance and stress tests should be relevant only when doing actual heavy work, like database optimization, transfering a lot of files, importers and all that stuff. Your casual addon *should have* pretty much no impact on anything. Reason for that is again, we are using XF2. If XF2 does scale with your numbers, then most addons will aswell.
Yes, there is something called micro-optimization where you would hunt for every useless query, misplaced if-clauses etc. Like Xon usually denotes in his addons what the query impact is. But that's really another story.
Considering different systems - we have a strict policy where we officially only support the current generation of browsers + their ESR pendants. We use Blisk and BrowserStack for different environments, and for most systems we also have an actual physical device.
