I want to tell New testers

I want to tell New testers

By Randall W. Rice, CSQA, CST, CSTM

Translation: skinapi

Preface
As I have been leading and training the test team for many years, I always have something to say to the test novice. Whether you are a beginner or an experienced testing expert, you must keep a lot of useful things in mind.

1. You are a reviewer and you do not need to be responsible for quality.
Many testers go astray and do not understand that they evaluate products rather than control products. There is a world of difference between the two. For example, a test team spends weeks testing and discovers many defects, just to watch the management decide to release a product with known and serious defects. Testing teams often feel frustrated and doubt their purpose.

I asked the Team members if they were paid. The answer is "yes ". I asked them if they tried their best to do their work. Once again, the answer is "yes ". I told them, "You did your job. You tried your best to test the vulnerability and reported it. Now you can go home and have a rest. In fact, the only failure of a tester is not to report a known defect ."

This will not boost morale, but will help things develop in the right direction, especially when people do not have to work at home every night.

Many testers, including me, seem to feel responsible for the quality of the system applications we tested when we started testing. Although the starting point of this work is admirable, our testers have basically no control over the quality of our products. For this reason, testers are not responsible for quality. The problem is that the management does not always see this difference. So we often see that the management team proposes something similar to "isn't we paying these people for high-quality software ?" .

2. All defects are valuable.
Every defect is an opportunity for in-depth understanding and improvement. We may only have one chance to observe a defect, so I always tell the tester to stay focused and not to get bored.

Defect information may be one of the most effective resources in the retrieved project data. But it all depends on how well we can capture and convey information about the defects we have found.

Each defect costs money for the entire organization. If we don't know more about products, we will waste a lot of time and money. When we turn an error into an opportunity of in-depth understanding, the leverage function will emerge. Let's face it-some lessons can only be learned through experience.

Blame for a defect does not have any good effect. Blame can only reduce morale and interrupt Communication. It's just like sending a dead horse to survive.

3. Everything was wonderful before you reported the first question.
This is the reality faced by testers. You can plan a test and obtain the required resources. It seems that everyone is on your side. However, when you report the first problem, the problem becomes tense.

The reason for this sudden change in attitude is that you are criticizing some people's work now. Self-esteem makes yourself hurt and the relationship becomes tense. In some cases, self-esteem is worth looking forward to, as long as you know that your attitude may change when you start to discover problems.

One thing I often suggest testers do is read some of the defect reports you have written in the past, assuming they are the ones who receive the defect reports. You will find that you need to be more sophisticated. Writing a defect report without any mining statements may be of little fun, but it does help maintain a good relationship with developers.

4. You can only test what you can observe.
You may always want to test some really creative use cases, but what is the significance if you cannot observe the results? Although some applications allow you to observe a lot, you still have no way to access them, such as structures, hidden objects, and background processes.

5. Don't forget how you got to a place.
I'm not talking about how you walk into a room, but how to perform the test. For new testers, it is common to discover a major defect, but it cannot be reproduced to locate and solve it. In this way, you will only feel uncomfortable and do not know whether you have actually discovered a defect or whether you just used the application incorrectly.

The methods you can use to track your test steps include test scripts, test records, keylogging such as Spector, and on-screen video capturing tools such as Hypercam.

6. Standards and procedures are your friends
Although standards and procedures are restricted, they provide valuable guidance for your work. Do not reject standards because they are detailed and specific. Therefore, they are used to guide you to complete your work faster and more consistent.

7. There is not enough time for testing.
Almost every tester complained that there was not enough time for testing, but it was impossible to test everything to the full extent. This is especially true when you fully consider software features such as availability, security, compatibility, and interoperability.

Do not complain about the lack of time, learn to prioritize risks, and focus on the application goals that are very important to the management. Sometimes the content we test exceeds what we need to test, because our goal deviates from the value of the product.

8. You cannot find all the defects.
Don't be discouraged if something you test is found to be defective later. You may have done a very comprehensive job and achieved a high level of defect removal, but 100% of them are impossible targets.

9. Maintain a sense of humor and confidence in prospects
Smiling and keeping healthy may be your best way to survive. If you are in a difficult situation, believe that everything will pass.

10. Strive for the best, not the perfect
New testers often fall into the process of pursuing perfection and believe that 100% of the correctness is the standard. I used to be one of the victims, but what I want to defend myself is that I was influenced by TQM posts and articles similar to "1980s is not good enough" in the later 99.9% S.

The problem with pursuing perfection is that it slows down the testing process and worries about introducing everything you do, making you more picky about others and often disappointing your friends and family.

Of course, no one is willing to make mistakes, but they don't pay attention to it. To avoid making mistakes is to deny the reality. Strive for a good habit, indicating your attitude towards your work and the degree of investment. If you want to do your best, you will go a little further.

According to my observations, most people are tolerant of errors or mistakes. People are most concerned about your response to the problem.

11. Developers are not enemies
The efforts of the entire project team are required to deliver high-quality products. Sometimes it seems that developers are not very concerned about quality. At this time, there may be hidden feelings behind things. At this time, you need to better cooperate with developers rather than oppose them. Always remember that good communication is a key factor for a successful project. When you stand on the opposite side with developers, the communication stops, and you cannot obtain much information you need for testing.

12. Establish and maintain a private communication network
Your private and work relationship is a very important asset. When you have a job or when you do not have a job, they are a good support system. Find a good mentor and become someone else's mentor when you learn enough.

13. Continuously exercise your skills
Your skills separate you from others. Continuously learn by attending professional meetings, obtaining certification, and reading professional materials. I set myself to read at least one book per week related to personal development and career development (testing, leading art, Business, IT, etc ).

Individual development experts have said that if you spend 30 minutes reading on any specific topic every day, you will certainly be an expert on this topic within five years. This works for me-You can try it.

Another good way to keep yourself informed and establish a network is to be active in some QA or testing forums.

14. When it becomes difficult to move forward, laziness requires creativity.
When I became the head of a test team for the first time, I put a note on my desk. It constantly reminds me of creativity as a lever for solving problems.

Learn to look at problems in a new and creative way. You may have a good test plan, but how do you cope with various changes? Elasticity is a key feature of an outstanding problem solving owner.

15. Simplicity is not always easy.
Much of the work we do in the test seems simple. However, the challenge is to maintain consistency of effort.

Some solutions seem simple at the beginning, but do not discard any idea because it is simple and obvious. Similarly, do not underestimate the effort required to implement a simple idea.

Some of the books I 've written with William E. Perry, "tutorial ving the Top Ten Challenges of Software Testing", comment that these Challenges are simple and easy to address. This makes me wonder why people are still asking people questions year after year ". I think it is much easier to create ideas in the brain than to implement them.

Conclusion
Wisdom is more important than knowledge. You may have learned a lot of testing techniques, but if you do not have enough wisdom to determine when to use them and do not understand them as a whole, your ability to apply them will be greatly limited. One of the problems you have with anyone involved is that "you don't know what you don't know ". Intelligence helps you understand what you need to know to succeed.

All of the above is what I hope I have fully realized at the beginning of the test. I hope they will help you.