DOP 43: There Is No Such Thing As Continuous Testing

Transcript

Darin Pope 0:00
This is episode number 43 of DevOps Paradox with Darin Pope and Viktor Farcic. I am Darin

Viktor Farcic 0:06
and I am Viktor

Darin Pope 0:08
and Viktor has a new microphone.

Viktor Farcic 0:10
Haha

Darin Pope 0:11
He's probably sounding better right now. It's much easier because he likes to...how much...so when you travel...we've never talked about this. So when you travel, actually let me put it this way...when I travel I have a massive bag and I carry lots of stuff just because I'm usually there for a week and trying to maintain some normalcy. You on the other hand more times than not are not somewhere for a week.

Viktor Farcic 0:34
Yes sometimes Yes. I mean this time for example, I'm out for 10 days but I'm very unorganized person I just put random stuff in a suitcase and then figure out what you need and buy it

Darin Pope 0:44
and buy it when you need it. Okay,

Viktor Farcic 0:46
When I need it, yes.

Darin Pope 0:48
See, I couldn't do that, except for the one time my bag was lost.

Viktor Farcic 0:52
Ok`ay, so in my case, I don't remember the last time I actually bought any clothes outside of airports. It's been years I think.

Darin Pope 1:02
That's a sad thing because that's a captive audience. But this story sort of weaves into what we're going to talk about today. Maybe. I'm gonna make it weave into it. Testing. We had a recent episode with Eric Mizell about his concept of continuous reliability. We're going to take that one step further and we'll see if continuous testing is a thing. What do you think?

Viktor Farcic 1:32
It's not. That's it. That's the whole conversation. It's not.

Darin Pope 1:36
Why do people think it is? Okay, so, so let's define what we think continuous testing is, before we go any further.

Viktor Farcic 1:43
I can't imagine what it actually really is, outside of silly marketing from companies. Because, look, what I've been asked quite a few times... "Okay, so Viktor, you're gonna help us with continuous delivery?" and I said "Yes, I'm going to help you Continuous Delivery." They say, "but can you then join that with continuous testing?" And then my eyes start rolling around and I lose a bit of my hair because I cannot understand what would be continuous testing together outside inside I don't even know, but in conjunction with continuous delivery. Does that mean that you're doing continuous integration, continuous delivery, whatever continuous, without testing? And then you need to add continuous testing to it? Is that what it means? Does it mean that continuous delivery means that you're going to build something and deploy it? And then separately from all that test, maybe? Or if you don't have continuous delivery, then we're just going to deploy stuff automatically without testing. Well, what can it be? I really don't know.

Darin Pope 2:49
Is it just because they need to be on the continuous bandwagon?

Viktor Farcic 2:53
Because it's I think that the word continuous like together with DevOps sells well, and then companies invent Continuous something. And I don't understand what continuous something is. Can we agree right now that continuous delivery would mean that you are continuously delivering something somewhere, and that you're not doing in yours, unless you're completely insane, all that without testing. Can we agree on that?

Darin Pope 3:22
I can agree. I can agree with you on that. I can also tell you in reality, it doesn't happen.

Viktor Farcic 3:28
Yeah, I know. In reality, I have difficulty coping with reality. But logically speaking, continuous delivery includes testing, right?

Darin Pope 3:40
Yes.

Viktor Farcic 3:41
So what is continuous testing?

Darin Pope 3:44
That's something made up.

Viktor Farcic 3:47
It's the same thing when people ask me, okay, we want both CI and CD. No. CI is a subset of CD and testing is subset of CD and building is subset of CD and deploying is subset of CD. So there is no, if you're doing continuous delivery, there is no such thing as continuous building, continuous testing, continuous coffee making, whatever it is. It's all part of a process. Now my theory is that because still companies live in a highly separated with highly separated departments, and then, yeah, we're a testing department. We don't do whatever the others are doing. We don't cooperate with others. We don't work with others. They have something called continuous delivery. We are not included, because we exclude ourselves. And then we need to come up with something that's going to be continuous delivery, sorry, continuous testing. That's the only thing that I can imagine can be happening. And its just a sign of companies not understanding that there is no continuous anything without different experts working together.

Darin Pope 4:57
Well, continuous also implies to me that you've eliminated manual gates as much as possible.

Viktor Farcic 5:06
Yeah, there is no continuous with gates.

Darin Pope 5:08
That's probably the most inflammatory statement you've ever said. Say it again, because that's an important phrase,

Viktor Farcic 5:14
There is no continuous something if there are gates simply because gates means I stop, I wait until somebody approves it, and then I continue. Logically speaking, I'm not talking about how companies implement, but logically speaking, if you need to stop and wait for some unknown amount of time until somebody approves something, then it's not continuous. And I'm going to coin a new phrase right now, that probably does not exist in industry. It's a "delayed delivery". Right? It's simply it's logic. It's nothing to do with tooling. Forget about tools. You cannot say that you're continuously doing something if important, significant part of that something you're waiting for something to happen.

Darin Pope 6:00
Okay, we're we're hammering hard on the people that are delusional right now.

Viktor Farcic 6:06
Yes, yes. If you're delusional, then I think this is a wrong podcast for you. There are many people who can do real professional assistance.

Darin Pope 6:19
Let's go to the exact opposite of that. What if people do not believe that they can automate their tests at all? They said it's too complex. A human has to do their testing.

Viktor Farcic 6:33
That's better. That's bad, but that's better than the situation where they're fooling themselves that they're doing some automation just for the sake of fooling themselves and they're not, which is very common case. You know when you write a bunch of tests, and then they're failing, 20% of them are failing, and you still have a month of manual testing afterwards. That's fooling yourself. I would be actually happier if, if that group of people would say, okay, no automation, we're not capable of it. It's admitting something and that's good. That's not bad. Admitting that you cannot do something is not a bad thing. There are many things that I cannot do and I admit. I cannot dance. And I don't dance, because I cannot dance. I admitted it.

Darin Pope 7:17
But do you want to dance?

Viktor Farcic 7:18
No, that's okay.

Darin Pope 7:19
You can dance if you want to. You can leave your friends behind.

Viktor Farcic 7:23
Yeah, fortunately for me, I don't want to dance. But if I would want to dance, I would still admit I don't know how to dance because my feet are not controllable. Which is separate subject, but admitting it. Actually, in many cases, it's not only a bad thing, it's "Yes. This is a horrible application that was not designed to be testable, and we're not going to test it automatically. We're going to continue suffering until one day we go bankrupt or we rewrite that application." That's a valid statement. There's nothing wrong with it.

Darin Pope 7:54
It's a known state.

Viktor Farcic 7:55
Yeah, it's being sincere. It's accepting reality.

Darin Pope 8:02
Now let's back up for just a second. That is that person's current belief.

Viktor Farcic 8:08
Yes.

Darin Pope 8:09
But what if in reality, it could be testable, and they're just not aware?

Viktor Farcic 8:14
I doubt that it could be testable, and they're not aware that it is possible. But if I rephrase your statement and say, What if they're aware that they cannot make it testable? That's quite possible, quite likely. Actually, as a matter of fact, if you were capable of making it testable, then you would have done it so far. So the problem is you. You cannot make it testable. There's nothing wrong with it. I mean, there is something wrong with it, but it's an understanding what you can and what you cannot do. That's the first step because the next step is once you admit that, okay, so we need to bring somebody who can help us with that, who can explain us how to do it, who can teach us, who can maybe even rewrite our applications. Many options. But the first step. Its like being an alcoholic. The first step to stop being alcoholic is to admit that you're an alcoholic, right? I'm guessing. I'm not but I've seen it in movies.

Darin Pope 9:13
Okay, yes, I'm gonna go there. I want to go back to the bomb you just dropped about delayed delivery.

Viktor Farcic 9:24
Yes, that's the common pattern in most companies.

Darin Pope 9:29
So if people are fooling themselves thinking they're doing any kind of CX we'll just say it that way but in reality they're doing DX delayed everything. There's a lack of knowing how to admit you have a problem.

Viktor Farcic 9:50
Yeah. You're fooling yourself that you're doing something that you're not doing and that prevents you from solving the problem. Maybe the problem cannot be solved. Maybe it can, but it will never be solved. If you're so if this, let's say that the solution to your problems would be to do continuous delivery, just for the sake of argument. There can be many different solutions. If that's the solution, you're never going to apply that solution because you're fooling yourself that you're already doing that. So therefore, that cannot be a solution. Right?

Darin Pope 10:21
That's correct.

Viktor Farcic 10:22
I'm into philosophical mode right now. But if you claim that you're doing something, then that sounds and you're actually not, but you are claiming that you are, then that something is off the table as a solution.

Darin Pope 10:35
Well, it's Yoda. Do or do not there is no try.

Viktor Farcic 10:40
Exactly.

Darin Pope 10:40
I probably butchered it. So people don't want to automate their tasks because they can't. That's one thing. If people don't want to automate their tests because they're saying I don't want to do it, I know how to do it. I just don't want to. That's being...

Viktor Farcic 10:56
Being a liar. That's what it is. Because there is no person who says, who truly knows how to do something in that is better than something else. And at the same time says, I'm not going to do it. That would be the same thing as me saying, I know how to code in Go, but I'm not going to do it because I prefer to code in Perl. I mean, I most likely don't know how to code in Go. I mean, I'm using now we're not comparing the two. That's, that's not what I want to do. But when they say, I know, they don't,

Darin Pope 11:31
If we are trying to help people make a decision, change their mindset, where should they start? If they're not doing any kind of testing today at all and is something that could be testable, where should they start? Obviously, unit tests will be the right place to start, right? If nothing else.

Viktor Farcic 11:48
I think that there should if people are just starting, they should definitely without any doubt, they should not start with any of their applications, because that's going to be very hard and the lessons learned are going to be bad and so on and so forth Create a new application. There is always something new happening in a company. Find something that is being created new where you can start without the pain that will be inflicted if you start trying that something in an existing application that is not designed for that something. So start a new application. If there is no such thing as new application in your company, start your own pet project. If you do it in office hours, if you cannot do it in office hours, do it outside office hours. Figure out how to find a use case where you can apply that something with testing and something else that is not on your existing application because you're going to suffer through problems before and it's okay to suffer through problems when you'reexperienced how to know where to look for solutions. But if you have no experience, and then you're thrown into solving difficult problems that might not be easy or solvable at all, then you're in a bad place.

Darin Pope 13:02
I was thinking...I was saying unit test maybe a good place to start. Actually, if you've got a web based application, maybe that's the worst place to start. Just automate the click throughs the UI if nothing else.

Viktor Farcic 13:13
Yeah, something. That's also problematic. That's why I think that, you know, if you start from, I think that you should start from your unit tests actually. Because that will drive the design of your application. Otherwise, you're going to, if you start by clicking UI, then you're going to exaggerate in the amount of tests, you're going to, you're going to start testing things that shouldn't be testable in that way. You're going to create yet another technical debt, and you're going to wonder why it takes you weeks to write new tests and why takes hours or days to execute them. That's my experience. When people those that have seen that start from there, they simply think that that's the way how you should do all your testing and it's not.

Darin Pope 14:02
Let's go back to what you were talking about. Going to create a new application. Instead of working on your... now if your application is small, you're writing a microservice, then okay. There's no excuse. Do it there. But most people don't really write microservices, when it's all said and done. Most.

Viktor Farcic 14:19
Look, when you start a new application, it's a micro service no matter what.

Darin Pope 14:23
That's correct

Viktor Farcic 14:24
Because it's new and it doesn't have much in it. It is going to be small. I mean, unless you're Superman or something, and you can start and write hundreds of thousands of lines first day.

Darin Pope 14:36
And that's the right place to go ahead and get your all your continuous stuff done. You've got you've got the bones in place. You did let's say you're using Spring Framework or Spring Boot. You crank up the just a little Spring Boot app with the packaging in it that you need. The very first thing, don't write real code, figure out how to get that thing shipped. Just like get it out where its going to be running or at least a prototype of where it's running.

Viktor Farcic 15:05
Exactly.

Darin Pope 15:06
And once you know that you've proven that out, your chances of being able to be continuous are probably much greater. I'm not going to put a number on it, because you've already proven out, oh, I can do my code, I can commit, my hooks are good. The deploy side of it, the testing side of it is all working. You keep working, you start rolling in tests before you start writing real code. Where if you need to do integration testing, if you need to do database evolutions, maybe those are the first things you're putting in because those, those are your foundational things. And then three weeks later, whatever however long it takes you to get there, you start writing the real code.

Viktor Farcic 15:44
Exactly

Darin Pope 15:44
because then you have a good foundation to build on.

Viktor Farcic 15:47
And that's not really what you just said, is completely correct. And it's not related directly with testing that applies to anything else. Let's say that you want to change the database your application is using and you have zero experience, no experience. Are you going to start rewriting everything to use that database without having any experience or to change framework in your application or anything. First you get experience up to certain level and then you start modifying real deal.

Darin Pope 16:16
Well, and then you know how to test. You have to have experience before you can test it.

Viktor Farcic 16:21
Yeah. If nothing else, once you get a bit of experience, you will be able to say, not worth it not worth it. Yeah, I'm going to do that part.

Darin Pope 16:30
It's just when you have the blinders on is like, here's my JIRA ticket. This is what I do. It's just, it's a lost cause at that point.

Viktor Farcic 16:40
But that's kind of one of the problems. It always sounds as if its going to be more efficient, not wasting time on something that goes to trash. And starting and starting from day one on the real deal, as if that's going to take you somewhere faster. And I think that that's completely wrong. First you learn things on something that goes to trash, and then you apply it and you're going to get there faster for sure. Hundred percent sure.

Darin Pope 17:10
Well, so there's there's a guy I listen to, Ken Coleman, and I've talked about him a couple of times. One of his phrases is relentless preparation. I'll throw in the word practice there. So relentless, relentless practice, turns into reflexive performance.

Viktor Farcic 17:29
I like it

Darin Pope 17:29
If you keep practicing, at some point, it's just natural. That's the reason why you see sports teams. It's like, why are they just doing this one thing over and over again? Because in the heat of pressure, when that same scenario occurs, or a variation of that scenario occurs, the reflexes kick in and its like, Oh, this is how we solve it. Fireman you know, first responders, all those, they work in the same way. Why not apply that same concept to what we do as a knowledge worker. We practice. It's like, okay, I did this. Okay, this time, I'm going to Heroku. Okay, this time I'm going to build something, it goes into EKS. This time I'm doing whatever it is, right? I'm just building up these small things. This follows you know, nothing, nothing against your programming skills, Viktor, but uh, your classes and your books, those aren't full applications.

Viktor Farcic 18:24
No

Darin Pope 18:24
But what but what they are are practice

Viktor Farcic 18:28
of course

Darin Pope 18:29
And by drilling that practice, it's not about the code. It's about everything else.

Viktor Farcic 18:34
That's actually a good example. If I started, let's say, a book about Kubernetes aimed at people who know nothing about Kubernetes. And then we start with the complex scenario that requires some stuff that many people don't need and those that do really need it only after years of experience. Would you start with that? A book?

Darin Pope 19:01
Let's go with a real one. Hey, this is the introduction to Kubernetes. By the time you get to the end of this book, you're going to be able to run a multi region, multi provider cluster with a single application. Right? No, that's like why do that? Number one, most people will never need that. Most. There may be a handful of people in the whole world that we need that level of whatever. What you're going to get down to the end is "Can I deploy my application? Can I see the fail overs? Do I understand the concepts of Deployment versus StatefulSet?" Because those are fundamentals before you can even get to the multi cluster, multi region.

Viktor Farcic 19:47
The end could be what you just said multi cluster multi region. That could be the end goal of a book or a third book doesn't matter, end goal of something. But you don't start there, no matter what the end goal, that's not the start.

Darin Pope 20:01
Correct. But testing is always an interesting subject. What's one thing we haven't touched on? I'm going to step into it with both feet. What do you think of test driven development in the way that it's preached today?

Viktor Farcic 20:19
Now in the way that it is preached, that's hard, because different people preach different stuff, and ways to do that. But I do believe in test driven development being the only viable way to do development.

Darin Pope 20:33
What's your definition of test driven development?

Viktor Farcic 20:36
You write a test. You execute it. It fails. You write some code. You execute a test, and it succeeds. Simple.

Darin Pope 20:44
Okay, I had to ask because, as you said, it depends on who you're listening to.

Viktor Farcic 20:51
You know, those can be different levels. That test might require me to write a few lines of code. It can be unit test, it can be a big functional test that requires days of my work. But if I don't write the test first, I don't know whether that test is valid at all, because it might be passing anyways. Right? If test is written after the code, then it is too biased, right? You're going to go through the code and says, Okay, so the code says "x should be y", therefore my test should validate whether x is y. To me, tests are requirements and forget about you running them. You write the requirement first, and then you make the application pass that requirement. The only thing I'm suggesting is for that requirement to be executable. That's the only difference between what I'm saying and what people have been doing for a long period of time.

Darin Pope 21:58
which is writing Word documents

Viktor Farcic 22:02
Yeah

Darin Pope 22:02
that aren't executable.

Viktor Farcic 22:04
Exactly. I want executable documentation. Think of it that way. Forget about the word "test".

Darin Pope 22:10
Okay, you've come up with two phrases. One, you just dropped two. Delayed delivery. We'll probably get a lot of hate mail on that, but that's okay. We should get some more. And this last one executable documentation. Is that what you said?

Viktor Farcic 22:28
Yes, executable documentation. Written before, not after, the subject that is being documented.

Darin Pope 22:39
That's what else can you say? Without clear requirements without and I'm not going to say documentation but without clear requirements, why are you writing an application? Now? Clear meaning 80% clear? Because somethings you won't know until you get into it.

Viktor Farcic 22:58
It can be 80% can be 90%, it can 100%. Where i, where i disagree with how we were doing it in the past is that I don't believe that requirements should be right written months in advance. It can be I'm going to write the requirement for a thing, a single thing, that I'm going to about to start implementing. That's okay. And those requirements can change. That's also okay. I just want them to be executable. I just want them to be written in advance to confirm that that requirement is not fulfilled and then you to fulfill that requirement then confirm that requirement is fulfilled.

Darin Pope 23:39
Okay, I'm gonna I'm gonna make one more statement here and then we'll we'll wrap but I want to see what your response is to this. Most people that write requirements primarily are not technical, and the skill gap between those people that the skill gap is those people do not have the ability to write executable requirements. How do we help that?

Viktor Farcic 24:07
Stop not knowing anything about the industry you're working in. That would be unacceptable anywhere else. Why is it acceptable in software? I don't understand. Can you work in a hospital without knowing anything about medicine?

Darin Pope 24:22
If you're the janitor, yes, even the janitor knows the hazmat bags?

Viktor Farcic 24:28
Yeah, and probably knows what to throw to trash and what not. But I'm not talking about so one thing is to work in an industry and do a job that is unrelated with what the industry does. That's okay, janitor. That's cool. But affecting directly the outcomes of that industry without knowing what that industry is. That's insanity. That's crazy.

Darin Pope 24:55
Whether you're a nurse, whether you're a doctor, whether you're a radiology tech, all of you have had biology.

Viktor Farcic 25:02
Yeah. And you might...now there are different levels of experience. I'm not asking everybody to be the best coder in the world. I'm not asking that from anybody. I'm not asking that even from developers. But to have a certain level of understanding... ah come on, it's a must.

Darin Pope 25:22
And if you're not willing to keep learning, pilots have to go back for recurring training.

Viktor Farcic 25:30
Or at least Okay, let me rephrase it. Okay. You don't understand what what's it all about. You don't have capabilities to contribute to that, then actually limit your work to the absolute minimum possible. So if you're defining requirements, great. Talk with the team about those requirements, but don't be the one who defines them. Explain. You know, I think that people would like red color. Excellent. And then let somebody else define really what that means.

Darin Pope 26:05
You have the visionary person, and then you have the translator person that is able to get it to the implementer. Yeah. And that's okay. Dang, we didn't fight enough on that one. That's okay. Testing is always a very touchy subject. Because I don't see it done. Number one, I don't see it done very much. And most of the time when I do see it done, it is done very poorly.

Viktor Farcic 26:31
Exactly. But nobody today denies the benefits of having automated, automating repetitive tasks. No, sane person, sane person denies that.

Darin Pope 26:47
They may not deny it, but they actually don't do it.

Viktor Farcic 26:50
Yeah, they don't do it or they cannot do it or there are many reasons why it's not happening. But you know, it's repetitive. You automate it. Outside of software industry, it's already automated. So why not our industry?

Darin Pope 27:05
I can go to McDonald's. I don't have to talk to a person anymore. In fact, I can make my order, drive up to the McDonalds, somebody hands me the bag. Off I go.

Viktor Farcic 27:13
Exactly.

Darin Pope 27:14
I don't have to talk to anybody to place the order. I can customize it the way I want. The automation is getting rid of the frontline things. Who is the frontline people in our industry?

Viktor Farcic 27:26
Everybody

Darin Pope 27:27
Everybody? Well, to me, it's everybody. But to me, the frontline people are going to be the testers. They're usually the most junior to come in on a team.

Viktor Farcic 27:37
Wrong, wrong wrong. I mean, sorry, most of the time they are but they shouldn't be. That's another one of the things. It's kind of testing is not a stepping stone towards something better. It's not why would you be junior? You should be experienced test coder that actually knows how to write tests and help others who don't.

Darin Pope 27:58
But if you're a tester listening to this today, and you're like, well, I don't know how to do that. Go figure it out. There's this thing called the Google. Go ask the Google and shameless plug. Viktor has books and courses. To help think. I mean, and there's plenty of people that were just sort of joking there, but not really. Go learn. If you're unwilling to better yourself in your role, go find another job.

Viktor Farcic 28:31
Yeah. And I let me just clarify. Now we were talking about testers. But exactly the same applies to any other segment of our industry. So if you're offended, because you're listening to this and you're a tester, it applies to developers, applies to architects, applies to everybody.

Darin Pope 28:49
It's always interesting to go into places that on on what I talked about, and then I introduce Cobra, especially since we all yeah We're starting to do some stuff and Go. I say have you looked at Cobra yet? No. What's Cobra? Oh dear, right? If you don't know what Cobra is, it's fine. I'm not throwing you know not not saying anything. But Cobra is the framework that is used to build CLIs in Go. kubectl is built on it, Hugo, you name it, you go out to the Cobra, just go GitHub it and look for Cobra on GitHub. Did I just make up a new verb? GitHub it? You know, it's those kinds of things. So you have to always be learning. If you don't want to be if you don't want to continue learning, to me you have two options. Maybe more but two obvious options to me. One is retire. Just get out of the way so somebody else can take your seat or number two. if you don't want to learn, go find a role that doesn't require you to have to learn. But in our industry, and what we do, you have to be learning. Period. Like we learned today, Mr. Farcic, Mr. Rogers, Mr. Farcic gave us two really great phrases to think about. Delayed delivery and I'm gonna call it executable requirements or executable documentation, whichever way you want to call it,

Viktor Farcic 30:25
and also removed one word from your vocabulary. Continuous testing.

Darin Pope 30:32
That is correct. All right. Very interesting conversation. I'm still waking up and trying to grok all this. I think I agree with most of it. I'll have to listen to it when I edit it to see if I still agree with it or not. But if you're listening right now via Apple podcast or Spotify, please subscribe, leave a rating and review. All of our contact information, including Twitter and LinkedIn, can be found at https://www.devopsparadox.com/contact. And if you'd like to be notified by email when a new episode is released, you can sign up at https://www.devopsparadox.com. The signup form is at the top of every page. I believe that's truly every page now. Also, down in the show notes we'll have some links out to other things. Oh, by the way, by the way. Here. Fill some fill some time for me, Viktor. Quick.

Viktor Farcic 31:27
Hello, my name is Viktor. How are you today?

Darin Pope 31:33
Okay, keep going. I'm almost there. You cut the blade there under Yeah, no, that's staying in and that's that's classic. Okay, so we got a recent review on Apple podcast from folkengine. And let me let me read that just in case you you know. It was great. It says "as a developer who is finally embracing the harmonic convergence..." these are great words... "that is happening between development operations and quality, this has quickly become my favorite technical podcast. A wonderful companion to Viktor Farcic's excellent books and video training courses. I love how they embrace and dive into the ambiguity of the DevOps craft. Highly recommended." folkengine, thanks for the review, and the five star rating. See, listener can do the same thing. You can leave a rating and a review. Now folkengine, you were using some really big words there. Harmonic Convergence. Wow.

Viktor Farcic 32:36
that's too much for me.

Darin Pope 32:38
I wish there was Harmonic Convergence between development and operations and quality at most places. It's more like cognitive dissonance more than anything else than Harmonic Convergence. But anyway. Testing. Do it. Do it right. If you've never done it before, start small. Once you start small you grow steady. Just little by little, little bits here and there. Now right now, today is someday. I don't know what today is on the release day today's release date is...I should always write this down like a dufus and I forgot. Today is February 19 if you're listening on the release day, Viktor, you're probably somewhere. I know, I know exactly where we are today. We're actually physically sitting side by side.

Viktor Farcic 33:34
Oh, we're in Vegas.

Darin Pope 33:35
We're in Vegas.

Viktor Farcic 33:36
Yeah, baby.

Darin Pope 33:38
And this is not Vegas is not my favorite place in the world. It's one of the few cities you can go from the airport, get in the cab, go to your hotel, stay there for 15 days. Never come out of the hotel, get back in the cab and go to the airport. It's not one of my pleasant, most pleasant places to go. But yeah, we're actually physically together. So during this week we are recording, hopefully a few more episodes, just because we'll be face to face and whatever it is, but anyway. Is that it? Anything else about testing for today?

Viktor Farcic 34:14
Learn it. Apply it. Just like anything else.

Darin Pope 34:17
That's it? That's it. Thanks for listening to episode 43 of DevOps Paradox

DOP 43: There Is No Such Thing as Continuous Testing

Show Notes

Hosts

Darin Pope

Viktor Farcic

Links

Rate, Review, & Subscribe on Apple Podcasts

Signup to receive an email when new content is released

Transcript