Testing Experience Issue 12, December 2010

Record card

What the links show

The December 2010 issue was the second file under the new naming scheme, testingexperience12_12_10.pdf, and was also mirrored as issues/testingexperience12_12_10.pdf. The root file has 17 referring domains and 335 links; seven of those domains used the raw URL as the anchor, the highest count for any issue file. The mirrored copy adds two more domains. Links come from a Russian technical community site, Chinese and Korean testing blogs, a Polish tester's knowledge base that lists magazines worth reading, Portuguese quality blogs, and English tester blogs and forums.

The Portuguese theme index for the magazine includes 'Ferramentas Open Source' (open source tools) and 'Automacao de Testes' (test automation), and the timing and volume of the issue 12 links match a special issue on open source testing tools that readers in tool-heavy communities shared widely. That is the theme recorded here, hedged as 'as cited': the anchors do not preserve article titles, and this record does not name any tool the issue covered.

Why would a tools issue be the most shared? Because in 2010 the open source testing tool landscape was changing fast, comparative overviews were rare, and a free PDF that surveyed the field was worth passing around. The same need exists now, which is why the open source testing tools guide exists on this site. It deliberately describes tool categories, maturity signals and licence families rather than naming products, so that it stays true as products come and go.

For readers arriving from a 2011 forum link, that guide and the test automation strategy guide are the current continuation. The Test Automation hub holds the rest.

The link shapes tell you how issue 12 was shared. Seven of the 17 root-file domains pasted the raw URL as anchor, the highest count of any file, and 335 links from 17 domains is nearly twenty per domain, which means forum threads and category pages where the same link repeats. The linking sites divide by language and by kind: a Russian technical community site (a forum, where a link is quoted in replies), Chinese and Korean testing blogs, a Polish knowledge base that lists reading for testers, Portuguese quality blogs, and English tester blogs and forums. Six languages on one file is unmatched in the run. The mirrored issues/testingexperience12_12_10.pdf name adds two domains. None of the anchors names an article or a tool; the theme rests on the Portuguese theme index and on the kind of communities that shared it, which is why the record says 'as cited'.

A reader who arrived from a 2011 forum thread wanted a survey of open source testing tools: what exists, which are mature, what the licences allow. The open source testing tools guide answers each part without naming products. Its Table 1 sets out eight categories with what each does, the maturity signals to look for and the typical licence family. Its ten-point evaluation checklist runs from release cadence (a release in the last six months) and issue health (median age of open issues under 90 days) through contributor spread, breaking-change discipline, documentation, language fit, CI integration, extensibility and licence compatibility to exit cost. The section on how to run a bake-off is the method for choosing between two finalists, and the test automation pyramid guide explains why the unit-level category dominates adoption.

Between December 2010 and 2026 the questions a tester asks of an open source tool changed. In 2010 the questions were whether the tool worked and which licence it carried; the Open Source Definition, unchanged in substance since 1998, settled what counted as open source, and licence family was the main risk. Since then the risk moved to the supply chain: whether the project is maintained, who has merge rights, whether releases are signed and whether the dependencies the tool pulls in are themselves safe. The Open Source Security Foundation, formed in 2020, publishes the criteria (maintainer count, release signing, dependency update policy) that a 2026 evaluation checks and a 2010 one did not. The guide's checklist reflects that shift: half of its ten points concern project health rather than features.