Shulou(Shulou.com)06/01 Report--

It will be 10 years since I started testing and developing. I have been in startups and big companies. Along the way, I have learned, changed and experienced in the workplace. I have long wanted to write about it and share it. This process includes the improvement of technology, the literacy of engineers and a little bit of insight into the industry.

Automated test vs test development

I remember that when I first joined the profession, my title was an automated test engineer. At that time, the difference between the two was not so obvious, and the questions in the interview were similar. At that time, the recruitment of "testers who can write code" preferred to be called "automated test engineers", but now many companies have become "test development engineers".

According to the concept, in fact, automated test engineers prefer to improve the efficiency of the business direction, while test development is more inclined to improve the efficiency of the infrastructure direction. To put it simply, the framework produced by the test development engineer can be thought of as the parent class, and the automated test engineer can be understood to inherit different subclasses from the parent class according to the line of business.

What exactly is test development doing?

Test development originated from the book "Google Software testing", in which SET (Software Engineer in Test) was first proposed. However, different company titles are not the same, such as the domestic most of the time is still collectively referred to as QA.

So what exactly is SET doing? In my opinion, SET favors the infrastructure development and process setting of the testing department, such as automating the building of the underlying framework mentioned earlier, or rewriting some open source classes and methods to provide to other testers in the group; for example, the well-known CICD, unit test or integration test coverage statistics, and automated deployment and release scripts can all be included in the scope of testing. In addition, we often say that testing also requires the introduction of new technologies, and now the common Docker and K8s are also gradually spreading to the testing team, because one of the biggest obstacles to testing is "many test environments", and containerization can solve this problem very well.

Of course, the situation varies from company to company. Generally speaking, the larger the enterprise, the more standardized its testing process, the more obvious the role of testing, and the higher the testing efficiency of the corresponding products.

The ultimate task of quality assurance

I believe that many test engineers actually have enough resonance, that is, "We are not testing bug, we are the quality assurance staff of the product." But many immature enterprises and teams still have misunderstandings. For example, the number of bug does represent the output of your work, but if your team or leader uses the number of bug as the only indicator, I think it's time for you to consider job-hopping. In my opinion, quality assurance, which covers a lot of things, is a huge concept, which can probably include four points:

1. The correct process

Now many of them are agile development models. In the requirements review stage, the testers participate and have some understanding of the requirements or products and preliminary test plans.

two。 Quality of the foundation

The standardization of the development code, the inspection of the basic code, and the steady improvement of single test coverage. After all, the foundation determines the upper layer.

3. Coverage of business

It can be divided into service interface tests / front-end UI tests / performance tests / stability tests / system integration tests / regression tests, which can be said to cross the most students.

4. Guarantee of product terminal

Collaborate to develop grayscale release strategies / standardize online operations / understand common risk points in the process of user use / develop stop-loss strategies

To put it simply, testing ensures quality, which determines the product. Testing should be the role that best understands the requirements and the logic of the product. Therefore, as long as the product changes, test students should subconsciously follow up.

And any of the above points, can be studied in depth, to do better.

Engineer culture

I believe that no matter how good the test development is, you should start with the business. If you don't understand the business, you don't know some development code, or if you don't know some development code, some things are bullshit. In my opinion, business testing is not low at all, but it is a very testing thing. Whether we are test engineers or test developers, we are all engineers and serve the products. Since you are an engineer, you should have the literacy of an engineer. I think to accomplish a good test task, you probably need to do the following at the same time:

1. Be responsible for the test results

We are the last hurdle of the product, we have the absolute say on whether the product is released or not, at the same time, we are also responsible for our own test results.

two。 Test to the final scenario

Now many product links are very long, which requires test students to take the initiative to shape their own products of overall vision, not limited to a unit of testing, regardless of the overall situation, sometimes resulting in fatal online disasters.

3. Sensitive to logs and able to accurately locate problems

If the development process is standardized enough, there is a complete log system, in fact, it is not difficult to locate the problem; every time we find a bug, we can try to trace its root. Over time, you will have a clear understanding of the engineering code or logic, which will add to your next testing work.

4. Induction of similar problems and loopholes

Whether it's the problems of front customers, the problems found by PM or your own bug library, frequent summarization can save a lot of time and give you an "intuition" about your work, but this intuition is sometimes very accurate.

What should we do with different products?

The development technology or framework may be generic, but testing may produce "unique" adjustments with the product shape, which I call the "test form". For example, in today's artificial intelligence testing, because each model iteration requires a large amount of data, you may not be able to use traditional concurrency to request, then you may need to learn some distributed techniques. Then there is cloud service testing, most of which are pure back-end service testing, or SDK testing, without the front end to assert your expectations, then you need to be familiar with curl commands, network commands, etc., or even generate some shell scripts to execute your test requests; and mobile testing, for example, how to ensure its compatibility and stability is another discipline. Finally, there are relatively popular smart hardware, boxes, TV, ah, these, how to ensure its quality, is another way.

However, in the final analysis: the test thinking will not change, in order to respond to changes.

In short, testing is a big knowledge, and the barriers to entry are not high, but the deeper you go, the less you know. As a workplace personnel, do not change with the business change, have their own precipitation and technical foundation, can be more long-term. And the test development industry, I think the future will also be more important, it is a link between product / test / development, it quietly supports the whole testing system in an orderly way, to some extent, it is a hermit.

Welcome to join the 51 software testing family, where you will get [latest industry information], [free test tool installation package], [software testing technology], [job interview skills]. 51 learn and grow with you! QQ group: 755431660

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.