Using automated bdd-gui-tests to keep user-documentation-screenshots up do date?

Question

Are there developpers out there, who (ab)use the CaptureScreenshot() function of their automated gui-tests to also create uptodate-screenshots for the userdocumentation?

Background: Whithin the lifetime of an application, its gui-elements are constantly changing.

It makes a lot of work to keep the userdocumentation uptodate, especially if the example data in the pictures should match the textual description.

If you already have automated bdd-gui-tests why not let them take screenshots at certain points?

I am currently playing with webapps in dotnet+specflow+selenium, but this topic also applies to other bdd-engines (JRuby-Cucumber, mspec, rspec, ...) and gui-test-Frameworks (WaitN, WaitR, MsWhite, ....)

Any experience, thoughts or url-links to this topic would be helpfull. How is the cost/benefit relation? Is it worth the efford? What are the Drawbacks?

See also:

Is it practical to retroactively write specifications documenting a system via automated acceptance tests?

[Update 2017-12-13]

I have shifted from dotnet to android where localized screenshots for the appstore may also be a topic that could be generated by the bdd tests. My apps are translated to non ascii-languages like arabic (with right-to-left reading), japanese, chinese, bengali.

Answer 1

I had one gig where I wrote an automated test script explicitly to generate new screenshots, and it worked quite well. Whenever the GUIs changed I merely ran that test, then copied the images to the website. It proved to be a much better system than to regenerate the screenshots by hand.

This method also guaranteed that the screenshots were consistent. We developed cross-platform software, so before we did this we had some screenshots from windows, some from various linux systems, all of which had different window borders, different login accounts, etc. By running a script we could get a cohesive set of images that told a story rather than a bunch of random screenshots that may or may not be related.

Answer 2

Documentation is like sex, when it's good it's awesome and even when it's pretty bad it's still better than nothing. If you already know you're not going to update the documentation, have the testing software do it. It's fine as long as you still give it a very thorough look before you ship the doc. Do not skimp on that thorough look!