I like to think I'm wiser now.
Sometimes the best thing you can do for a project is to not get involved. Yes, you are the QA department. And yes, the quality of the software that leaves your company reflects on both your company and on you specifically.*
Sometimes it's okay for quality to have a different bar that you haven't touched personally. Sometimes you can't add value. And in those cases, you're just adding overhead and it would be better if you stepped away (and found something where you can add value).
Consider not getting involved if the project is:
- A demo. Particularly if the demo is controlled (aka done by someone you know to a set script), then you don't necessarily have to get involved. The lack of variability and the incentive to the demonstrator to have it go well will help protect you. The people doing the demo and the people building the demo can do the testing that's needed.
- A prototype. A prototype isn't designed to be shipped. It's designed to show whether something is feasible at all. It's a long way from prototype to shipping product, and lots of things are likely to change. So don't worry about it too much; once the prototype is done and actual design/implementation begins, then you can get involved.
- A dependent component. Let's say a new hardware platform is being qualified for the software you produce. Qualifying that hardware platform may not be the best use of your time; sometimes your vendors and your lab team can do this for you. This is a borderline case; your specific situation will determine whether you ought to get involved, but it's worth asking yourself what would happen if you didn't stick your nose in.
Knowledge is comforting, and being involved in projects lets you help control them and mitigate their risks. However, you can't be involved in everything; there simply aren't enough hours in the day. It's better to explicitly not be involved than to try to be involved and do a rush job of it. So ask yourself sometimes whether this really concerns you, and know that sometimes it's okay for the answer to be "no".
* It's not fair, but I think this is true. If you work in QA for a company that ships a low quality product, you'll be tainted by that, even if it's not your fault.