Hello! In our organization, we have SDET and manual testers. Our manual QA testers are responsible for all acceptance testing which is primarily exploratory. We’re starting to dabble in written test cases but haven’t decided whether that’s the best route for our team.
We are however, responsible for writing the product documentation used by all the departments in the company (primarily our customer experience team). Is this a common QA responsibility? How is that responsibility handled at your company?
Bonus Q: I’m curious if test cases in a test case management suite can be used as de facto product documentation as well.
Nooo, here’s my rant from another discussion on this. I caveat my rant with there are times on occasion given a tester will often have the best knowledge of the product it may make sense but I strongly recommend against QA getting associated with being the documentation person.
One other flag that may be worth raising, it in my experience is not good for testers to get known as the documentation person.
There are still people out there that feel testing is all about documentation, writing test cases, reports, release notes, bug reports a lot of things that may be useful though tend to carry a lot of waste in my experience but still often detract away from actual testing.
I’ve seen places where some managers were sub consciously seeing this to the extent that the QA’s were more often than others taking meeting minutes at retro’s for example. It’s can be both a bit disrespectful and diminishing to helping people understand the real value of testing.
I for example will almost never volunteer to take meeting minutes due to that risk, taking your fair share of documentation is one thing but do not get a rep as a documentation person.
We’re lucky and have two dedicated technical authors, that take care of external customer facing documentation.
For internal documentation we do often produce internal documentation for other teams - so for particualarly complex pieces of functionality we will take detailed documentation that has been produced by engineers and turn into something appropriate. I think, where we as test are well positioned sometimes, is to understand the stakeholders better than the engineers. We produce a lot of embedded software, which is used on precision instruments. The engineers typically solve complex problems - and their designs reflect that comlexity. We cannot, however, put their design documentation infront of - say - a customer service engineer. They just lack the skills to understand how a feature will work from that level of documentation, so we as testers - since we have to understand the needs of the stakeholders to test the thing in the first place - often end up distilling these down to application notes, or other short form documents with the appropriate level of detail.
These aren’t used as part of testing, so we’re not preducing the day job so to speak - we’re helping teams out with our understanding that has been gathered over the formal testing process.
As for the bonus question, I haven’t seen that done. Our test cases link back to requirements and then back to features in Azure DevOps, but these would be too low level for most stakeholders to get a grip on for my money.