Table of contents
Double check your documentation
Responsibility determines value
Foreword:
Test planning is an important step in the software testing process that involves comprehensive testing of a software product to ensure it meets customer requirements and expected quality standards
Ask me what test? What tools do you use? My answer is: mainly functional testing, and some auxiliary tools, such as fiddler, will be used. They were all disappointed.
Here I can briefly describe my current work situation. Although the testers in our company sit together, each of us will work with different projects for a long time. When I first started working, I used soy sauce for three months (go wherever I need it). Later, an elder sister asked for maternity leave, and I took over the work of the network disk, and then I was too busy, so I recruited a new buddy to follow me to make the network disk. Work content:
Participate in requirements review --> write test plan --> write test cases --> use case review (call product, development) --> conduct rounds of testing after the project goes online (every round of testing, send out a round of test conclusions by email) --> After a few rounds, there is no problem. The project will go to grayscale (equivalent to internal testing) --> After the grayscale test, it will go to the whole network --> Issue a test report.
All right! Let me talk about the points of attention in this process:
communicate
Those who work in IT are generally typical boring men (I am also one of them). On the Internet are all literary and angry youth. I know what the status is in the real working environment. I knew a buddy who was engaged in development before. There is nothing to say about the technology, and there is nothing to say about the spirit of research. I went to ask him a question, but he was nervous talking to me, which made me worry about him. In the work, it is necessary to communicate with superiors, develop communication, and product communication. This aspect really needs to be strengthened. In the requirements review, express your own views on the needs and products. In the use case review, it is a test-oriented meeting, so it is necessary to have clear thinking and review use cases in an orderly manner. In the process of testing, developing or confirming problems in products, and assisting in developing and locating problems, communication is required. Two words, calm and humble.
use case design
A good test case is to cover more function points with the most appropriate use case. Some people write use cases with very fine granularity, and hundreds of use cases can be written with a few simple functions. The more detailed the writing, the slightly changed the requirements. Your use case is directly void. It is written too thickly, and many function points cannot be covered. My point is to think comprehensively and use cases flexibly. It is difficult to think comprehensively, and no matter how experienced people are, it is inevitable that they will be careless. This can only be accumulated in the lessons of blood and tears. Spend more time researching the business and needs under test. Looking at the use cases written by others will also gain a lot from it.
The use case should be flexible. For example, I generally expect that the result will be vague expected results such as "give corresponding prompts" and "match the input content". As for the specific design of the development, it is his business. As long as it is reasonable, unambiguous, and easy for users to understand the design. I think both are correct. Of course, this might cause a little trouble for someone reading the use case. Also, if there are clear requirements in the product requirements, they must be clearly written.
Double check your documentation
The most cumbersome thing for testers is to write a lot of documents after a project, such as test plan documents, test case documents, test paper reports, test report documents, acceptance plan documents, etc. I believe you have fully possessed this point in your long-term work As far as ability is concerned, what I want to say is carefulness. We are used to copying a modification on the previous document. This can save a lot of time, but it is also error-prone. That's what I did, or the date, or the data forgot to modify. All right! As a tester, this greatly discounts one's own performance. Don't underestimate this. It is best to check the written document twice.
Accumulate your skills
The "little white" who always behaves in front of development, if I develop, I will despise you too! According to my current work, I need to be familiar with the structure of the system, the language of development, and the database. In addition to testing the interface test function, I can check the database to see if the data has been successfully stored, or modify the database data to see the previous effect. For example, I want to test the prompt message for uploading files after the network disk space is full. Through the function, how many large files do you need to upload before the space is full? Just change the size of the files in the database directly.
When operating on the foreground interface, check the server log to see if there is any error message. Sometimes the server log can also be used to locate or determine the cause of the problem.
Multi-use page analysis or packet capture tools, for example, if the button click is invalid, then use the debug tool to view the properties of the button on the page. Use a packet capture tool to look at the request and response. In short, try to dissect the system under test during the test.
after discovering the problem
The most exciting moment for a tester is when a bug is found. When you find a bug, don't rush to report it to the bug management system or tell the developers. First determine the steps to reproduce. Try another system, another browser and try again. Perhaps, you forgot to clear the browser cache and the problem persists. Well, it's best to try to locate and resolve the source of this bug.
The second point I want to say is that if you find an ambiguous problem, you should try to look at the problem from multiple angles, and consider the impact of the problem from the perspective of the user. Look at the severity and repair cost of this problem from a development perspective. Explain to developers how this problem affects users. In this way, a harmonious relationship can be developed and established.
what the test should learn
This is the second type of question that is often asked. I am not valued, and I rarely arrange work. What should I learn? For this question, I divide the knowledge system of testers into two parts, one is testing knowledge, and the other is the entire software knowledge.
Let’s talk about testing knowledge and basic testing first. Many testers have never read any software testing books (including myself, I have read a few recently). Because there are not many software testing majors in universities, and training schools pay more attention to practice. I won't tell you too much theoretical stuff (personal guess). Most of the test testers are not from a professional background. The test threshold is really not high, and you can do the test directly after you get familiar with it. There is no energy and need to spend too much time learning the basic theory. All right! This is also the reason for the disappointment and disdain shown by most people when I asked me to do a functional test. All right! I still think you should read a few testing books "[Software Testing] Ron Patton", "Full Software Testing", "Software Testing paulC. 2nd Edition", when there are "Microsoft's Way of Software Testing" and the most classic "The Art of Software Testing", if you don't know what books are available about software testing, why not go to Dangdang.com and china-pub to enter How about a few keywords for "software testing"?
Of course, if you are not interested in these and want to learn some more practical and powerful-looking technologies, you can search for books on performance testing, automated testing, unit testing, exploratory testing, agile testing, etc. However, I still recommend laying a good foundation for testing! No matter how many tricks, no matter how advanced the technology is for testing, you don't understand what the essence of testing is? That is the blind pursuit.
Another thing to learn is software knowledge. Testing is for software. Software engineering, programming language, architecture, network, all knowledge related to development, you have to learn. There are many things to learn here. Breadth is required. When we are reviewing requirements, sometimes developers will talk about technical implementation, function logic, internal processing mechanism, architecture level, etc. If you don’t understand all of them, it’s too "outside". Of course, these knowledge have a subtle effect Your testing behavior, the depth of understanding of the system under test, and the depth of finding problems. I have used "scratch itching" many times to say that I don't understand the development of the test, how it feels, you can experience it yourself!
Of course, everyone has their own knowledge structure and their own learning route. Don't hesitate which technology is easy to learn, which technology has a future, and which technology has high wages. Compare it! Look at the various technical communities complaining to each other. It can only be endless complaints. Whether you learn or not, the technology is there, and your technical level will not increase or decrease. Of course, you can't study hard all the time. After studying for a while, you should stop to summarize and think. What route am I going to take? What capabilities are missing from the route I'm taking? What else do I need to improve. Of course, you should also pay attention to future technology trends.
Responsibility determines value
I recently read the article "Software Testing, It's Not Easy to Say I Love You", and I felt deeply. The author talks about software testing with the experience of a tester who has worked for seven years.
One of the examples is quite profound, explaining the truth in one sentence. If you are a hard-working and struggling tester, you still don't understand why testing is lower than development. The relationship between testing and development can't be more clear than using nurses and doctors as an analogy. The two most common jobs in a hospital are doctor and nurse. Even the best and most professional nurses cannot cure the patient's disease. Similarly, a good tester can't make software. There are many famous doctors, maybe you can call out a few casually, who can count the famous nurses in detail, except the founder Nightingale. I'm afraid I won't be able to call one. In fact, the relationship between testing and development is the same. Because the responsibilities are different, of course there are differences in severity.
There is both value, hospitals cannot do without nurses, and testing is needed in software development. All right! Please take a good look at your career. Maybe, you'll move on to more valuable developers, or architects. Or work that doesn't matter. I think most of them will continue to choose to move on on the road of testing. Then try to maximize your value. Lead a test team, or be a test lecturer, or publish a few books, become a test expert, and explore new technologies and models of testing. Now that you have chosen and love it, let’s move forward!
agile testing
Due to the recent project situation, the process has become more and more cumbersome. Under such a cumbersome process, the quality of the product is not well guaranteed, and most of the testers' time is spent on various documents. So, start learning about agile testing. I also want to find the answer I want from it.
Agile testing places higher demands on testers. Testing is no longer a link in the process, but is highly integrated into the entire process of the project. Perhaps this can maximize the value of testers, but you need to be competent enough to meet it.
Definition of Agile Tester
We define agile testers like this: Professional testers who adapt to change, collaborate well with technical and business people, and understand the idea of using tests to document requirements and drive development. Agile testers tend to have excellent technical skills, know how to collaborate with others to automate testing, and are also good at exploratory testing. They want to understand what customers are doing to better understand their software needs.
end:
Test planning is an essential part of the software testing process. By writing a detailed test plan, you can ensure that tests are used for the most valuable test scenarios while minimizing test cost and test risk.
(WEB automated testing, app automated testing, interface automated testing, continuous integration, automated test development, big factory interview questions, resume templates, etc.), I believe it can make you better progress!
Just leave [Automated Test]
http://qm.qq.com/cgi-bin/qm/qr?_wv=1027&k=1MDs4T0SvhL4arRoq3njIVb9HGXrRoj6&authKey=sx1h5dj77OV5obrcx6nE7Dn3sqEVuE4XrGqzqneReBJ y3ojOL3oHMSH48XPKPWhW&noverify=0&group_code=574737577