ScreenshotNeo
Sign in Get a free key

BlogEngineering

Selenium News and Updates: A Smattering of Selenium 62

A guide to Adam Goucher’s 2011 Selenium roundup: its links on test design, selective automation, maintainability, and software delivery—and what it can tell developers today.

By the ScreenshotNeo team4 October 20265 min read

“A Smattering of Selenium #62” is a link roundup, not a Selenium release announcement. Adam Goucher published it on September 29, 2011, collecting opinions and articles about test design, GUI automation, what to automate, maintaining automated suites, and software delivery. The number 62 is the roundup’s sequence number. Read it as a snapshot of what practitioners were discussing in 2011, not as current Selenium documentation or compatibility guidance.

Goucher opens with the line “All opinions, all the time…” That framing matters: the post curates links and offers commentary; it does not report a systematic study or present quantified findings.

1. The central theme: design tests deliberately

The roundup points readers to a sequence of writing about designing tests for automation and GUI automation. Taken together, those links make test design the post’s central subject: automated checks need to be chosen and structured, rather than treated as a goal in themselves.

One of the linked pieces makes that limit explicit in its title: “Not Every Test Should be Automated!” The roundup’s inclusion of that argument is a useful counterweight to the idea that more automation is always better. A test may be valuable without being a good candidate for automation; the post does not claim that every testing activity should become a scripted check.

2. Automate selectively and prioritize the work

Another link concerns prioritizing automation work, introduced with a “taking on water” metaphor. In the context of the roundup, the point is to think about where automation effort is most useful instead of trying to automate everything indiscriminately.

The post does not provide a scoring system, a formula, or empirical evidence for choosing candidates. It is a pointer to an argument about prioritization, not a prescriptive method. Developers using it today can take the question—what is worth automating?—as a prompt for team discussion, while consulting current sources for implementation details.

3. Maintainability is part of test design

Goucher links Cem Kaner’s paper on improving automated test-suite maintainability and calls particular attention to strategies on page three, especially items 1, 2, and 5. This emphasis connects the roundup’s test-design theme to the long-term cost of keeping a suite useful: automated tests have to remain understandable and maintainable as the software and the suite change.

The roundup highlights selected strategies but does not reproduce the paper’s full argument. For details, consult the paper itself and evaluate its advice in its original context; the link roundup alone is not enough to attribute specific implementation practices beyond the items Goucher identifies.

The links reach beyond GUI automation into neighboring software-engineering topics:

  • Dependency injection and dependency inversion: Goucher points to a discussion distinguishing these related but different ideas. Their appearance signals that the roundup connects testability and design discussions to broader engineering concepts; it is not a complete explanation of either principle.
  • Harold’s Corollary to Knuth’s Law: The post specifically frames this link as applying to unit tests rather than functional tests. Keep that distinction when describing the item; the roundup does not present it as a general rule for every kind of automated test.
  • Continuous deployment: A link considers why continuous deployment matters, placing automation discussions alongside software delivery practices.
  • Exploratory testing: The roundup mentions The Little Black Book on Test Design as intended for exploratory testing, while Goucher suggests that some ideas might transfer to automation. That is a suggestion about possible relevance, not a claim that the book is an automation manual.

5. What developers can take from this historical post

  1. It is curated opinion. The post gathers articles and commentary; it is not a release note, standard, or research review.
  2. Test design recurs throughout. The linked subjects include designing automated tests, GUI automation, and maintaining suites.
  3. Automation should be selective. The roundup explicitly includes an argument against automating every test.
  4. Testing connects to wider engineering practice. Its links touch dependency principles and continuous deployment as well as testing.
  5. Its date sets its limits. The article records a 2011 conversation. It does not establish current browser support, Selenium version behavior, or compatibility advice.

6. How to use it without mistaking it for current guidance

  1. Use it for historical context. It is useful for seeing which test-design and automation discussions Goucher chose to surface in 2011.
  2. Follow original sources for the arguments. The roundup summarizes and links to other authors; read those sources for their full reasoning.
  3. Check current official documentation for implementation questions. If you need present-day Selenium setup, browser support, APIs, or version compatibility, consult the current Selenium documentation rather than inferring those details from a 2011 roundup.
  4. Separate the categories of advice. In particular, the post distinguishes a point about unit tests from functional tests, and presents exploratory-testing material as potentially transferable rather than directly written for automation.

7. Capture browser evidence from a test target

If your work around Selenium includes saving a page image for review or documentation, ScreenshotNeo is a website screenshot API and MCP server for developers. It can capture a URL as PNG, JPEG, WebP, or PDF. Its clean-shot flow accepts cookie and consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; those steps can be disabled. Only clean shots are billed: bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and the response identifies the page verdict and billing status in headers.

For a one-request capture, see the ScreenshotNeo API documentation:

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp
import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)
const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

Replace the example URL with a page you are authorized to capture. ScreenshotNeo also offers an MCP server for Claude, Cursor, and other MCP clients, with tools for screenshots, page information, and PDF capture. Its free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000. See ScreenshotNeo for product details.

Sign up for ScreenshotNeo free: 1,000 screenshots a month, no card required.

FAQ

Is “A Smattering of Selenium #62” a Selenium version?

No. It is the number of Adam Goucher’s roundup, published September 29, 2011.

Does the roundup prove that a particular test strategy works?

No. It curates opinions and links; the dossier reports no quantified findings or systematic evaluation in the post.

Does it explain current Selenium browser compatibility?

No. It is a historical link collection, so use current official Selenium documentation for present-day compatibility and setup information.

Is every linked idea specifically about functional testing?

No. The roundup notes that Harold’s Corollary is aimed at unit tests rather than functional tests, and describes the cited test-design book as intended for exploratory testing.

Keep reading