Software Testing (ii) six years of software testing sentiment

Unknowingly already engaged in software testing for six years, 2006 graduation to enter the outsourcing company outsourcing to Microsoft to do software testing, to now join the famous foreign enterprises. It's been a fast six years. The long-term testing work also let me have a more in-depth understanding of software testing. But I am still a low-level tester, my views are relatively narrow, if there are errors, please criticize the correction.

Read the catalogue:

1. Software testers should be vigilant
2. Testers should be more familiar with business requirements than developers
3. Learn how to get along with the developers
4. Testers should be able to understand some basic programming
5. Testers Build development environment
6. Writing documents is the core competency of testers
7. A two-day cross-test should be done later in the test
8. Testing staff Bottlenecks
9. Automate as much as possible
10. Automated Testing vs Manual testing
11. The technology of automated testing differs too far from the technology used in development
12. The most depressing is the inability to understand developer discussion techniques
13. Excellent testers are scarce.
14. Most of the test managers have a background in development.
15. Software testing is really boring, it takes a lot of effort
16. English is the lifeline of testers.
17. Use less UI Automation testing, more unit testing, and interface testing

Software testers should be vigilant

When the economy is bad and the company's performance is bad, the company is likely to make layoffs. The first thing to cut is the tester. Because the tester's technical level is relatively low, easy to be replaced, it is easier to recruit. Companies often take the test personnel first surgery.

As testers, although most of our usual work is more comfortable. But never boil a frog in warm water. Should strive for self-improvement, like a developer, continue to learn, improve their programming level. In this way, a new job can be found quickly even if it is cut.

Testers should be more familiar with business requirements than developers

The level of testers is mainly embodied in the design of test cases. Designing comprehensive, wide-coverage test cases requires testers to be familiar with the business requirements of the project they are testing, even more than developers.

If it is a test banking system, communications industry, or ERP software. These business knowledge is very useful, learning is more passionate.

It is difficult to be proficient in business requirements.

1. To familiarize yourself with the functional requirements documentation, check with PM for any questions you have in place.

2. Treat yourself as an end user, often using the software you have tested. Simulates the user's behavior.

3. Memorize every feature of the software.

If unlucky encounter some useless, cumbersome software, really do not want to learn its business (out of this company will no longer use the business)

Learn how to get along with the developers

Testers must work closely with developers, so it is important to have a good relationship with the developer.

1. Make friends with developers.

It's easy to be familiar with what you do

2. Do not disturb the developers

When you see the development of writing code, do not disturb others. Writing code requires a concentration of effort, and if disturbed, it interrupts thinking.

3. Concentrate on asking questions.

Sum up the questions that need to be asked, and focus on the development so that you can save a lot of time.

4. Write bugs, not bothered by developers.

If a developer sees a bug description that is unclear and cannot be reproduced, he will certainly scold the tester. So testers must write a good bug, describe the precise, concise, no ambiguity, detailed and concise steps to reproduce, plus.

Testers should be able to understand some basic programming

Your product is developed in C #, and testers should have the knowledge of C #. You test the Web program, you should at least understand html,css, Javascript, jquery bar, or you measured a year or two of the Web program, do not know how this thing is done, tragedy it.

Only by understanding the code can you communicate with the developer and not be despised by development.

Testers Build development environment

Product code is the best learning materials, we can not always follow the development of the butt of the test, not always wait for the development build a version, we test this version, the development of check in what code, testers do not know. Occasionally we should understand how the product code is designed to understand how the developer fixes the bug. Perhaps the level of programming is high, but also to help develop code review.

Use the Source code tool to check out the product code to this machine. Often look at the code, often look at the development of bug fixes when the code submitted.

Writing documents is the core competency of testers

I remember my previous test lead saying that she was able to be a lead because she was very good at writing documents and sending emails. Writing documents needs to summarize the ability of induction, but also logical clear. She is very good at analyzing the dozens of-page spec and writing out a dozens of-page test plan. She is also very good at summarizing test reports. A complete, clear and beautiful test report is sent to each group every day, so that all the people in the company can clearly see the work of the Test team.

