Testing Experience Issue 13, March 2011

Record card

What the links show

The March 2011 issue was published as testingexperience13_03_11.pdf and mirrored under the issues folder with the same name. Between the shapes it has fourteen referring domains; four used the raw URL as anchor. The highest-authority linker is a long-running Chinese software testing blog whose 2010 archive page links the file directly, which is notable because the blog's own post predates the issue: the link was added to an older reading-list post when the issue came out, a habit of curated blogs that keeps links alive for years.

The Portuguese theme index for the magazine (the same source that gives issue 12 its open source tools theme) includes 'Dominios de Teste', test domains, and the timing places that theme with the spring 2011 issue. Testing by domain (finance, medical devices, automotive, telecoms, games) was a recurring interest of the magazine, which circulated in a European market where regulated-industry testing is a large part of the profession. This record labels the theme 'as cited' and does not name the domains the issue actually covered.

The issue's links also include the first Eclipse Testing Day media partner listing (the wiki page for the 2011 event links the homepage) and a Hungarian tester community page that used the magazine's editor's name as an anchor, in Hungarian ('Jose Diaz irja', Jose Diaz writes). By 2011 the magazine was being read and summarised from Portugal to Hungary to China.

There is no single guide on domain-specific testing on this site yet (it is on the backlog), so the continuation for a reader who followed a 2011 link is risk-based testing, which is how regulated domains decide what to test hardest, and TMMi, the maturity model most often used in those industries. The issue index lists the neighbouring issues.

The fourteen domains on issue 13 divide by how the link was made. Four pasted the raw URL. The Chinese blog linked from a curated archive page, which is a maintained list rather than a dated post. The Hungarian community page used the editor's name as its anchor, so its link is about the magazine rather than this issue and reached the file through a listing. The Eclipse Testing Day wiki links the homepage rather than the file, and is mentioned here only because it dates the media partnership to the 2011 event. Root and issues-folder names carry the same string, testingexperience13_03_11.pdf, so the two shapes differ only by folder, and about 30 links across fourteen domains is the ordinary two-per-domain profile of readers sharing a download.

A reader who followed a spring 2011 link expecting articles on testing in specific industries wanted to know how a regulated domain decides what must be tested to what depth, and how it proves that to an assessor. The risk-based testing guide answers the first: its 5 by 5 matrix (Figure 1) scores likelihood times impact, and the table under allocating effort by risk class maps each class to depth, techniques and share of effort, with a six-feature worked example. The TMMi guide answers the second: its table lists the sixteen process areas of TMMi release 1.3 by maturity level, and its section on how a formal assessment runs describes what an assessor asks for. For a domain where security is the regulated property, the security testing guide's five-type table applies.

Domain testing in 2011 meant, for most European readers, testing under a sector standard: medical device software, automotive, rail and finance each had their own. What changed by 2026 is the amount of shared ground. ISO/IEC/IEEE 29119 gave the sector standards a common test process to reference, and the TMMi model, maintained by the TMMi Foundation and now at release 1.3, became the maturity framework that regulated organisations in those sectors most often assess against, because its process areas (test policy and strategy, test planning, test monitoring and control, test design and execution, and test environment at level 2; peer reviews and non-functional testing among the level 3 areas) map onto what an auditor asks to see. A domain-specific guide is on this site's backlog; until it exists, the risk-based and TMMi guides are the honest continuation.