One day after the New Year, I received a message from my colleague saying that the uplike test team was preparing to publish something and asked me to write a preface.

At that time, I was very surprised. I had never heard of the test team doing this before. Part of my surprise came from the fact that I had never written a preface before. While the Youzan tech blog posted more than 100 dry articles in 2019, the Youzan tech team has never published a full-length feature before.

I read the ebook carefully and it’s very complete. I was expecting some practice sharing, but in fact there are a lot of the latest theories in the industry and some great practices based on that theory. After reading four or five chapters in one go, I was quite shocked. The awesome work was not easy, especially in 2019, when the team was under great business pressure. The system was expanded round after round, and dozens of rounds of online real environment pressure tests were all carried out at midnight. In this context, the test team still has such high quality content output, it is not easy, have to let people sigh over the years the test team has grown very fast.

Today’s Youzan test team, 99.999% of students rely on their own efforts, as a member of the team has done 0.001% of things in the past, I am quite proud.

There were no early tests for this job

Youzan is a relatively late test team, the first line of code was written in November 2012, and the test team did not start to build until the second half of 2014, by that time, youzan technical team had more than 50 people, only front-end and back-end two work.

Today, many people may wonder why such a large technical team did not test at that time. According to the industry convention, about 5~8 engineers would assign a test. According to the truth, at that time there should be praise technical team of more than 5 tests.

Youzan is a company that strives for perfection in many aspects, including testing this position. In fact, until now, we will tell a truth in the compulsory course for technical freshmen: “bugs are written, not tested.” Therefore, the first person responsible for coding is the coding person, not testing. Of course, testing is responsible for detecting bugs. We often promote the phrase “wipe your own ass” internally.

Because of this philosophy, when we first set up a good test team, we asked the recruitment committee to write code tests. At that time, functional testing was the dominant industry. It was not easy to make such a choice at that time. There were few tests that could write code in the market at that time, especially in a city like Hangzhou. Of course, the price was also expensive, we were still in the early stage of business, there was no income.

Likes are only for tests that can write code

In fact, the business was not very complicated at that time. From the perspective of purely meeting business needs (with no major problems online as the goal), we could choose to recruit a small number of testers who understand code (called test development engineers today), and more functional testers who are oriented to the business layer. The reason why I did not choose this option is that I think that in the next five to ten years, the professional space for pure functional testing will be very small. Recruiting a large number of such people and replacing them in the future will not be responsible for these people and will not help improve efficiency. I’ve always felt that a good engineer is 10 times more efficient and more scalable than an average engineer.

Facts also proved my idea at that time: it took about one to one and a half years for the youzan test team to be established, and gradually it was recognized by the Technical circle in Hangzhou. Test students began to go out and share great test practices and thoughts with their peers.

The testing team has also gradually become a very powerful force within UzAN Technology, which is mainly reflected in the following aspects:

First, echelon is most complete within a year or so of its establishment.

Second, because of the natural advantages of the profession, the test needs to follow many projects and test many businesses, so I am very familiar with the business and scenes. From the test team, I have grown up many technical leaders of partial business, or even those in charge of pure business.

Third, because we insist on recruiting only test engineers who can write code, we also let many things that were originally undertaken by multiple roles converge to one role, such as basic security (attack and defense, penetration, etc.), early development efficiency system construction (CI, CD, etc.), stability guarantee (full-link pressure measurement, performance analysis), etc. Just because of the filling and role convergence, we saved a lot of time, energy and money before role specialization, and the test team took the initiative to undertake more things because of their excellent ability.

Pursue long-term value

There are many, many examples of this kind of choice and thinking in the history of awesome, not just the test team. For example, at the very beginning, we chose people, arranged the training of new recruits, established the operation and maintenance system, and implemented the universal service. There are so many, so many, that the whole development process of the test team is a microcosm of those things.

If we focus on the present and solve the current problems, many things are not worth it. If we look at the cycle of 5 years or even longer, two or three years later, we will find that the past “investment” slowly begins to produce “profit”.

Good test team today can have such output, can have some influence in the industry, it is the past “investment” and accumulation. Almost 100% of this test release is from great real world practice, with lots of details on how to do it, including team building.

Some people might suspect advertising, but there are 10,000 ways to do advertising, each of which is easier than writing a book, and to do it for advertising is downright stupid. In my opinion, the real useful thing is the original restoration. The world is never short of theories, but the practice behind theories.

Comrade Xiaoping said: “Practice is the only way to test truth”. But I think practice may not be able to test the truth. After all, truth is universal, and any practice is finite.

Therefore, in the end, I would like to remind all readers, please pay attention to the cause and effect, do not copy, praise is suitable, may not be suitable for every team, praise practice just provides a way of thinking and possibility, we should still according to their own business appropriate improvement and adaptation.

It has been a privilege of my life to work with a testing team that has done so much more than I have asked them to do. It is a proud team.

Thank you all for your support to the likes test team. We welcome all questions and suggestions on the content. We welcome any form of direct communication.

The e-book “Test Combat Frontier — 5 years of Experience in The Like Test” is now on the shelves, and you can subscribe by identifying the QR code on wechat