For our hardware product, no; for our software product, yes, from time to time.
The hardware product is a network security device that essentially works as a black box, with limited inputs and outputs. It requires so much domain expertise that the small group of us that work on it take an incremental approach both to feature development and to bug fixes, with a fair amount of design review, code review, discussion, prototyping and PoC, etc., before moving to actual testing.
Most recently, I've tended to do the bulk of the development and one of my colleagues the bulk of the testing. When we find errors, there is a lot of screen sharing to review code and logs, determine the best way forward, etc.
Our build process generates ISOs with several layers of security, from completely locked down release instances to a permissive mode with a development account for the privileged access necessary to run onboard diagnostics.
The caveat is that one of our main customers is a security agency with complementary expertise, and they tend to beat the bejeesus out of it.
Overall, we take a similar approach to our software product (design and code reviews, much screen sharing, discussion between development, marketing, and senior management on what it should do and what it should look like, etc.), but at some point it gets turned over to QA. I wrote above that our QA resource was full time from time to time, because when they are not doing QA on the product, they are doing market research and analysis, developing marketing strategy, etc.
From on QA PoV, one major the difference between the two products is audience: The hardware product is used by domain experts to do very specific network segmentation and data transfer; the software product is intended for general use by non-IT corporate users - it's a web application for integrated risk management and compliance reviews.
We consider ourselves competent to fully test the hardware product we've updated, because its functionality is essentially binary: either it works or it doesn't, there aren't a lot of variations in use case, and we are best positioned to determine how it should work and whether it is working.
We don't consider ourselves competent to fully test the software product, because we are a) too close to it, b) domain experts, c) not typical users, and because d) we have a lot of experience with a lot of different software.
Our users are often people who mostly use browsers, and occasionally office products. They may be domain experts, but their domains are far from IT (especially the physical security people).
Our QA person is excellent at getting into their shoes, so to speak, imagining how they might approach things, and findings both bugs and ways that our designs and GUIs and UXs lack and don't help users get to where they need.
Having someone with that external perspective is invaluable. Having them be full-time when in QA mode helps us move quickly when we need to - they are never the bottleneck, and anything released has been thoroughly beaten up.