Knowledge Transfer: The Tutorial Series
Alongside the magazine, its publisher ran a series of short practitioner tutorials under the name Knowledge Transfer. One is known by title: a tutorial on agile program management, offered in early 2011. The format is worth keeping, and this page explains how to run one in-house.
Archive featureUpdated
Browse all 28 issues
Every issue with its date and theme, and the twelve that have their own page.
Open the issue indexWhat the series was
The publisher of Testing Experience was a testing consultancy and training company, and Knowledge Transfer was its tutorial series: short courses taught by experienced practitioners for testers and test managers. The catalogue itself is not covered here, and only one tutorial is known by title. That one, Agile Program Management, was offered in early 2011 and promoted to the magazine's newsletter readers in the same way the issues were. It is continued on this site by the agile program management guide.
The publisher's media partnerships, such as the Eclipse Testing Day, belonged to the same events-and-training side of the business. The tutorials are no longer offered; the training business belonged to the original publisher and is not part of this site.
Three sessions a year with two artefacts adopted is a better training history than twelve conference days with none.
What knowledge transfer means
The phrase describes a particular kind of course: a practitioner with deep experience of one subject (program management across several agile teams, say, or test process improvement) teaches a small group over one or two days, with exercises drawn from the participants' own projects, so that the knowledge transfers rather than being presented.
It is worth keeping the idea even though the original series is gone, because most test teams still learn by sending one person to a conference and hoping.
Running a session in-house
A knowledge-transfer session a test lead can run in-house has five parts. Pick one subject narrow enough to finish (writing a risk-based test plan for the next release, not 'test management'). Choose the teacher for experience, not seniority. Insist that every exercise uses the team's real artefacts: the actual backlog, the actual defect list, the actual pipeline. Set an output the team leaves with (a plan, a checklist, a decision). Schedule a 30-minute follow-up two weeks later to see what stuck. Two half-days beat one full day; people retain more when they sleep in between.
The guides on this site are written so that each can be the reading for a session: the test plan guide has a template table, exploratory testing has charter templates and a session structure, risk-based testing has a scoring matrix. Use them as the pre-reading, then spend the session applying them to your own product.
A one-day agenda that transfers
The day is built around one decision. For a risk-based test plan, that is which of the next release's features get deep testing and which get a smoke test, and the teacher states it at the start. The agenda below follows that decision through to the follow-up.
Two half-days on consecutive mornings hold the same content with better retention.
Choosing the subject and the teacher
A subject qualifies if it can be finished in a day and produces an artefact. Risk-based test planning, writing charters for exploratory sessions, scoring automation candidates and writing a layered definition of done all qualify; 'test management' and 'agile testing' do not. The teacher should be the person who has done the thing on a real project most recently, which is often not the most senior person present.
A tutor from outside is worth paying for when nobody inside has done it; the original series existed for that case, and its one tutorial known by title, Agile Program Management, is a subject where experience is scarce inside most test teams. The agile program management guide that continues it opens with a figure of one program backlog feeding four teams and a table dividing responsibilities between team level and program level, which is a usable pre-reading for that session.
Measuring whether it transferred
Three checks, two weeks later. Did the artefact leave the room and enter the real process (is the risk scoring in the actual plan; are the charters in the actual session log)? Can a participant who was not the presenter explain the method to a colleague in five minutes? Has the team made one decision differently because of it? If the answer to the first is no, the session was a presentation whatever it was called, and the next one should start with the artefact and work backwards.
Keep the count: sessions run, artefacts adopted, decisions changed. Three sessions a year with two artefacts adopted is a better training history than twelve conference days with none.
At a glance
Questions
What was Knowledge Transfer?
The tutorial series run by the publisher of Testing Experience: short courses for testers and test managers, taught by experienced practitioners.
Which Knowledge Transfer tutorials are known?
One by title: Agile Program Management, offered in early 2011. This site's agile program management guide continues that subject.
Are the tutorials still offered?
No. The training business belonged to the original publisher and is not part of this site. The sections above describe how to run a knowledge-transfer session in-house.
How long should an in-house session be?
One day, or better, two half-days on consecutive mornings, with a 30-minute follow-up two weeks later to check what was adopted.
Which guides work as pre-reading for a session?
The test plan guide, the exploratory testing guide and the risk-based testing guide are each written to be read before a session and applied during it.