Under her leadership, we have summed up a number of documents, such as "New hire Checklist", "on boarding traning", the documentation used by the test tool, and so on.

After I wrote more blogs, I found that my ability to write documents improved a lot.

A two-day cross-test should be done later in the test

Cross-testing means that two test engineers exchange tests with each other. There are many advantages to doing so.

1. Help to find bugs, test engineers to measure their own projects, easy to form eye blindness. will be blind to some bugs.

2. Conducive to knowledge and business sharing, to avoid staff turnover, leave, resulting in unmanned testing situation.

3. Test ideas are different, can find a lot of problems with each other

Testing staff Bottlenecks

Manual test work for two or three years, basically can master the most knowledge of the test needs, if not climbed to the test lead position, many people feel the development bottleneck, repeat the test every day, learn nothing, will soon lose enthusiasm for the test work.

Learning nothing, low technical level, is the biggest problem in testing the industry.

How to break the bottleneck? I don't know.

Automate as much as possible

Take the time to make the most of your test work to automate, you can save time to test, improve your level of technology, you can also avoid repeated testing.

Automated Testing vs Manual testing

Now a lot of companies recruit test requirements more and more high, a lot of good companies recruit senior QA, all require more than 5 years work experience, master a programming language, has a wealth of automated testing experience. Of course, the benefits of automated testing will be much better than manual testing.

Automation is a trend, only the people who do manual testing, will certainly lose competitiveness in the future.

The technology of automated testing differs too far from the technology used in development

Before many colleagues wanted to be developed by testing, now a few years passed, or did not turn into, they originally wanted to use the technology of automated testing to accumulate, go to do development. The technology used for automated testing is far from the technology used to develop it.

Test turn development? Difficult

Try to learn the code, then use it for testing, is the right path

The most depressing thing about testing is the inability to understand developer discussion techniques

Sometimes it's a meeting with the developers, and the developers at the meeting have a heated discussion. And I do as testers basically do not understand this group of development to say what, at all, can't plug in words. I haven't even said a word in many meetings.

Excellent testers are scarce.

It is not easy to do the test well, good testers need a wide range of knowledge, good communication skills (not only to deal with developers and project managers, but also with other groups of people to communicate). Rich experience in testing, with great enthusiasm and patience for testing work. There is also a need for testers to have a wealth of business knowledge and to write code.

The person who writes the code well, certainly does not do the test, but does the development.

Most of the test managers have a background in development.

I found out that my superiors had been tested by the development transfer. They all have a few years of development experience, and then do not know what reason to become a test manager. They can both develop and test, and will provide technical support to their testers.

If a Test manager what technology do not understand, the internal hold his men, the other group of people do not bird you.

Software testing is really boring, it takes a lot of effort

It is undeniable that the test work requires a lot of energy, so the United States and Europe will be a large number of test jobs outsourced to China, over and over again repeated testing, constantly execute test cases, measured weeping, hair halo.

I remember that I previously tested the various versions of a program in Windows Update upgrade, first install the old version of the program, and then Windows Update restarts to see if there is an upgrade, and finally uninstall. And then install, and then uninstall. The last Test almost spit blood.

English is the lifeline of testers.

It's not technically as developed. Must occupy some advantages in English.

The same level of technical skills, English good testers can enter foreign companies, than a bad English test personnel treatment is much higher.

Use less UI Automation testing, more unit testing, and interface testing

The automated test that can find bugs is useful, otherwise it's a gimmick.

UI Automation tests are less stable and difficult to analyze for test results. And the UI changes are large. So you should do as much as possible to do some of the underlying automation tests, such as ASP. NET MVC in the UI and logic separate, for the logic of automated testing is better done.

Software Testing (ii) six years of software testing sentiment