1. You are an inspector - You can't guarantee quality.
Many testers get sidetracked by not understanding that they assess things, not control them. There is a huge difference between the two! For example, a team may work weeks on a test and find many defects, only to see management decide to release the product with known serious defects. The team often feels demoralized and asks why they even do testing.
I ask the team members if they got paid, and most of the time the answer is "yes." I ask if they did their jobs to the best of their ability, and once again, most of the time they answer "yes." I then tell them, "You did your job. You tested to the best of your ability, found defects and reported them. Now, go home and relax. In fact, the only way you can fail as a tester is to fail to report a discovered defect or to fail to perform a specified test."
This may not improve morale much, but it does help keep things in perspective, especially in having the ability to not take the daily frustrations of work home every night.
Many testers, me included, when we first start out in testing, seem to feel personally responsible for the quality of the application or system we are testing. While the work ethic is admirable, we testers really have little control of the product quality. It is for this reason that testers do not ensure quality. The problem is that management doesn't always see that distinction. This is seen when management asks questions like, "Aren't we paying these people to have good software?"
2. Defects are valuable.
Each defect is an opportunity to learn and improve. We may only get one opportunity to observe a defect, so I always tell testers to be observant and not fall prey to the boredom of testing.
Defect information is perhaps one of the most telling sources of project data available. However, that depends on how well we capture and convey accurate information about the defects we find.
Each defect costs the organization money. If we don't learn from them, we are wasting a lot of time and money. The leverage happens when we convert a mistake to a learning opportunity. Let's face it-some lessons are only learned by experience.
It doesn't do any good to place blame over a defect. All blame does is lower morale and shut down communication. It's like beating the proverbial dead horse, hoping it will come back to life!
I wrote an article called "Defects are Good" which explores in more depth about the positive side of defects.
3. Everything is fine until you report the first problem.
This is where the reality of being a tester sinks in. You can plan the test, get all of the needed resources in place and it seems everyone is on your side. However, things tend to get tenser when you report that first problem.
The reason for the sudden change in attitude is that now you are criticizing someone's work. There is a pride of ownership that causes egos to be bruised and relationships to be strained. Some of this is to be expected, just be aware that attitudes may change when you start finding problems.
One thing I always suggest to testers is to read some of your past defect reports as if you were the recipient. You may find that you need to be more diplomatic. (See how gently I said that?) It may not be as much fun to write a defect report without sarcasm, but it will help maintain good relationships.
4. You can only test what you can observe.
You may want to test that really creative case, but if you don't have a way to observe the results, what's the point? Although some applications allow you to observe a lot, there are still things you may not have access to, such as structural views, hidden objects, background processing, etc.
5. Never forget how you get someplace.
I'm not speaking about knowing why you walked into a room, but of the steps you took in testing something. It's common for beginning testers to find a significant defect, only to fail to recreate it for resolution. Then, you're left with the uncomfortable feeling of not knowing if you truly found a defect, or just used the application incorrectly.
Some ways you can trace your steps include test scripts, a test log, keystroke loggers such as Spector (http://www.spectorsoft.com/) and screen video capture tools such as Windows Media Encoder (http://www.microsoft.com)
6. Standards and processes are your friend.
Although the idea of standards and processes may seem confining to some, they give you valuable guidance in doing your job. Don't reject standards because they may be detailed and lengthy. Instead, use them as a guide to do your job faster and more consistently.
7. There's never enough time for testing.
Almost every tester complains there is not enough time for testing, but the reality is there is never enough time to test anything to a degree of completeness. This is especially true when you consider software attributes, such as usability, security, compatibility, interoperability, etc.
Instead of complaining about the lack of time, learn to prioritize based on risk and focus on the application objectives important to senior management. Sometimes we test more than we need to because our objectives are out of line with what the sponsors value.
8. You can't find all of the defects.
Don't get discouraged if a defect is found later in something you tested. You may do a very complete job and achieve a high level of defect removal, but 100% is an elusive goal.
9. Maintain a sense of humor and perspective
Being able to laugh and keep a healthy sense of balance may be your best survival mechanism. If you are in a bad situation, remember, this too will pass.
10. Strive for excellence instead of perfection
New testers often get caught up in the quest for perfection with the attitude that 100% correctness is the standard. I was a victim of this as well, but in my defense, I was influenced heavily by the TQM posters of the late 80's and articles such as "99.9% Isn't Good Enough."
The problem with perfectionism is that it will make your progress slower, introduce fear into everything you do, cause you to become more critical of others, and generally, drive even your friends and family to the point of despair.
Of course, no one wants mistakes, but they happen regardless. To think otherwise is to deny reality. Excellence is a habit that is shown in your attitude and dedication to the work you do. If you are committed to be the best, you will go the extra mile.
My observation is that most people are forgiving when they see a mistake or experience a lapse in service. The thing people pay the most attention to is your response to the problem.
11. Developers are not the enemy
It takes the entire project team to deliver a quality project. While it may seem at times that the developers don't care about quality, there may be more issues than meet the eye. You will make more progress by working with developers instead of against them. Remember that good communication is a major key to successful projects (and testing). When you take an adversarial position, the communication stops and so does much of your information needed for testing.
12. Build and maintain a personal network
Your personal and professional relationships are a great asset. They are a support system that can help when you have a job and when you don't. Find a mentor and when you learn enough lessons, become a mentor to someone else.
13. Keep building your skills
Your skills are what distinguish you from others. Always keep learning by attending professional meetings, obtaining certifications, and reading in the profession. I make it a goal to read at least one book a week on topics related to by personal and professional growth (testing, leadership, business, IT, etc.).
One personal development guru noted that if you read 30 minutes a day on any given topic, in five years you'll be an expert on the topic. It worked for me-try it for yourself!
Another great way to stay sharp and to build a network is to stay active in some of the QA and testing forums. Some of my favorites are at www.stickyminds.com, www.qaforums.com.
14. When the going gets tough, the lazy get creative
I made a sign with this saying on it and hung it on my desk when I first became a test team leader. It reminded me to let creativity be my point of leverage in problem solving.
Learn to see problems in a new and creative way. You may have a good test plan, but how will you deal with changes? Flexibility is a key attribute of good problem-solving leaders.
15. Simple is not always easy.
Much of what we do in testing seems simple. However, the challenge is in the consistency required to maintain the effort.
Some solutions to problems may seem too simple at first, but don't discard an idea just because is it simple and obvious. Also, don't underestimate the effort needed to implement a simple idea!
Some readers of the book I co-wrote with William E. Perry, Surviving the Top Ten Challenges of Software Testing, have commented that the challenges are simple and easy to solve. That makes me wonder why people still raise the same "people problems" year after year. I think it is easier to obtain the head knowledge than to actually implement the solutions at work.
Conclusion
Before knowledge, comes wisdom. You may learn a lot of testing techniques, but your ability to apply them will be limited if you don't have the wisdom to know when to apply them and the context to understand them. One of the problems you have in starting out in just about anything is that "you don't know what you don't know." Wisdom helps you understand what you need to know to be successful.
The things I have listed are things I wish I had fully realized when I first started testing. I hope they serve you well.
As always, I would like to hear your comments about things you would have liked to known as a rookie tester. Just e-mail me from the contact page.
