Tips from New Testers
Tips from Veteran Testers
Tips from Veteran Engineers

Tips from New Testers

A brand new tester writes:

"I have learned two very important things in my three months here, which I think will see me far in the business world.

1. The first is that very, very few people know what they're talking about. So I don't feel bad -- and in this business, saying "I don't know that -- will you explain it to me?" doesn't seem to be a bad thing. The people who don't know feel like they're safe around me, and the people who do see me as honest.
2. The other big thing I've learned is that speaking confidently when I don't know what's going on can cover up for my lack of skills, when I'm talking to people who don't know either."

A new tester with six months experience writes:

"If you take Practical Software Testing you can be confident in your abilities as an Intellitest-trained software tester. If you forget everything else, remember the mantras. I've been working on my "Jeckle & Hyde testing," which is using two separate testing personalities. The Dr. Jeckle tester is the mild mannered, garden-variety end user that just runs the apps or sites for what they are, and then there's the Mr. Hyde tester that has nothing but diabolical plans for the crashing of the app or site!"

A tester with one year's experience writes:

"One of the things I like most about software testing is that I am constantly challenged and continually learning in this ever-evolving world of technology."

Tips from Veteran Testers

A veteran tester of over 10 years writes:

"The most important things you need to know to be a successful tester...

• You can never find all the bugs, you can only make the product as good as you can in the time you have available.
• Know when to pick your battles. Some bugs may drive you nuts, but they aren't worth a fight, others will drive users nuts and must be fought for.
• It's very important to have a good relationship with the developers/programmers/engineers. They are the ones who will help you and answer questions for you.
• Try not to say 'I told you so' when the pet peeve you had about a product comes back as a fire-drill fix."

A veteran tester and test manager of 5 years writes:

"Sweat the small stuff but remember that you have the same goals that the developers do -- ship a product that works. It's not us against them (QA vs. Development). Sure, everyone would like to have more time to test their products, but remember what's important: if you never ship product your company dies."

A veteran tester and test manager (who manages remote testers) of 4 years writes:

"The best testers are the ones that can change assignments quickly, can work with minimal supervision and have a working knowledge of the concepts presented in Intellitest's Practical Software Testing."

A veteran tester and test manager of over 15 years writes:

"When Intellitest tells you that the two most important skills that a tester has is knowing where to find the bugs and knowing how to write them up, they are so right on. You will have good relationships with engineers and managers if you can master these two things and you will not be effective in this business if you do not have good relationships.

As a manager, my biggest frustration is when a tester has made a commitment to do something by a certain date and then they don't do it, don't inform me or don't inform me early enough that I can either juggle their assignments or assign someone else to it. In many cases I've made promises to the team that the assignment will be done. Being honest and letting me know you can't get it done is a good thing. If you don't get it done and don't give me a chance to get it done you really make me look bad and that... really pushes my buttons."

Tips from Veteran Engineers

A veteran engineer writes:

"Ultimately, the best user testers are the people who can climb into a user's head, look around, ask some smart questions, then climb out again and tell the world what happened. Few people can do that, but when they can, the feedback they offer product developers can be worth it's weight in gold."

-- The Right Web Job For You
Mike Kuniavsky, article originally on WebMonkey

A veteran engineer and project manager of over 20 years writes:

"The best testers are the ones that can write a bug specifically enough and clean enough so that it can be quickly reproduced and fixed. My favorite testers to work with give me serious bugs with clear steps to reproduce, and clearly identified what was wrong and what they expected to happen."

A veteran engineer of over 17 years writes:

"The one liner: Testing is hard. If it was easy, programmers would do it.

The view from here:
I've been writing consumer software applications and tools for seventeen years. In all that time, the push to add more features to the product has remained fairly constant. We need those checkmarks on the box. But the features themselves have become larger and are built out of components that are made by a variety of teams in a variety of companies. Some "old timers" lament "code bloat", the mushrooming of the disk and memory requirements of applications. This code bloat is a direct result of the complexity of features, and the resulting complexity of applications.

Time was when just getting your app to print to more than one kind of printer was a big deal. Today, printing to more than one printer has become easy. But, no one asks us to do that. Now what they want is to use JavaScript in HTML pages to fetch data from the app and integrate it with E-Stamp so customers can print both postage and addresses on the envelopes. On any printer on their intranet. At least that last part is easy!

We want customers to be able to sign up for server-based services that integrate with the desktop product. We want to vacuum customer preferences and send them to the server when they are online so we can target ads to them. We want billing services and credit card lookups and web-backups of the data and off-cycle add-ins written in any language by some team we hire in the future and so on and so forth.

So, code has increased in size exponentially. As processor speeds double every 18 months, so too does the size of the products we make and you will test. Much of the code being executed was not written by the people who wrote the product. A lot of that comes from Microsoft. But, not from just one team at Microsoft. There are the various OS teams (NT, Win 95, Win 98, Win 2000), the Internet Explorer team, the folks working on the XML products, the COM products, the various Active-X developers, the Visual Basic team, the C++ team, and others we will never know about. And they are developing some of this in conjunction with standards that are in flux and being developed by consortiums.

The "popular consumer product" I work on runs 98 DLLs as a part of starting up. 35 of those were developed by various teams inside the company, most of the rest by Microsoft, but a few by printer manufacturers, video card manufacturers, and so on. We can insist on some of the DLLs being "at least version X", but of course customers upgrade their machines with new OS's and new versions of products we depend on all the time. So we don't really know exactly what set of things any customer will be running.

Now we ask you to insure that the product works. Has quality. Holds together. Is compelling. Runs on most machines. On all flavors of Windows. On our "target minimum machine". You will be the last people to see the product before it ships, the last ones who can raise the alarm that something isn't right. But we may tell you it HAS to ship, we are out of time. We may tell you we can't possibly fix this problem. You will be under-appreciated. Your schedule will be the one that can't slip, even though code was turned over to you late.

But you must stand firm. You must raise doubts. Question authority. If you don't, who will? If you are ignored, then management is throwing away their money. If you are insulted, berated, brow beaten, know that you are right. Your job is to point out all the flaws in the program. All the risks. All the annoyances. If they choose to ignore them, so be it. You represent the customers. More importantly, you represent the investors who trusted your managers with their money. They want you to do a good job.

We programmers desperately want you to do a good job. At times we may say we want you to go away and leave us alone. But we really do want you to find out what we screwed up. Any programmer that doesn't isn't worth keeping. Better that you know our human foibles than that the customers know. To paraphrase Vidal Sassoon, if you don't do good, we don't look good.

Good luck, we're all counting on you!"