We have DevOps. Let's dismiss all testers
Is it possible to automate anything? Then all testers dismissed, of course. Why are they now needed, "manual" testing is left. Right?
This is a story about the future of testing in terms of DevOps. There will be concrete figures and purely practical conclusions, as it turns out that good specialists always have a job. (Or not work! Look at the photo of Shakespeare and be afraid, now your fate will be decided).
')
The material is based on the transcript of Baruch jbaruch Sadogursky’s report, Developer Advocate in JFrog. Text version and video of the report - under the cut.
Hello! See the quote from Shakespeare in the picture a little higher? This is "Henry VI", a proposal to kill all lawyers. You understand that since then we have more vegetarian ways to get rid of the wrong professions. We will not kill anyone, just take and dismiss everyone.
More precisely, there is such an opportunity. Will we dismiss someone - let's talk.
This is Vasya. One morning he comes to work and passes by the most important negotiation. And then his boss welcomes the new consultant. A performance consultant comes to the company and says: “We will do DevOps as in netflix *. We specifically flew to Silicon Valley for a conference, and there we were told how they are doing in netflix. ”
They put on Spinnaker, then they launch Chaos Monkey, and they automate everything. And we will do it and we will be very effective.
The chief asks, what about testers? “And in our netflix we have freedom and responsibility . Developers will write tests themselves. ”
And here Vasya becomes ill, because he looks at his business card, and there ...
Vasya begins to worry: the last time when a performance consultant came, his acquaintance, Natasha, who worked as a sysadmin, was fired. Because everywhere is DevOps. And then he realizes that soon everything will be very bad.
But, of course, Vasya wakes up here.
My name is Baruh Sadogursky, I’m a Developer Advocate at JFrog. The editor of this article specifically asked to write a couple of paragraphs so that no one doubted my authority to tell how we would dismiss the testers.
JFrog is a startup in Silicon Valley, our last estimate was over a billion dollars. We are officially unicorn , and we are automating DevOps. Our products — Artifactory , Xray , Mission Control, and so on — are tools for the very same automation that turns the Omsk Meat Factory into netflix.
I myself am not a tester, so maybe I will tell some nonsense. In the program of the conference at which this report was originally read, there is a special designation - a picture with an incendiary bottle. So, the speaker is going to carry some kind of heresy, and the audience will be burned. This is about me. I tweet @jbaruch . As you already understood, I am a very cheerful guy, I urgently need to follow me.
I have news for you: 80% of developers write tests. Developers are satisfied with all sorts of polls. Here we are the company JetBrains happy with a very good State of Developer Ecosystem Report . They ask who writes unit tests.
Total 70% of developers use unit tests. That's cool.
There is a more in-depth study of the company Hubstaff about testing with the help of developers, it is a little bit older - in 2014. According to him:
The vast majority of developers claim that they also test something with pens. They lie, of course, but the statistics are as follows.
Since 2011, our favorite quote is: “Every company is a software company” . Including, of course, the Omsk meat processing plant, where Vasya works. Everywhere there is software and everyone is trying to make money on this software. What do companies want? Row a loot with a shovel. Where does the money come from? From satisfied customers. What do clients want? New features. And when they want new features? Now!
CEO from comic book Dilbert - chief of chief Vasya. He also listened to all sorts of interesting reports. He believes that if customers want new features, then new features should be released more often. Is logical. To do this, reduce friction in teams.
Should I release more often? For example, in 2017, Java switched to more frequent releases, because everyone wants features and, it would seem, it is necessary to release quickly. Every six months there is a new Java. But no one uses it.
We recently had a Joker, we arranged Java Puzzlers on it. At the beginning, we always ask who is on which Java in order to understand which puzzlemakers to ask.
The picture has not changed: 80%, or even more, still sit on Java 8, which was published a hundred years ago. Neither the ninth, nor the tenth, nor the eleventh takes no one.
To understand why not use, you need to understand how we make a decision about whether to take any updates or not. Let's imagine how we put any updates - the operating system, applications, browser - what you want.
A notification comes that we have an update, let's install a new operating system. Do we want this? Is there something useful or we have a cash register that runs on Windows 98 Embedded, and we don’t need anything else?
If we want this update, the next question is how dangerous it is. It's one thing when Facebook is updated, and we will go scrolling, and we won't be able to add likes. It is quite another thing when the life support system turns off in the hospital. If we do not care about the risks, let's update. If there are risks, then the question is in trusting the one who rolls out the update.
With Apple had no problems: there is a new operating system - let's take. It was before, and now we are already afraid of updating, there is no former trust. If we trust - no problem, update. If we do not trust - you need to test.
We do what is called acceptance tests. Here we are informed: a new Java was released, and for example, we are a Baidu company. Highload, 100,500 servers, cloud, JVM everywhere. We take some of the servers, start changing Java. A bunch of engineers have to do something and check it all out. Once every three years it is normal, but once every six months ... Have you been fucked? We will only check it for six months. Of course, we will not take this new Java.
Therefore, if we can check quickly, it is worth upgrading. But if you have to check for a long time, then you can skip a couple of versions. Nothing happens if we crawl from the eighth version right to the twelfth.
The problem is trust. If we do not trust, it will be hard to update. If the issue of trust is resolved, then there are no problems with updates. Or we have a feature, or we do not care.
Take chrome. He, starting with some version, updates at all without asking anyone. The risks there are small, but still there. But on the other hand, we trust those who write Chrome. Most often, when a new release of Chrome comes out, nothing breaks there. In fact, we have no problems with trust, and we go down this path.
We have an update, the risks are not important, we trust - update. And we will not be asked whether we want it or not, so we will always update. That is how it is done.
Imagine, netflix is ​​rolling out a new update, and now we can skip not only the titles and screensaver, but all the boring places. Cool update? Steep. Do we want it? We want. Will it work? Probably yes. As a last resort, we will go to YouTube, cartoons will see if netflix has broken.
The issue of trust is critical here. How do we solve it? The term "we" refers to the two co-founders JFrog, Fred Simon, Yoav Landman and your humble servant. We have written a book that advises how to solve this problem.
Suppose we persuaded our CEO, he read Liquid Software, and now he understands why he needs an update. He asks the consultant how we will update more often. Agile! DevOps! What is DevOps?
Let me tell you a little bit of the theory of what DevOps is, since we earn money from it. Take a look at the picture, we had these groups, teams, departments:
There are developers, there are Ops - system administrators who take what the developers have written, and throw it on the prod. And midway between the Ops developers, there are QAs that test. That is, the developers sat down, wrote, then carried them to testers, tested them, carried them to sysadmins, and they poured them on to the prod. For this we had separate departments.
Russian is beautiful: a department is always separate , this is the root of the word. In English, this beauty is not there, so these different departments are called silos . The best translation of this word into Russian was brought by Anton Weiss, who was the best speaker of DevOops . He calls silos "wells." Different departments - deep wells. To download some work there, you need to go down, and then pull the work out - to get up. The most convenient way to do this is in groups. How do we group things that we get from the well?
Naturally, buckets. That is, we have such “buckets of work”. The developers wrote something in the well, we loaded it into buckets, took it out of the well, carried the buckets to the testers, and lowered them into the well.
A lot of actions are performed to transfer work between different wells. When we group tasks to save on this work, we begin to load these buckets. Of course, the larger the bucket, the more we will save on this transfer process. Therefore, buckets make great.
What is the problem with big buckets? The fact that they fill a long time. Therefore, when we have important features that need to be immediately released to production, because there is a queue of customers with money - we cannot do this. We have the same wells, let's better we collect more in a bucket. Therefore, important features are waiting for any nonsense, as long as we have enough to fill this well. This is bad, as you understand. This is solved by the fact that we get and mix all of these wells.
I am not guilty! I just took the three original colors, put them one on another, and this color turned out. Now we all do everything. We have such engineers who are both a Swedish, and a reaper, and a igrets on the dude. These are Dev, QA and Ops. He wrote the code and tested it, and then also put it all out on the production - such a unicorn.
What is the problem of unicorns? That they do not exist. And those that exist, they have long been hired by netflix. Therefore, it remains for us to make a mixture.
We have a common culture, common goals. We came out of the wells, we are all together now, but we still have deep specialization. A developer is still more a developer than Ops, and a tester is more a tester than a developer. But nevertheless, they understand everything. They understand what they do, why they do it and how it works.
That is, we have T-shaped people, "people in the shape of the letter T".
They have a deep specialization, they know very well what they are doing. They know well enough and everything else too. For example, developers understand a little bit how to test correctly, how the processes of laying out on the prod and so on work.
DevOps is:
Let's talk about the assumption that there is an inverse relationship between speed and quality. Roughly speaking, the sooner we release, the worse the quality will be. And vice versa: if we do not hurry, we will have time to test everything thoroughly. We have trade-off!
In order to understand whether this dependence really exists, let us turn to scientific works and talk about the State of DevOps report on the DORA organization. I highly recommend you to take a good look at this report.
How much can you trust him? The report says that in five years more than 30,000 people were interviewed, and in 2018 almost 2,000 people. This is a very large sample and on the basis of such an amount, for example, they make predictions for elections in the United States. Therefore, the study can be trusted.
In addition, Nicole Forsgren, who heads the DORA, unlike us, is a scientist, so everything is serious there. Let's see what DORA will tell us about this inverse correlation.
First, they divided all respondents into three groups: Low performers, Medium Performers and High Performers.
In addition, there is Elite. This is Netflix (actually not, see the disclaimer above).
As you can see, the proportions change. Naturally, five years ago there were a lot more Low Performers, now there are a lot more High Performers, because we are already starting to understand a little bit what we are doing.
This is somehow strange. It turns out that Medium is tested with pens more than Low. Why? Because Low doesn’t test anything at all.
They have a trend, a graph called the J-curve, which shows the same correlation or inverse correlation between speed and quality. And here everything is very strange. At some point we see confirmation of this inverse correlation. That is, the faster we release, the lower the quality.
But further correlation is not only not inverse, it is direct. The faster we release, the better our quality. Suppose we Medium and test pens. Everything is not bad, but slowly, because we believe that if we do not hurry, then we will test everything better. Then the consultant from DevOps comes and says: “Everything, now we are automating. And we do not need testers. All perfectly".
But without tests some nonsense turns out. After we realized that we still need to test something, and we need to automate correctly, we begin to automate correctly and continue to strive for transcendental heights.
This failure, where many bugs appear, needs to be overcome correctly. How to get into it, I think, there are no questions. The question is how to get out of it.
We need to answer the question of how to live without manual testing. The answer is the same as the question how to live without setting up servers. Obviously possible. What is changing?
Previously, we had a sysadmin who was rolling out a product for selling. He sat and waited for the developers to finish writing. After that, he took this product and went to the CD-ROM to insert and wire stick. What happens to everyone else at this time? All others are waiting. This bottle neck, plug.
We solve this with the right automation. We automate the process, we have a pipeline prepared in advance, and now the product rolls out automatically as soon as it is finished writing. Does it mean that now these people are not needed? Not. This means that they are needed, but are doing something else.
The same with testing. We have testers who test the product. They are waiting for them to write the product. They wrote - it's time to test. What are the others doing while they are testing? Do nothing, sit waiting. How do we solve this?
Again, the correct automation. We build the process. He will guarantee the quality of the product. We can prepare this process in advance, and then the product is tested automatically.
It remains to automate everything. In fact, we can automate testing. The problem is that you can automate a certain part.
You all know this joke about how a tester goes to a bar, orders beer, orders 0 beer, orders 99999999999 beer, orders a lizard, orders -1 beer and orders ... Here’s a bug, because it should be asdfgh, and not this bullshit.
It is easily automated. , . , . . — , , .
, , , , . . , , , — , , , . , , , , , . , , , .
, , , . DevOps. , . T- — , .
, - . « », , . , , , . , Selenium . , .
, .
— . , , . . , , Ops- , , , , , , , .
Developers in test — , , . , . , ; — , ; TDD , , , , . , , .
« ». , , , , , — . , , , , , , , , , , Continuous Testing .
end-to-end , . , , DevOps, .
, - , . , 70- : « DevOps, ». , , .
. -, , , , , . : ( EVP Engineering, SignalFx) , , .
70- . . , , . , . , , , , . , , , , — , netflix .
, , , , , , , , , . . , .
, . . « , », — , , .
«, — . — : , , , . , , , , , . . , - , . ? Artifactory , ?!».
, — , . , . ? !
DORA: , , , .
New Work. , New Work Low — 30%, Medium — 40%, High Elite — 50%. ( , Low) , , .
.
This is a story about the future of testing in terms of DevOps. There will be concrete figures and purely practical conclusions, as it turns out that good specialists always have a job. (Or not work! Look at the photo of Shakespeare and be afraid, now your fate will be decided).
')
The material is based on the transcript of Baruch jbaruch Sadogursky’s report, Developer Advocate in JFrog. Text version and video of the report - under the cut.
Hello! See the quote from Shakespeare in the picture a little higher? This is "Henry VI", a proposal to kill all lawyers. You understand that since then we have more vegetarian ways to get rid of the wrong professions. We will not kill anyone, just take and dismiss everyone.
More precisely, there is such an opportunity. Will we dismiss someone - let's talk.
This is Vasya. One morning he comes to work and passes by the most important negotiation. And then his boss welcomes the new consultant. A performance consultant comes to the company and says: “We will do DevOps as in netflix *. We specifically flew to Silicon Valley for a conference, and there we were told how they are doing in netflix. ”
* Disclaimer: Netflix is ​​often used in this article as an unattainable DevOps ideal. This usage is nominal.
A discussion of whether Netflix really is an ideal DevOps is beyond the scope of this article (most likely, by the way, no).
They put on Spinnaker, then they launch Chaos Monkey, and they automate everything. And we will do it and we will be very effective.
The chief asks, what about testers? “And in our netflix we have freedom and responsibility . Developers will write tests themselves. ”
And here Vasya becomes ill, because he looks at his business card, and there ...
Vasya begins to worry: the last time when a performance consultant came, his acquaintance, Natasha, who worked as a sysadmin, was fired. Because everywhere is DevOps. And then he realizes that soon everything will be very bad.
But, of course, Vasya wakes up here.
My name is Baruh Sadogursky, I’m a Developer Advocate at JFrog. The editor of this article specifically asked to write a couple of paragraphs so that no one doubted my authority to tell how we would dismiss the testers.
JFrog is a startup in Silicon Valley, our last estimate was over a billion dollars. We are officially unicorn , and we are automating DevOps. Our products — Artifactory , Xray , Mission Control, and so on — are tools for the very same automation that turns the Omsk Meat Factory into netflix.
I myself am not a tester, so maybe I will tell some nonsense. In the program of the conference at which this report was originally read, there is a special designation - a picture with an incendiary bottle. So, the speaker is going to carry some kind of heresy, and the audience will be burned. This is about me. I tweet @jbaruch . As you already understood, I am a very cheerful guy, I urgently need to follow me.
I have news for you: 80% of developers write tests. Developers are satisfied with all sorts of polls. Here we are the company JetBrains happy with a very good State of Developer Ecosystem Report . They ask who writes unit tests.
- 59% write themselves
- 11% see unit tests in their code and do not know where they come from.
Total 70% of developers use unit tests. That's cool.
There is a more in-depth study of the company Hubstaff about testing with the help of developers, it is a little bit older - in 2014. According to him:
- 85% of developers write unit tests,
- 15% no;
- 40% work according to the methodology of test-driven development;
- good coverage - between 34 and 66 for 31% of developers.
The vast majority of developers claim that they also test something with pens. They lie, of course, but the statistics are as follows.
Since 2011, our favorite quote is: “Every company is a software company” . Including, of course, the Omsk meat processing plant, where Vasya works. Everywhere there is software and everyone is trying to make money on this software. What do companies want? Row a loot with a shovel. Where does the money come from? From satisfied customers. What do clients want? New features. And when they want new features? Now!
CEO from comic book Dilbert - chief of chief Vasya. He also listened to all sorts of interesting reports. He believes that if customers want new features, then new features should be released more often. Is logical. To do this, reduce friction in teams.
Should I release more often? For example, in 2017, Java switched to more frequent releases, because everyone wants features and, it would seem, it is necessary to release quickly. Every six months there is a new Java. But no one uses it.
We recently had a Joker, we arranged Java Puzzlers on it. At the beginning, we always ask who is on which Java in order to understand which puzzlemakers to ask.
The picture has not changed: 80%, or even more, still sit on Java 8, which was published a hundred years ago. Neither the ninth, nor the tenth, nor the eleventh takes no one.
To understand why not use, you need to understand how we make a decision about whether to take any updates or not. Let's imagine how we put any updates - the operating system, applications, browser - what you want.
How do we put updates
A notification comes that we have an update, let's install a new operating system. Do we want this? Is there something useful or we have a cash register that runs on Windows 98 Embedded, and we don’t need anything else?
If we want this update, the next question is how dangerous it is. It's one thing when Facebook is updated, and we will go scrolling, and we won't be able to add likes. It is quite another thing when the life support system turns off in the hospital. If we do not care about the risks, let's update. If there are risks, then the question is in trusting the one who rolls out the update.
With Apple had no problems: there is a new operating system - let's take. It was before, and now we are already afraid of updating, there is no former trust. If we trust - no problem, update. If we do not trust - you need to test.
We do what is called acceptance tests. Here we are informed: a new Java was released, and for example, we are a Baidu company. Highload, 100,500 servers, cloud, JVM everywhere. We take some of the servers, start changing Java. A bunch of engineers have to do something and check it all out. Once every three years it is normal, but once every six months ... Have you been fucked? We will only check it for six months. Of course, we will not take this new Java.
Therefore, if we can check quickly, it is worth upgrading. But if you have to check for a long time, then you can skip a couple of versions. Nothing happens if we crawl from the eighth version right to the twelfth.
The problem is trust. If we do not trust, it will be hard to update. If the issue of trust is resolved, then there are no problems with updates. Or we have a feature, or we do not care.
Take chrome. He, starting with some version, updates at all without asking anyone. The risks there are small, but still there. But on the other hand, we trust those who write Chrome. Most often, when a new release of Chrome comes out, nothing breaks there. In fact, we have no problems with trust, and we go down this path.
We have an update, the risks are not important, we trust - update. And we will not be asked whether we want it or not, so we will always update. That is how it is done.
Imagine, netflix is ​​rolling out a new update, and now we can skip not only the titles and screensaver, but all the boring places. Cool update? Steep. Do we want it? We want. Will it work? Probably yes. As a last resort, we will go to YouTube, cartoons will see if netflix has broken.
The issue of trust is critical here. How do we solve it? The term "we" refers to the two co-founders JFrog, Fred Simon, Yoav Landman and your humble servant. We have written a book that advises how to solve this problem.
Suppose we persuaded our CEO, he read Liquid Software, and now he understands why he needs an update. He asks the consultant how we will update more often. Agile! DevOps! What is DevOps?
Devops
Let me tell you a little bit of the theory of what DevOps is, since we earn money from it. Take a look at the picture, we had these groups, teams, departments:
There are developers, there are Ops - system administrators who take what the developers have written, and throw it on the prod. And midway between the Ops developers, there are QAs that test. That is, the developers sat down, wrote, then carried them to testers, tested them, carried them to sysadmins, and they poured them on to the prod. For this we had separate departments.
Russian is beautiful: a department is always separate , this is the root of the word. In English, this beauty is not there, so these different departments are called silos . The best translation of this word into Russian was brought by Anton Weiss, who was the best speaker of DevOops . He calls silos "wells." Different departments - deep wells. To download some work there, you need to go down, and then pull the work out - to get up. The most convenient way to do this is in groups. How do we group things that we get from the well?
Naturally, buckets. That is, we have such “buckets of work”. The developers wrote something in the well, we loaded it into buckets, took it out of the well, carried the buckets to the testers, and lowered them into the well.
A lot of actions are performed to transfer work between different wells. When we group tasks to save on this work, we begin to load these buckets. Of course, the larger the bucket, the more we will save on this transfer process. Therefore, buckets make great.
What is the problem with big buckets? The fact that they fill a long time. Therefore, when we have important features that need to be immediately released to production, because there is a queue of customers with money - we cannot do this. We have the same wells, let's better we collect more in a bucket. Therefore, important features are waiting for any nonsense, as long as we have enough to fill this well. This is bad, as you understand. This is solved by the fact that we get and mix all of these wells.
I am not guilty! I just took the three original colors, put them one on another, and this color turned out. Now we all do everything. We have such engineers who are both a Swedish, and a reaper, and a igrets on the dude. These are Dev, QA and Ops. He wrote the code and tested it, and then also put it all out on the production - such a unicorn.
What is the problem of unicorns? That they do not exist. And those that exist, they have long been hired by netflix. Therefore, it remains for us to make a mixture.
Mixture
We have a common culture, common goals. We came out of the wells, we are all together now, but we still have deep specialization. A developer is still more a developer than Ops, and a tester is more a tester than a developer. But nevertheless, they understand everything. They understand what they do, why they do it and how it works.
That is, we have T-shaped people, "people in the shape of the letter T".
They have a deep specialization, they know very well what they are doing. They know well enough and everything else too. For example, developers understand a little bit how to test correctly, how the processes of laying out on the prod and so on work.
DevOps is:
- The culture of what we now have common goals, we understand what we do together.
- Automation to release more often.
Speed ​​and quality
Let's talk about the assumption that there is an inverse relationship between speed and quality. Roughly speaking, the sooner we release, the worse the quality will be. And vice versa: if we do not hurry, we will have time to test everything thoroughly. We have trade-off!
In order to understand whether this dependence really exists, let us turn to scientific works and talk about the State of DevOps report on the DORA organization. I highly recommend you to take a good look at this report.
How much can you trust him? The report says that in five years more than 30,000 people were interviewed, and in 2018 almost 2,000 people. This is a very large sample and on the basis of such an amount, for example, they make predictions for elections in the United States. Therefore, the study can be trusted.
In addition, Nicole Forsgren, who heads the DORA, unlike us, is a scientist, so everything is serious there. Let's see what DORA will tell us about this inverse correlation.
First, they divided all respondents into three groups: Low performers, Medium Performers and High Performers.
In addition, there is Elite. This is Netflix (actually not, see the disclaimer above).
As you can see, the proportions change. Naturally, five years ago there were a lot more Low Performers, now there are a lot more High Performers, because we are already starting to understand a little bit what we are doing.
This is somehow strange. It turns out that Medium is tested with pens more than Low. Why? Because Low doesn’t test anything at all.
They have a trend, a graph called the J-curve, which shows the same correlation or inverse correlation between speed and quality. And here everything is very strange. At some point we see confirmation of this inverse correlation. That is, the faster we release, the lower the quality.
But further correlation is not only not inverse, it is direct. The faster we release, the better our quality. Suppose we Medium and test pens. Everything is not bad, but slowly, because we believe that if we do not hurry, then we will test everything better. Then the consultant from DevOps comes and says: “Everything, now we are automating. And we do not need testers. All perfectly".
But without tests some nonsense turns out. After we realized that we still need to test something, and we need to automate correctly, we begin to automate correctly and continue to strive for transcendental heights.
This failure, where many bugs appear, needs to be overcome correctly. How to get into it, I think, there are no questions. The question is how to get out of it.
We need to answer the question of how to live without manual testing. The answer is the same as the question how to live without setting up servers. Obviously possible. What is changing?
Previously, we had a sysadmin who was rolling out a product for selling. He sat and waited for the developers to finish writing. After that, he took this product and went to the CD-ROM to insert and wire stick. What happens to everyone else at this time? All others are waiting. This bottle neck, plug.
We solve this with the right automation. We automate the process, we have a pipeline prepared in advance, and now the product rolls out automatically as soon as it is finished writing. Does it mean that now these people are not needed? Not. This means that they are needed, but are doing something else.
The same with testing. We have testers who test the product. They are waiting for them to write the product. They wrote - it's time to test. What are the others doing while they are testing? Do nothing, sit waiting. How do we solve this?
Again, the correct automation. We build the process. He will guarantee the quality of the product. We can prepare this process in advance, and then the product is tested automatically.
- This requires, for example, cross-functional commands . Here we are up from the wells and sat down together. Now we have a lion reclining with a sheep, and the tester works together with the programmer.
- We do Continuous Testing . It's like automated testing, but smarter.
- In the development process is "brainline testing . " This is a more correct term than “manual testing,” because manual testing is about the brain, not about the hands. Thanks for this term to my twin on Facebook, Alexey Vinogradov. Brain test occurs during the development process. As soon as something appears, it is already possible to check its flow, it is already possible to understand how it works, it is already possible to begin to outline some corner cases, which we will then automate.
- We are now following the developer. If he did not write the test first, we can give him a headstrike. This is Test Driven Development .
- Instant feedback is important. We should have a pipeline that immediately tells us as soon as something breaks. Because we have to go right away and fix it instantly.
- Participation in the design . It happens that you look at something and think about how we are going to test this shit now. But excuse me, where were you when everyone decided that there would be shit? You come to the meetings and say that you do not agree, you need to do it spontaneously. You must participate in the design to ensure that you can later test it.
- Tools, strapping, stands - what many of you are doing today does not go anywhere. On the contrary, this will be more. Accordingly, this is someone must write.
- Chaos engineering . You always dreamed of running Chaos Monkey in production, especially if you have an ATM network on Windows 95. Here is your chance.
- Finally, you need to teach ignoramuses to design tests . We decided that the developers at least claim that they write tests. Now let them write the tests, but you need to teach them how to do it. Who will teach them, how do they know how to write tests? Only you. No one else.
It remains to automate everything. In fact, we can automate testing. The problem is that you can automate a certain part.
You all know this joke about how a tester goes to a bar, orders beer, orders 0 beer, orders 99999999999 beer, orders a lizard, orders -1 beer and orders ... Here’s a bug, because it should be asdfgh, and not this bullshit.
It is easily automated. , . , . . — , , .
, , , , . . , , , — , , , . , , , , , . , , , .
, , , . DevOps. , . T- — , .
, - . « », , . , , , . , Selenium . , .
, .
— . , , . . , , Ops- , , , , , , , .
Developers in test — , , . , . , ; — , ; TDD , , , , . , , .
« ». , , , , , — . , , , , , , , , , , Continuous Testing .
end-to-end , . , , DevOps, .
, - , . , 70- : « DevOps, ». , , .
. -, , , , , . : ( EVP Engineering, SignalFx) , , .
70- . . , , . , . , , , , . , , , , — , netflix .
, , , , , , , , , . . , .
, . . « , », — , , .
«, — . — : , , , . , , , , , . . , - , . ? Artifactory , ?!».
, — , . , . ? !
DORA: , , , .
New Work. , New Work Low — 30%, Medium — 40%, High Elite — 50%. ( , Low) , , .
.
Heisenbug 2018 Moscow, — 17-18 Heisenbug. , . , ( ).
Source: https://habr.com/ru/post/445334/
All Articles