Recently, I have sorted out the testing software test network and put all my articles together.
This is an article I wrote in November 2020. According to statistics later, the total number of views on different platforms exceeded 10,000 in a short period of time, which can be regarded as the peak of my single article views in recent years. The reason why I feel that I have such a page view is nothing more than a slightly controversial title, and it is also catching up with the overwhelming "test left shift" at that time.
I am afraid that some people will have value judgments after reading the title, so I will make a point of view at the beginning of the article: I am not opposed to "shifting testing to the left" in the true original sense. "Test left shift" is directly distorted into the fallacy of "test engineer left shift", thus "selling anxiety" people ! For details, see the article below.
When I have time later, I will summarize the valuable comments on this article!
Bomb test shift left , lead test software test network, 33 minutes
Why is there such a topic? For a long time, in the field of software testing, there has been a pessimistic atmosphere ! For example, testing is useless, do we need full-time QA, artificial intelligence will replace test engineers, test engineers have no way to create benefits for enterprises, and so on.
Because some people or organizations intentionally or unintentionally create some anxiety , software testing practitioners, especially new software testing engineers, are full of doubts about the meaning of software testing itself, as well as the development and technical path of software testing career! Here, as a software testing engineer who has been in the industry for more than 20 years, he is an expert-level certificate holder certified by ISTQB International Software Testing Engineer. I want to talk about my own knowledge and views, hoping to give software testing practitioners some software testing concepts and views that I think are correct.
For the first shot, let's start with "test shift left" and talk about my views on "test shift left".
What is the so-called "shift left of testing"?
Through Baidu's search, the earliest description of "test left shift" found in China began from the end of 2016 to the beginning of 2017. In other words, "shifting tests left" is a new concept.
When I first talked about the concept of "shifting testing to the left", it meant that testing activities in the software development process should be involved as early as possible.
Figure 1 Test left shift
The diagram above depicts the rationale for testing shift left. That is, most of the defects in the software development life cycle are introduced during the coding process, but these defects are usually discovered gradually after coding. If the cost of finding and fixing bugs during coding is 1X, the cost of finding and fixing bugs increases to 640X after release to users. This also leads to the fact that if we do the testing work earlier, that is, "shift the test to the left", the cost of finding or fixing defects will be significantly reduced. This is the theoretical basis of "shifting the test left".
If you are careful enough, there is another problem with this picture circulated on the Internet, that is, it defaults that the injection of defects starts from coding, but in the real situation, as long as someone starts to participate in the research and development work (such as requirements analysis, design, etc.), it is bound to Will start to inject defects, we will not repeat them here.
It should be noted that the concept of "shifting testing to the left" that was first mentioned means that the testing work should be done in advance, rather than specifically referring to the "shifting to the left" of test engineers, that is, full-time test engineers intervene from the coding stage. There is a difference between the two ! The difference will be explained later.
"Test shift left" has not been proposed for a long time, but is this a new concept?
The most famous model in software engineering is without a doubt the waterfall model:
The familiar software engineering waterfall model (waterfall model) concept originated from the famous article "Managing the Development of Large Software Systems" published by Winston Royce in 1970 (Proc. Westcon, IEEE CS Press, 1970, pp.328-339) .
Figure 2: Waterfall Model
In my opinion, the so-called "shifting testing to the left" is just making up for the shortcomings of the waterfall model, that is, don't let the testing work become the last and only quality assurance method before delivery, it should be based on the premise that it needs to run through the entire software development life cycle.
But please note that the waterfall model was proposed in 1970, and it has been more than 50 years ago . How could such a big question be answered only a few years ago?
The classic V model has already finished this matter!
The V model was first proposed by Paul Rook in 1980 and appeared in a publication of the National Computing Center in the UK in 1990. It is an improvement on the waterfall model.
Figure 3: V model
I don't want to explain the V model here, and if you are interested, you can check it yourself on the Internet.
What I want to say is that testing starts from requirements and runs through the entire software development cycle. It was proposed 40 years ago. This is not a new concept at all. If you only recently learned that it is your problem!
Then why did you change the term recently and put forward the "test left shift"?
The term "shift-left testing" first appeared in Arthur Hicken's blog, where he mentioned his views on testing left.
Figure 3: The earliest talk of "shifting testing left"
The original text can be accessed at this address:
https://www.stickyminds.com/article/shift-left-approach-software-testing
However, this article was published in 2018, which is later than the time when domestic discussions began. It is possible that this address is not the initial address, but it does not affect our discussion.
In a literal sense, "shifting testing to the left" emphasizes that development engineers should verify the correctness of their own code as early as possible in the software development lifecycle. Note that developers test their own code .
In the context of agile and continuous delivery, there is nothing wrong with this statement. Any engineering software development model emphasizes early verification and confirmation (this is the famous V&V model), which can be traced back to the V model 40 years ago. .
Then why did you start to emphasize "shifting the test to the left" again? It's very simple, I haven't done it all the time! Didn't do that? For example: unit testing, continuous integration, single function point verification, etc. Pay attention to the above tests, the most suitable person to execute is the development engineer himself .
Why hasn't it been done as requested? In addition to being afraid of trouble and having low requirements for delivery quality, what other reasons can you let test engineers do it for you in the future? This is also the core reason why developers have been promoting self-testing, being responsible for their own code quality, and practicing TDD in agile activities!
To sum up, the original intention of "shifting testing to the left" was to emphasize once again that development engineers should do their own unit testing and be responsible for their own code. This is a common topic. The emergence of new terms is just to make development engineers pay attention again!
What exactly is the bombardment of "test left shift"?
Up to now, we have not found any problems with the term "shift left of testing", although "shift left of testing" is essentially just reinventing a term, changing the soup without changing the medicine.
But in fact it is not that simple.
The phrase "shift left of testing" is catchy. As time goes by, "shift left of test" is misinterpreted as "shift left of test engineers", that is, all test engineers should become test development engineers , and excellent development skills are required. , Participate in unit testing, integration testing, or directly replace development engineers to test code logic and interfaces, and test code by writing code.
What's more, they even advocated that in the future, test engineers who don't know how to code will no longer be needed, and test engineers who don't know how to code will all be unemployed, there will be no future, and manual testing will eventually be replaced by code testing code. The media advertisements are filled with the propaganda of test development engineers and full-stack test engineers. This atmosphere makes manual test engineers feel inferior and gradually marginalized. It seems that software testing work does not talk about code and automation overnight, which is politically incorrect. , is the role abandoned by the industry.
I can always see such remarks in my WeChat public account: the background of the test software test network, and the QQ group where I chat with the lead test Lao He. The above formulations continue to spread in the circle of software test engineers . It is to create anxiety, distrust of one's own skills, doubts about work based on functional testing and manual testing! In the face of developers who are not tough enough, they always feel inferior, thus entering a vicious circle!
In order to illustrate this problem, I try to analyze it from the following aspects
1. There is a huge difference in the work goals of development engineers and test engineers
The working goal of the development engineer is to realize the function, the goal is relatively clear, and the criterion for judging success is also clear, that is, the target function is realized correctly.
However, the work goal of a test engineer is to efficiently find software defects, which requires risk thinking and probabilistic thinking . The criteria for judging the success of a test are not clear, and the evaluation after release is the ultimate judgment. Pay attention to the two dimensions of evaluating testing work here, one is efficient and the other is defect.
2. For the same thing, consider who is more cost-effective from the perspective of the organization
There is a cost to doing everything. The standard thinking model should be the greater of two benefits and the lesser of two evils. Who has the lowest cost for unit testing of code logic? Most effective? Of course it is the deity who writes the code! Enterprises must use the most efficient solution to achieve their goals .
3. Single function point verification is not software testing in the eyes of test engineers
If you look closely, you'll find that most engineers with a development background talk about software testing as basically single function point verification, and they insist that's what testing is all about . As a test engineer with 20 years of experience in software testing, I can tell you responsibly that passing single-function point verification is only the entry condition for systematic software testing, and it is by no means the whole of testing, or in a strict sense, it is Not software testing . Professional software testing studies the combination of functions. Finding the optimal solution in the current scenario among the endless function combinations is the goal you should pursue . What is the optimal solution? It is how to meet the established quality goals most efficiently while balancing the interests of all parties !
Ideally, the software we get should be a product that has passed the verification of a single function point. In other words, single function point verification should be the responsibility of the development engineer ! Only in this way can professional test engineers exert their greatest effectiveness.
If your company only does single-function point verification, or most of the work is single-function point verification, I can tell you clearly that what you do is not professional testing. The product you tested must be of poor quality! You need to systematically learn how to do software testing. You can find out about ISTQB International Software Testing Engineer Certification Training from Lingtest International (please allow me to do hard work).
To sum up, the development test and the test test are basically two concepts. The unit test should be completed by the development engineer. The verification of a single function point cannot be the whole test. Professional test engineers must have risk thinking and do Risk-based test coverage .
Let functional test engineers collectively transform to do unit testing, and it is called "test left shift": "either stupid or bad"!
Don't test engineers need to understand code?
Software testing is an industry with several types of work. With different positions, the skill requirements for mastering code are completely different. For example: they are also chefs, but pastry and western food chefs have far weaker requirements for knife skills than Chinese food chefs.
Of course, when you have mastered the code, it will definitely add positive points to the effect of the test, but I want to remind you that your value comes from the complementary skills between you and the team, not from the skills of you and the team Same point.
In other words, does your team need a professional test engineer to do risk-based test assessment, or do you need a test engineer who understands development to test code with code, so as to improve the efficiency of single-function point verification? This is something you or your team needs to think about!
In terms of the current domestic atmosphere, it is not too little, but too much, to say that test engineers need to master the code. It is not too much to discuss how to build a test system, so that test engineers can master professional risk-based and coverage-based test thinking, but too little .
There is nothing wrong with test engineers mastering the code itself. On the contrary, there are great benefits, which will greatly enrich your testing methods and improve testing efficiency. But please note that compared with the construction of the entire testing system, this is only at the "technical" level. As a test manager, you must be soberly aware of what problems software testing itself solves. Efficiency is the icing on the cake. Scientific coverage strategy That's the root! Efficiency without coverage guarantees brings only doubt and confusion !
Can automated testing of code-based testing replace professional functional composition testing?
Unfortunately, at least not yet.
The current automated testing technology is to extract the use cases that are suitable for repeated execution or data-driven from the manual test cases, and automate them. Based on this principle, automated testing is usually the minimum set of use cases for manual testing, and is used as the lowest quality firewall .
For cost considerations, in many scenarios, the cost of manual testing will be far less than the cost of automation. So there is no reason to automate all manual testing.
Furthermore, for example, the exploratory testing technology with super ability to find bugs does not need to plan the test path in advance. In principle, it is impossible for automated testing to replace exploratory testing.
MBT's model-based testing technology, at least for now, is not possible to do full traversal coverage after modeling, which will cause an explosion of use cases.
AI-based self-learning tests have not yet seen a practical solution. It is still in the stage of exploration and research, and I am cautiously optimistic about it.
Having said so much, I just want to explain that relying on code to test code, the problems that test development engineers can solve are limited, and it is impossible to completely replace manual test engineers .
If your enterprise really does this, I would like to ask you to think about it, is the quality of your enterprise software products currently high? Is there a lower requirement for release quality? In the later stage, it mainly relies on user discovery? If so, this is a special case, not a common situation, and mainly for Internet applications, customers are not sensitive to the release quality.
Why "shifting testing to the left" is a pseudo-concept
First of all, as mentioned earlier, "shifting the test to the left" is not a new concept, but just a renaming of the original theory decades ago!
Second, "testing left" is very different from "testing engineers left" .
The third point, instead of continuing to emphasize the misunderstanding caused by "shifting testing to the left", why not emphasize "shifting development to the right". Let development engineers realize that unit testing and single-function point testing are part of the development work. You cannot and should not let test engineers do it for you . Because only in this way, the test engineer can concentrate on the real test work. When the development complains that the test technology content is low and the test effect is not good, the crux of the problem is that the test engineer did not focus on the real test work!
The fourth point, specifically, should "shift the test to the left" or "shift the test to the right". I think the difference is nothing more than "unit test" and "single function point test". Who will test? It is also possible that many companies have not risen to this height, because it is impossible to predict at all! My point of view is: Of course, testing is better than not testing, but if it is a single function point test performed by a test engineer, I would like you to realize that this is not the testing work, or that this is not the whole of the testing work . If your company wants to improve software quality, please have a system and step by step to transfer this work to the R&D department. That is to start emphasizing "development shift right"!
Fifth point, please don't talk to me about agile, it makes no difference in this matter. Developers have to do their own testing, please "shift development right".
Sixth, does the so-called "test left shift" of test engineers improve or reduce quality?
It seems to improve in the short term (because someone did something that no one did before), but it declines steadily in the long term (because the development engineer, the first person responsible for quality, gave up this part of the work).
Whose responsibility is whose responsibility! Can assist, teach, but never replace! (The so-called teaching is the job of the test coach in Agile).
The software testing throughout the whole life cycle does not mean that the software testing work of the whole life cycle is completed by full-time test engineers, and different roles should complete the testing work in their own sense.
Test engineers, please be fully aware that software test engineers serve quality, not software development engineers. Any specific test work is a means. Your goal is to establish a quality assurance or test that integrates all roles. system. Only when all roles are divided and cooperated, can we jointly and effectively guarantee the quality .
Wake up: software testing and software development deal with different problems, don't feel sorry for yourself ! Is it because the test is not done well, the level is too low, or your understanding of the test is not right at all?
Armed with correct testing concepts, tough test engineers are valuable to enterprises!
Abandoning energy efficiency and talking about quality are hooligans
We have previously analyzed the reasons why a large number of development engineers should ensure the quality of their own code. Some people may ask, you said that developers test their own code to ensure the correctness of a single function point, let's say you are correct. But "shifting testing to the left" refers to early testing. This early testing does not only refer to unit testing and integration testing, but also includes testing of requirements! "Test shift left" generally means that professional test engineers should start to intervene from the requirements stage. Is there any problem with this? If there is no problem, how can it be said that "shifting testing to the left" or "shifting test engineers to the left" is a pseudo-concept?
That's a good question, so I'll save this topic for the end. Let me talk about my conclusion first. Full-time test engineers start to intervene from requirements, which can be considered a good practice for test engineers to move left, but is it not a best practice that is generally applicable to all enterprises? I don't think so!
In order to clarify this topic, we will explain the following points:
First of all, we have to distinguish between testing work and the work of full-time test engineers. Testing work broadly refers to verification and confirmation work, which may be completed by full-time test engineers or by more appropriate roles in the team . Who will complete the task needs to be comprehensively considered by the organization: skills adaptability, communication costs, career development, optimal efficiency, lowest cost and other restrictive factors.
Let's discuss whether it is a good practice for "test engineers to intervene from the requirements stage".
If the test engineer intervenes from the requirements stage, are there any special requirements for the skills of the test engineer? The answer is yes, of course there is!
First, the test engineer involved in the requirements phase must be very familiar with the business, at least a business expert, and his understanding of the business should not be weaker than that of the demand analyst, otherwise there is no way to conduct peer-to-peer communication.
Second, test engineers who intervene in the requirements phase must have a clear understanding of the writing skills and language logic of requirements documents, so that they can participate in the acquisition and review of requirements.
Thirdly, test engineers who intervene in the requirements stage must have strong communication skills. Much of the work at this stage starts from communication.
Fourth, the test engineer involved in the requirements phase must have strong test analysis and design capabilities, because this is his job at this time.
To sum up, the test engineer involved in the requirements phase is the core of the core of the entire test team !
What is the specific output of the test engineer involved in the requirements stage at this stage?
If you intervene before the requirements review, to be honest, there is no hard output , and it is more about understanding the system requirements in advance. Propose the planning of the main points and organizational methods of the follow-up testing work. Since the requirements document has not been fully finalized, all current work may be overturned.
If you intervene during the requirements review or after the requirements review is passed, you are more likely to participate in the requirements review work as a requirements reviewer, integrate requirements and other documents, etc., and conduct test analysis and design. There are clear outputs here . But please note that if testers participate in the requirements review, you are first of all a business expert who can contribute a little to the requirements review, and secondly you are a test engineer who thinks about requirements from the perspective of system testability. Don't do it the other way around! The first person in charge of demand work is the demand analyst, remember !
To sum up, if you are the person in charge of quality, how should you choose? Is it more reasonable for test engineers to intervene from the stages before, during, and after the requirements review?
There is no unique or best practice here. You have to consider cost, environment, technology, risk, input-output ratio and other constraints comprehensively.
My suggestion is: intervene after the earliest review is completed, or postpone the intervention until the system test starts, mainly from the perspective of input-output ratio. Of course, each organization has different expectations for quality, and it needs to be considered comprehensively according to its own actual quality goals .
As far as this topic is concerned, we don't talk about anything beyond what the V-model covered decades ago, and I'm not convinced that this is the most "advanced" idea of "shifting testing left"!
To sum up: to give up cost and talk about quality is to play hooligans! A reasonable teamwork model can improve the overall efficiency of the organization, and the improvement of both process quality and product quality should be the goal to pursue!
Say no to "selling anxiety" in software testing circles!
The field of software testing is a professional field. As practitioners in this industry, we should systematize our testing system and arm ourselves with correct testing concepts .
What we have built is a quality assessment system based on risk and probability thinking, and the technical means serve the test objectives.
Professional software testing cannot talk about testing technology without the coverage of the whole.
Finally: The complete software testing video tutorial below has been sorted out and uploaded, and friends who need it can get it by themselves [Guaranteed 100% free]
Software Testing Interview Documentation
We must study to find a high-paying job. The following interview questions are the latest interview materials from first-tier Internet companies such as Ali, Tencent, and Byte, and some Byte bosses have given authoritative answers. Finish this set The interview materials believe that everyone can find a satisfactory job.
