Some people struggle with saying no. It happens for a lot of reasons:

• we want to please others


• we really do want to do what we're committing to


• we are afraid to say no


• etc...

Here are some tips for saying no that I've found helpful:

• Force prioritization: "If I do that, something else needs to fall off my plate. What would you like that to be?"


• Remind them about long term effects: "If we write this code without writing our tests according to our methodology, in six months you'll regret it when we need to refactor this section of the code."


• Clarify that you're being asked to do something you can't: "You recognize that you're asking me to make a commitment that I can't really make, correct?"

However, no matter how you sugar coat it nothing beats a plain-spoken "No, I can't or I won't do that."

Practice it. No is more difficult than yes. Especially if you're saying it to yourself. Trust me when people would rather hear "no" upfront then have you say yes and then they don't get what they wanted.

The harsh reality is that in the tech world, companies prefer to hire young, inexperienced, engineers.

This is the first statement given in article "Silicon Valley’s Dark Secret: It’s All About Age". The author also gives advices "to those whose hair is beginning to grey", where main of them is:

Move up the ladder

Move up the ladder into management, architecture, or design; switch to sales or product management. Build skills that are more valuable to your company, and take positions that can’t be filled by entry-level workers.

As I think this is an honest advice, I don't consider it the only advice. If you are passionate about your technical job you can keep up as long as this kind of job is needed - and that fully applies both to testing and programming.

More specific to testing, I want to note the following.

• Build and consistently demonstrate ability to accomplish more in less time. Maybe you can't always stay at work 60 hours a week but you will be able to get the job done in regular hours, if you practice time management, risk assessment, and problem-solving heuristics.


• Learn from projects you work on. Whether it's content management system, an online banking application, or back-end VOIP cluster, learn and consciously integrate into your expertise both domain-specific knowledge and "soft", transferrable, approaches.


• Learn about and try practicing technologies you work with. Use collaboration opportunities, talk with other passionate specialists - they will love to teach you.


• While developing technical skills build big picture vision as well. Technologies come and disappear, problems and problem-solving techniques remain.


• Stay passionate.

Eric Jacobson recently posted his excellent analysis of resumes he's been reviewing since his team is hiring. Here's a short snippet:

However, the candidate would have probably gotten an instant interview if they had included any of these:

• My approach to testing is as follows…


• See my software testing blog for my opinions on how to test.


• My favorite testing books and blogs are…


• I enjoy testing because…

I really like the first one. I suspect that for some, it's a challenge to write that in a short format (like what I think you'd see on a resume). But there's no reason you couldn't summarize something in a paragraph on a resume and provide more details in a cover letter (perhaps tailoring your approach a bit for the prospective hiring company).

Does your resume include any of those points? I agree with Eric, it should.

Here's how I can tell I need help:

• I'm working at 1:00 AM and it's not because it's required (like some performance testing) or because I really like doing it (too much cool software and not enough daylight time).


• People are talking about something that needs to be tested and I can't follow the conversation (due to a lack of domain knowledge or technical knowledge).


• I'm missing deadlines (for the project I'm struggling with or for other projects because I can't get away from the project I'm struggling with).


• I'm not happy with the quality of my work.

If one or two of those happen for a short period of time, I probably need help. If all of them are happening (like they are right now), I know I need help.

When you need help, ask for it. That's easy to say, but hard for a lot of people to do. I know it's hard for me. I also know it's hard for many people who've worked for me. For me, it's an ego thing. But sometimes I need to recognize that I'm not helping anyone (most of all myself) by trying to hide the fact that I need help. Often, help is there - ready and waiting to be had.

If you're overwhelmed, ask for help. You might be surprised where it comes from.

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.