Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

2 Answers 2

up vote 2 down vote accepted

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.

share|improve this answer

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!

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.