Picture a boat anchor made out of stacks of paper.

That's what I call a paperweight - a tester who literally drags down projects because of the amout of paperwork they generate and/or require. They don't add value, they just add paper (digital or physical).

Dave Christiansen often talks about being an asset. Paperweights are on the opposite end of assets, they want you to do stuff for them. You need to provide them with information. You need to provide them with an environment. You need to provide them with test data. You need to clarify their requirements. You need to ...

A paperweight can't do, they can only ask...

It's been a while since I've encountered a paperweight. Recently, I've seen one in action. They are a visible drag on progress. They slow down the project, without adding value.

Don't do that.

Recognize that nothing about testing dictates that you need to be a drag on the project. That doesn't mean you can't ask for things. It doesn't mean you can't raise issues and risks when needed. But always always always do it from the position of being an asset to the project team. If you're doing that, trying to help move the project forward in the safest way possible, you'll have nothing to worry about.

When working large test projects, I have a couple of matrices that I try to develop early on to better understand who's doing what, where are they doing it, and when they are doing it. These include matrices that show:

• type or phase of testing by owner (including specific scope of coverage by team)


• type or phase of testing by environment (including data needs/integration dependencies)


• type or phase of testing by iteration (including dates, resources, and summaries of coverage for each iteration)

For me, these three views of the project can often paint a summary picture of everything that's happening. This allows me to quickly communicate to other project managers involved in the project or program. It also allows me to communicate updates in a format that those same PMs will take the time to look at. (I find very few people even bother to look at a 30+ page document that's been updated.)

When I start test planning for a large testing project (large to me is defined a couple of ways: length, number of people, or budget), often I'll start like everyone does by creating a test strategy. For me, early on ideas are fuzzy. I'm learning about the project goals. I'm often learning about the company and their business. Or I'm learning their processes, tools, regulations, and people. There's a lot of ambiguity about what we're going to do and how we're going to do it.

One thing I've found that really helps at this stage of the project is to create testing workflows for each type/phase/stage of testing that we'll be doing on the project. When I say workflow, I mean a simple one page flowchart diagram of the activities involved in testing some "thing." From where the requirements are coming from, to how we're capturing tests or test ideas, to how we're executing them and storing results. I'll often put the key decision points in there and show how those affect process flow.

I'll then circulate these workflows among the project team to solicit feedback. You'd be amazed how helpful this is for everyone - not just me. Often, other people in the project don't know exactly what the testing team is doing. They are work from assumptions that have on what you need, when you need it, and what you'll do with it. Detailed workflows like this dispel those assumptions.

Another quick tip: For all those testing project managers out there, workflows like this serve another purpose. Once you have them done, you basically have a work breakdown structure for each type of testing you'll be doing on the project. And it's in a much more accessible format than a mpp file.

Many of you may have already watched the Google video about testing on the toilet, so forgive me if I bore you, but I truly found this video inspirational.

Its a story on changing the testing culture within an organization.

The key points that struck me where:

• The testers had a high profile stakeholder who championed and explored their cause.


• They didn't try to sell testing themselves, they looked for volunteers from all over organization to come up with ideas to change the culture


• They didn't try to apply a 'one approach fix all' to all groups. Instead new staff were trained up during orientation, and existing staff were trained through free talks


• When one approach didn't work, they changed it and tried something different. They never gave up.

There is much more in this entertaining video here's link to watch it yourself. Its about 3o mins in length.

UX Booth (and author Matthew Kammerer) posted a fantastic article on user friendly content. In the article he covers a couple of topics that I think work well as test heuristics:

• Avoid using abbreviation


• Make headlines and opening sentences "scanable" by making them your most informative content


• Make paragraphs smaller


• Check the reading level of the content


• Use active voice

In the article he provides some good links to related content.