I’ve never called myself a QA or SDET, but I have influenced support documentation a great deal, depending on how you look at it.
Internally I’ve written a lot of work to help others. As I investigate archaic parts of the software and unpick it I will often write them up to save others the same pain. I think that many test artifacts, such as testing notes and bug reports, act as support documents internally. I’ve helped to find problems with oracles like supporting documentation, or problems with the software depending on where the misalignment falls.
Customer-facing documents I tend to have less influence over in a direct sense, but I consider them part of the product and therefore always worth considering for testing, even (or especially) if told otherwise.
What are your non‑negotiables for good support docs?
That I’m permitted to do work on them that I consider to be good. It depends heavily on the situation and how important the documents are, if there are other teams in charge of them, and so on.
What have you learned to avoid because it adds noise or goes stale?
Everything, in a sense. Investigation is a cost, and documentation of any kind is between one and two costs depending on if it has to be maintained. Every decision is based on what makes sense. If the system will change, if the documentation is mandated, how detailed it needs to be, if it covers something critical, who the audience is, who has access to it, and so on.
How deep do you usually go—just enough to unblock, or proper technical deep dives?
Depends on if it needs one. I won’t go off on a technical crusade without good reason, as it’s part of my job not to deliberately waste time and resources. Usually, I suppose, I do the minimum. Sometimes the minimum is a lot.
How do you decide what must be documented vs what should stay in code/tests?
I suppose that depends on what “must be documented” means. In the cosmic sense, nothing need ever be documented. So it depends on what pressures are on me to write things down. Some are self-imposed, such as writing testing notes for my own use, but perhaps I need to run a debrief and therefore need notes I can read the next day and remember what I did in more detail.
Who actually owns the docs, and how do you stop them rotting?
The owner can vary. As a tester I don’t stop rot, I discover and report it. As I say I think documentation is a big cost. Only write down what’s valuable enough for the situation.
Do bugs, incidents, or support tickets ever drive doc updates?
Depending on what we consider support documentation, yes. Sometimes bugs can drive documentation creation - I’ve written internal documents based on testing I’ve done following a bug.
Have you seen support documentation meaningfully improve quality, reduce defects, or help teams move faster?
Yes, I’ve been thanked for writing internal documents before where it’s saved others a great deal of time. Test artifacts obviously can be used for reporting.
Or is it still treated as “nice to have” in most agile setups?
I don’t think documentation should be an expensive luxury we pour money into because it makes the place look nice. It will depends on what is needed. Often in agile businesses I find that documentation is born from pain, like teenage poetry, and expires when the trust in it expires. Writing it “just in case” is something you only do at the start of your career when you realise how it goes unread (because one does not consider the audience and use cases) and how costly it is (when you realise that projects outpace documents and updating documents is a finite resource)
Just to try to be useful here’s some considerations for documenting part of some software:
- Is it important? If this part of the software is important it may benefit from documentation despite the maintenance costs.
- Will it change? If this part of the software won’t change then documentation may stay relevant for longer, reducing the maintenance costs.
- Who might need support? If you can think of a reasonably likely situation where someone might need this supporting document that helps defend the cost of it. That person will also need to know the document even exists.
And also support documents, especially those for users, are testable artifacts and can benefit from early involvement with testers. I don’t think it’s a testers job to create typical support documentation, but sometimes it’s created as part of testing and there’s no reason not to make that available to people.
.
will be rewarded for answers 
But yes, I’ve always both created and influenced documentation. In my experience, it’s (best as) a shared responsibility within the team - everyone should feel empowered to create / improve documentation, and no one should feel like the burden falls solely on them.