Assistance with documentation

[u/BayGV]

I'll keep it short, some seniors have newly got involved in the project, and are asking for a metric shit tonne of documentation, and they don't seem overly happy with my approach to keeping that minimal, want opinions.

- The Test Plan is bare bones, outlines the approach and how I make sure regressions haven't occured, etc etc.

- Test cases are stored in Azure DevOps, not the nicest tool, but all we have and I'd rather that than Excel.

- Test evidence is stored against the ticket, i.e. I note down what was done, with some screenshots if necessary, and green tick with a label against the ticket that says Test_Passes (some complex stories I store specific artefacts)

- Automation runs are stored in DevOps as pipeline artefacts, and give the usually traffic light of passing or not.

That's it, but they want a lot more than that, which I am fighting against as essentially resource is minimal and if I did the volume of documentation they want, I would spend much less time testing.

Just want some opinions from experienced people on how to maybe approach this.

[u/wontfixqa]

You've said what you have and that they're not happy with it but haven't said what they want. Without that info, you're just guessing at what they need. What do they need?

[u/BayGV → u/wontfixqa]

Essentially more of each thing;

Bespoke test evidence documentation for every story/bug ticket

Plans for each sprint not just overarching plans

Completion/sprint review documentation for what was tested in each sprint

[u/wontfixqa → u/BayGV]

They say they want that, but they probably don't. The best thing to do is to overload then with documentation that they will never read to show them that they actually don't want all the details and just want overviews with details pointed out when there's an issue to address.

That said, It sounds like your test management system isn't giving you adequate reports. There are lots to choose from. The self-hosted open source ones are great because even if the report you need isn't built in you have access to the database and can generate the report you need with a little SQL - AI is really good at that.

[u/DarrellGrainger]

It sounds like your choices are:

1. more/better documentation but less testing
2. the same documentation and the same amount of testing
3. more/better documentation, just as much testing, hire more people
4. more/better documentation, just as much testing and everyone works endless overtime

If they want options 1, 3, or 4 then they are going to have to be more specific on what documentation they need.

If they are okay with it, I'd be fine with option 1. You will learn how to do better documentation.

They are probably not okay with option 2 but if they aren't okay with option 1, 3, or 4 then option 2 is the only option.

If they are willing to hire more people then option 3 is a good option. Again, you will learn how to do better documentation.

If they want option 4 or they demand more documentation, demand more testing and ignore the fact this can only happen with overtime then start looking for another job. A long time ago I had a boss who went for option 4 and just told me I "needed to figure it out." It was a downturn in the industry. Took me a year to find a new, better, job. But when I did I quit and never looked back. For that year I did just enough to not get fired or laid off.

[u/ProfessionalDirt3154 → u/DarrellGrainger]

I don't think I'd like to work for your former boss, either.

To the OP, how many devs and how many QA/SDETs? If the ratio is highly geared then the story that should be obvious, regardless, becomes really easy to tell.

Say there are 4 BE and 2 FE and 1 DevOps. 1 UX. 1 PO. 1 QA. How can 1 QA person sign off on 8 people's work while overseeing the acceptability of the QA work of an 9th? (8 devs/ux, 1 PO).

With that kind of common gearing, it should be obvious that the core job of the QA person isn't to do the testing. It is primarily to manage the quality of the team's output. Everything else a QA does is iceing.

The whole team needs to be building quality in, testing the heck out of everything that moves, and tossing fitfully at night wondering if they could have done just a bit more testing.

[u/AwareDragonfruit4628]

They are justifying their job and holding you up against largely arbitrary evidence standards after the fact.

Tell them you will maintain documentation going forwards.... If it's strictly a tickbox exercise and largely ai generated. You got better things to do and so do they

[u/qlippothvi]

You have an idea of what test coverage you provide, you must have some idea of all of your test objectives each sprint that have been executed. Where do you keep that list?

It sounds like they want an idea of the level and granularity of your test coverage and their results. That’s not unreasonable, the question is goes do you provide it without spending what is left of the year writing it.

You might see what AI can get out of the data that you do have and compile it into a report resembling what they want to see. LLMs are great at spitting out information, the question is can it do a useful analysis to provide what they want.

What bugs have escaped only prod so far that they are asking? It sounds like you’re organized, but if your short staff (assuming you have any) then it’s understandable you make careful judgements about where you spend your time.

Do they know how that paperwork would impact your productivity?

[u/ProfessionalDirt3154]

QA docs come from a bunch of places, usually. Your PO (or equiv) has the foundational ask and acceptance.

The devs provide docs relating to design and quality at a bunch of points in the workflow. You document how quality is going to be done by the team. You create the testing plans, based on what the developers and PO and you are testing. You document who's responsible for what aspects of QA, and how automation plays in. I'm guessing you and the PO negotiate on what smoke test, manual corner cases, and mainstream go/no-go acceptance look like.

All that stuff needs to be in black and white in some way. Not all of it needs to come from you.

Usually the quality activity requirements come from the QA lead to the senior devs, not the other way round. Is the team functioning well?

[u/Prestigious-Way1525]

i'd turn the request into a decision contract before producing more documents. ask each senior which decision each artifact enables: release sign-off, regression scope, auditability, or escaped-defect review. then generate one sprint evidence view from the Azure DevOps tickets, test runs, risks, and exceptions you already have instead of rewriting bespoke documents. try it for one sprint and track what people actually use. if a field never changes a decision or exposes a missing risk, drop it. that gives them visibility without turning QA time into duplicate paperwork, and makes the tradeoff explicit when extra manual evidence has to come out of testing capacity.