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.

David Christiansen recently published an article on getting along with developers. Some tips from that article:

1. Don't editorialize the bugs you find


2. Stay in sync with the development cadence


3. Isolate bugs effectively


4. Sleep on bug reports

Check out the full article for details on each point.

Today's tip is guest written by Zachary Fisher.

Working as we do, it is easy to let skepticism become our default position on any statement made by any person. At any time. On any subject.

This behavior becomes maladaptive when we see ourselves as the only person who can be trusted. It thrusts the onus of proof onto ourselves and causes us to micro-manage every minute detail of our lives and/or project. This dysfunction reveals itself in subtle ways: we keep details from others while trying to figure it out, preferring to create tools rather than relationships, not delegating crucial tasks because someone else won't do it right; basically seeing ourselves as the hub from which anything done right flows.

As a manager of resources, i.e., people, time, money, etc, we should walk in the light of some truths:

(1) We can be wrong sometimes
(2) We will be wrong sometimes
(3) Other people can forgive
(4) Other people can help
(5) Grace abounds in humility

So if the project is taking on gargantuan proportions and you're being consumed by fears of catastrophic failure - take a step back and ask yourself if the task seems so great because you secretly envision having to do it all yourself. If so, kudos for being a responsible adult. Now, take a step of faith and give other people the opportunity to prove themselves as trustworthy as you've become.

In small companies especially, software testers get to perform lots of different tasks apart from testing. A software tester doesn’t just know how to use a new product, but invariably knows how to install, configure, work around issues, upgrade and back up data. Software testers will also know about minimum requirements and the applications limitations.

Not surprisingly, a good software tester starts to get a reputation of being a bit of a product expert. Someone people can come to to get product knowledge. Or someone who can setup demonstrations as well as perform them. This is very gratifying, but it can also lead to problems if it starts to impact your own work.

This can lead to stress and can often be a cause of resentment. It's best to try and manage this situations early on. I find the following approaches helpful:

1)      Learn to let go
Try not to perform tasks for people, but teach them the basics and let me go and learn it themselves. If lots of people are asking for the same thing, consider writing a short cheat sheet or posting stuff onto wiki.

2)      Learn to delegate
Always make sure someone else trains up with you. Don’t be the only person with all the knowledge. Make sure you share it by training up other team members.

3)      Learn to say no.
Sometimes its better not to take on work that is inevitably going to compromise your deadlines and deliverables. Say No, explaining why you are unable to help. You may upset people initially, but in the long term you are not doing anyone any favors by taking on too much work.  If your decision is overridden you may still have to go and do the extra work, but at least people are aware of the compromises being made.

If you are the only person who can fix things and you are overstretched, you are in fact more of a liability than an asset. Spread your knowledge and let you and your company benefit from your wealth of knowledge.

If your team already does some pair testing, take a look at promiscuous pairing.

"Promiscuity, it turns out, is a good way to spread a lot of information through a group quickly. Rapid partner swapping ensures that a good idea, once envisioned, is soon practiced by every pair. Replacing individual accountability with team accountability empowers each person to do those tasks at which he excels — and allow someone else to take over for his weaknesses."

Try 60 to 90 minute sessions where you alternate partners each session.