 Okay, since there is a feedback form, I'll be very kind to all of you. Okay, hi, my name is Pradeep Sondarajan. It is a great pleasure for me to be here in front of you. So before I begin on anything, I would like to first understand what's really happening here in the name of testing. Because I can't be of value to you till you tell me what do you all do? So just to show off hands, how many of you do hands-on testing? Okay, good. So how many of you write code? Okay. How many of you manage testing or manage something? Oh, okay. There is also quite a few number of people. So there are some people who seem to do hands-on testing, coding, and managing. And I can imagine their life. It's not great. Just kidding. Okay, and what kind of apps are you testing? You know, web, raise your hands. Okay, web and mobile. Okay, web and mobile, backend, backend APIs. Okay, stuff like that. Okay, great. Okay, awesome. So, and do you have a title called a tester or QA, or an SDAT, or a software engineer? So, okay, I asked, how did you even raise your hands? There were like too many questions inside that, right? So you do have a title here called, software tester or a quality engineer or something like that. It still exists here. Okay, so I'm not in a land where it does not exist. It still seems to be relevant. Okay, but say, how many testers are there in your company about, you know, what say, less than 10 raise your hands? Okay, less than 10. Less than 50 raise your hands. Okay, less than 100 raise your hands. Okay, I'm not gonna ask the next question. That's too much already. Okay, great. You know, I asked this question, what's the number one testing problem in your organization? Can somebody say? What's the number one? Yeah, no one takes ownership of quality. Wow, okay. Good news, the rest of the world is not, is not, you know, different. Okay, but any other, you know, number one, you know, testing problem in any of your organizations. What's the number one problem? Yes, please. Yeah, yeah. Okay. Yeah, okay. Yeah. Okay, okay, got it. Yes, please. Rapid requirement changes unless time to test. Okay, just to show our fans, how many of you are in the same state? Okay. Banks, maybe they don't actually change requirements. Are you? Oh, okay, the mobile application aspect of it, right? Okay, great, awesome. Okay, so that's your number one problem. Yes, I think somebody else, yes, please. Oh, okay. Okay, very short time given. Okay. And I'd like to go back to Janani, I think, right? If we want this. So, you know, you're mentioning that they're not, they're not taking up ownership or something. Who is they here? Oh, the QA is not taking ownership. Oh, okay, wow. Okay. Yes, sir. Yeah. Limited understanding of testing. Oh, wow, okay. Yeah. Very, as you go higher in terms of the ladder, I think the learning tapers down or something like that, right? No, actually, we people who are doing hands-on and are more, you know, test-aware, the more our knowledge grows, it looks like others' knowledge is actually shrinking. But sometimes we also need to learn how to connect with them. But yes, I'm, you know, this is for me to understand the context, so I get your number one problem. Any other number one problems? Yes, please. Oh, yeah, the client's part of it. Okay, so you're in some kind of a services, you know, space? Okay, okay, great. Yes, please. Yeah, okay. Oh, yeah, I've been there very painful. Been there very painful. Okay, yeah. Oh, okay, curious. Okay. Yeah, people are like, yeah, yeah. Yeah, okay. Yeah, so we have people to clean things up so we can keep messing it up. That's some, yeah, okay. Yeah, yeah, that is true and but it's, but we all say that in the practice part of it. Yes, please. Lack of early engagement by whom? Well, okay. So by the stakeholders, you mean? Okay, okay, okay, good enough. Okay, okay, great. Oh, yeah. Okay, okay. Anything else? Yes, please. Oh, yeah. So there's that goal saying that by this time we should be done with automation. All right, okay. Yeah, okay. Okay, good point. Anything else? Yes, please. Okay, okay, good, good. Yes, anybody else? Yes, please. Ah, okay, okay. Cool. I'm getting this, you know, sneeze but it's not coming out and I'm trying to take the mic away every time it's trying to come but it's not coming. So, okay, good. Now I'll just pause this and say, I want you all to answer this question. All of these problems that you mentioned, how long has it been there in our industry? What? What are you saying? It's been there for ages. So if it's been there for ages, what are you trying to do over there? It's been there for ages. Okay, great. So what are we trying to do over that? Huh? Live it through, find a group therapy session like this. All right? Ha, ha, ha, ha, ha. Right? And come to these group therapy sessions and say, look, I do have this pain in my life. It's not gonna go away. We are gonna live with this, but please tell me how do I be happy while I go through all of this? That's a question you are not asking but should be asking, right? Now, for me, as I keep going to different places and connecting with a lot of different testers and I keep asking this question and the pattern is the same. Everybody that I have actually met has one or the other problem that was already shared here. But when they go back, our means, our approach to solve these problems is the same as what it has been there for ages. So why a problem has not been solved is because we have been trying to solve it in a certain way. Like, how many of you have put some kind of resistance in your company and said this is not the way to do it? Just raise your hands, okay? Everybody, almost, right? If you've said that, and of course, people would have argued with you some questions, some challenges. And any changes that happens happens when you're there and if you move out, that change vanishes or something like that. You know, this is another thing that I've actually seen. So it's a good point for all of us to think why, despite so many people, so many generations of people, facing the same problem, have not addressed this problem. And we, as a community, have not moved forward but we are stuck at the same place. So a decade after now, if there is a meetup and there's somebody here and there's somebody there and this person asks, what's your number one problem? And if the same thing comes up, then we are just not moving anywhere. So to me, it appears that we have gotten so used to the problem, right? But we are growing, right? We're growing in the last decade of you all working. Your compensation has changed, has improved. Your titles have improved. A lot of other things have improved. Yeah, that has not been static, right? If that had been static, you would have done something about it. Oh my God, that's very scary. But probably these problems are not looking scary for us. So we are kind of living with it. So another question that you may wanna ask yourself is, while you're complaining about this, okay, you didn't complain. You just shared in this group therapy session. You just shared your problem. But probably you have gotten used to this problem, right? Okay, probably the reason why these meetups are exciting for you is that you find a voice, you find a ear who can listen and who can voice out something similar. So while you think about it, I will just give you a quick tour of a new world of testing that I'm trying to facilitate, okay? Yeah, so, yeah, okay. So how do you prioritize these things? So for those who say testing is my first priority of my life, raise your hands. The first priority among all of that stuff, the first priority, no, okay, nobody. Okay, no problem, no problem. Nothing bad, and some people looked here and there saying, am I the only one? No, no, no, I'm not, right? Family is the first priority, raise your hands. Okay, awesome. You know, money as a first priority, raise your hands. Okay, somebody lifted half and went back. That's okay, that's okay. There's a second priority that's coming up, okay? Coffee as the first priority. You can have two equal priorities. So coffee as the first priority. Okay, first thing in the morning, if you don't have a coffee, you get a headache. You're that kind of person? Okay, then, you know, whiskey, whiskey or beer. Okay, awesome, okay, good to have. God, God as the first priority. No, okay, okay, that's good. I'm gonna be kind to God today. God has been kind to me. Okay, now I'm gonna come to the second priority. Who says, you know, testing is my second priority in life after a family? Okay, there's three, four, four hands, okay? You know, money? Okay, more encouraging, more encouraging. Now, coffee. No, okay, okay, whiskey. No, nobody? Okay, God, oh, okay. So we are, some of us are also considered to God and giving them some priority in life, good. Okay, so this is how you prioritize. This is how I prioritize. For me, till 2016, testing was my top priority. My family came as priority three. Coffee came as priority two, right? Why even I gave the priority three to families because they were the ones who were giving me the coffee. Okay, and I was so obsessed to, you know, to testing that I have put my family in tough situations because I was obsessed to testing. And then as times changed, my priorities also changed. My family got a promotion. My family got a promotion and testing still remains the top priority. It's just that my family got a promotion. I got married and my wife and we had a kid, right? So those two are the important educational qualifications I have and they got a promotion and then everything aligned. So I didn't know what to do with God so I've actually still actually put the God there. So this is how my priorities actually changed, yeah. Now, because of this kind of obsession to testing, I saw testing in a very different way than what people have been seeing. And because of which I used to speak about, you know, testing in a certain way in the organizations I was working on, I have worked as an employee, as a consultant, as a contractor in several places. And I wise out my opinions about testing and this is the way to test and this is the way to think. And hence I kept losing jobs as well. And my wife still loves me. Yesterday, I WhatsApped her, I love you and she said me too. So I didn't do that today. So I didn't put the first August. But yeah, at least till yesterday, if we were to go by WhatsApp, if that's a legitimate way of expressing and receiving love, she still loves me. And the reason why I put this up is that she is the one who had to go through a lot of hardship because of me being so obsessed to testing. She's the one who made much larger and bigger sacrifices than me till about, you know, 2016. If I was the wife, I would have really left this guy called Pradeep and ran away on day one. She has more perseverance than me, so she certainly gets a worthy mention every time I present. And so welcome to the way I see the world today and I wanna give you some examples of some of the problems that that. So, you know, so before I begin on this, Rahul Verma and I are, you know, two people, he specializes in some things and I specialize in other things and we are very complimentary in nature. So I have specialized in product owner value, business analyst value, exploratory testing value, functional testing value, and he specialized in the performance, automation and things like this. And we had this smaller group therapy sessions at that time in a coffee shop and we used to keep talking about, you know, things. And then we said, this is getting too much. We cannot afford to see testing continue to have these problems and we have to solve these problems. So that's how we started, you know, building something. And we see that there are two kinds of problems in everything that you mentioned, right? There is a testing problem and then there's a tester problem. So some of, when you said they're not taking ownership, that was let's say the tester problem, less of testing problem, but still there is a testing problem. So if you, whatever you actually spoke about, you could bucket that into a testing problem or a tester problem or a people problem. Instead of saying a tester problem, you can say people problem and that people also includes the developers, the testers, the stakeholders, the managers and everybody. So, you know, and I try to understand what are these testing problem? You know, to me, the current state of industry is a combination of this, yes please. So to me, testing problems are these. There are org problems. There are org problems. And then there are culture problems and then there are software industry problems. So for you when you're facing something like let's say, you know, a bank, I was once consulting for, you know, Mercedes-Benz in India and I showed them a few tools and the testers there said, oh wait, we can't use these tools. I'm like, hey, you just said a problem and this tool solves the problem for you. Why can't you use these tools? Oh, because it has to be approved by the tools division where since it's Mercedes-Benz, they have to take it through a high level of security checks of that tool before we can use it. And I asked them, how long does it take? And they said, one year. Now, I asked them, can you give me a list of tools that you're using? And then they gave me a list of tools that they're using. And then I said, oh, okay. How did these tools get in? And then one person said this great thing, yeah, but all of these are outdated versions because they are always one year away. I'm like, you wanna build cars that are three years ahead and you are using tools that are one year obsolete. Why? Right? So, now this is an odd problem. What can you do there? You can't do anything about it unless you get an appointment with the CEO and say you're doing something wrong and he wants to listen to you or she wants to listen to you. But it's unlikely to happen. So that's an odd problem as an example. And then there's a culture problem. So sometimes we don't know what's the contract people have, like, let's say, if there's, if a partial development is outsourced or if there's some partners also supporting, you don't know what kind of contracts that people have signed. And you don't even know how are the developer, how is the developer value being assessed? If the developer value is kind of assessed, like, when you said quality has to be everybody's responsibility, it has to be everybody's responsibility. Holding one person or one team or a one set of teams accountable for it will actually spoil the whole culture of the company. So in organizations when there is such a culture, whatever you try to do, unless you fix the culture, nothing is gonna change. Absolutely nothing is gonna change. So those are the examples of culture problems. And then there's software industry problems. We always copy what the big four does. If Google says, oh, we don't hire manual testers at all, a lot of companies try to think that why are we doing it wrong? Why are we doing it wrong? Right? Now here is something that what they're not actually telling. So there's a book called How Google Test Software, How Microsoft Test Software. In that they don't necessarily mention that they do hire testers. They don't. Now, I was consulting for a couple of IT services companies in India. The iTunes page that you see in the Mac is actually tested by a couple of testers in India, but not tested in the US Apple. Okay? The browser does all things load in a browser for Microsoft, is not tested by any of the Microsoft employees, but it's actually tested there. So when I was consulting, I had said, oh, we could automate these things, right? We could automate these things. They said, oh, yeah, that the Microsoft employees are doing. Then why do you want this to be done? Because we want human eyes. Right? So these companies are not sharing these kind of things, and they are trying to mask it. Now I wrote being obsessed to testing. I wrote to these authors and I asked them, hey, why don't you say it out? Because I went to the company that you outsourced this part of the testing too. And you're saying that there's nothing, there's no mention of that? And then they said, oh, Pradeep, you haven't read the book properly. Here is one line about it in a 400 page book that we use some partners who bring in a crowd of testers to help us get a different coverage or in the wild testing or something like that. So for me, these are the testing problems. Yeah. Some of the odd problems that personally I've come across is the product versus engineering. Anybody going through that? Do you have anything like that? The product teams and the engineering teams are in conflict for some reason. So that's one kind of problem I've actually gone through. And then the engineering versus the test and QA, which is something I heard over here, so it's still there. And the agile and DevOps implementation. So I asked this question to a lot of people. Okay, are you agile? And people say yes. And then I say, really? And then they say, no. Huh? Okay. Right, so what's that? What's that? You're like, are you agile? Yeah. Really? No. One simple switch. And it's so easy for them to do that switch. Okay, the other thing that I'm going through about is that the automation versus the test automation. You know, there is a difference of that. You can automate without tests. You don't need tests to automate. Automation is independent of testing. We can add a layer of testing to it. But just because there is automation does not mean there is test automation. Maybe you began the automation looking at the test case document, but still it is not necessary that there is test automation. I'll come, I'll tell you why. Not respecting as, you know, testing estimates. Do you, anybody here still gives, you know, testing estimates? You do? And when some people mentioned about the, you know, the testing time is actually shrunk, you know, but do you give estimates at the start? Do you give estimates like how long we need to test this? Okay, currently no, okay, good. And for those of you who are actually doing, I've seen this practice for, you know, for actually quite a long. And they ask for the, ask for the, what's the estimates, but they don't respect it. So it's, so to me every time it feels like I'm gambling with them. What's, what's the number? Magically I'm thinking about seven. No, six. Okay, six. Actual is three, but okay with six. Right? And then, you know, you know, expecting the QA to do, or the testers to do gatekeeping, saying you are, you are accountable for the quality. Wow, I feel awesome. But in reality, I'm not. And then implementing ideas without fixing leadership and culture. So a lot of companies today, if you know, what's the implementing agile and, you know, things like the DevOps and all of that stuff is a cultural change. So the management, sometimes the management would have heard a buzzword in one of those, their own group therapy conferences. And they would come into an organization and say, every other CIO is talking about agile. We, we now have six months to call ourselves agile. But, but the, it has to be a cultural change. And the culture starts from them, but they don't recognize it. They're like, you do that. I'm just going to put that in my profile that I help implemented agile in this company, right? So I've been going through this and if you smiled and laughed a little bit, then it looks like it still resonates with you. And the, and the software community problems again, it's, there's a lot of best practices, you know, discussions about, hey, you know, this is what it is. A lot of people who, who have been following, who have been pretending to be agile, think of that if they do a two week sprint, they are agile. A lot of, a lot of them, because when I interview people, this is one thing that I get. And, and it becomes like it is, it is that everybody is so glued to following the best practices. And this is another thing that has been plaguing. So, yeah. So now coming to the tester problems. Fear. I'm afraid to. I'm not, I'm not saying I'm not afraid, but my fear is very different. Hi. So my fear is very different. If, if I die without seeing a change in the testing, I will not rest in peace. That much I know. That is my fear. That so many people, so much of effort, not resulting in change, then we are all bullshitting. So, so that's my fear. But, but most of the testers that I've come across have some kind of fear. Fear of, oops, I'm sorry. I'm gonna stay a little bit away to make your job a little easy. Otherwise I'm gonna be like somebody who peeps into the cam or something like that. Okay, so, yeah. So there is a certain level of, you know, fear. You would have challenged in your company, but you might have not gone to the extent to piss your boss off, right? You would have done some polite challenges here and there. I slightly disagree with you. Maybe you fully disagree with him, but I slightly disagree with you. So, so there is some level of a fear which is making us not highlight the problem the way it is sometimes. And then there is a very shallow thinking. Here is something I was thinking about, about a lot of things about automation. It's okay. I think that if people were able to automate all their tests, then their tests were horrible in first place, right? If you could automate 100% of your testing, then your testing is horrible. Now, what you have achieved is automated horrible testing. I'm glad that way that you don't want humans to do that, right? So for me, I see that a lot of thinking that's going in, it's very shallow. Now, you know, in the waterfall model or there was a time where there used to be a very big BRS, FSD, I don't know what all the names they give. FRD, FRD, BRS, sounds like a little bit like FBI, we're working in FBI. But in practice, there is a lot of heavy documentation. By the time the person finished the documentation, he actually wanted to change the first few lines, but he got tired about it. So it used to come to me and we started trying to understand that. Now, they've made, in the so-called agile word, they've tried to make this life easy. They have an epic and a story. Y'all relate to that? They have an epic and a story. And here's something that I've seen about testers is, they're very, here I'm gonna give you an example of this, what's a shallow thinking. They take the acceptance criteria and convert it into expected result. What kind of test design is that? Do you call that test design? It's not, but you see that's all that's happening, that I see all around, that people take up an acceptance criteria and try to convert that into an expected result and say hence pass, which is sometimes also what organizations want. But here is something, and then about automation. So how many of you have actually pivoted from being hands-on tester to a full-time automation? Okay, okay, good. When something becomes red, do you feel good or you feel like, oh my God, now I'm gonna be asked the question, why did this turn red? Good, okay. Many, many people that I come across, first they get concerned that is there a bug in my script? Right? Previously, when they were a hands-on tester, they were like, wow, I found a bug. And I was recently consulting for a very large, very mature, multi-billion dollar company where their head of test engineering told, oh Pradeep, these are constantly turning red, I'm getting concerned. Okay, why? Because we will be asked questions. That's okay, that's okay. If people wanna ask you a question, I mean it's not a scary thing, right? People can ask you questions. What's the problem there? No, this was green. Of course this was green. That's the reason why we exist. That's the reason why we exist. Of course this was green, yeah, but that was in the previous version, previous build, not in here. In here it's red. Now I have seen sometimes, I know people try to change their script to make it green again, okay? One thing that happens, the other thing that happens is that people say, so the other thing is this, when this project gets started, like you were mentioning about the time pressure part of it, right? People think that, oh, so every, again going back to the best practices part of it, every other company that I come across have completed this in six months, so we should also complete it in six months. Maybe our product testability layer is not ready for automation at all. So here's what I've seen people do. Now you can either vouch or actually not vouch for this. When they wanna automate, they come up with, these are the element IDs or accessibility IDs or whatever. Do you really get all of that? You don't get all of that stuff. I've seen in one script, it switches from X-part to element ID to access, what is this? This is some, for those of you, you all should know about it. It's like Masal Puri, a script which you know you wanna have it through the accessibility IDs or element IDs. You have switching between X-part and all of that stuff. You are making your own script prone to failure, right? And then suddenly it switches from web view to native view for those of you who are automating, what's it, mobile apps. Oh my God, that's like a moving target, right? So for me, I think that there is a lot of misunderstanding about automation and the reason why the industry is not changing is because of you people. The whole, all of us, but you people, because you are supposed to say, I'll not write it. We don't have all the element IDs that we want. I can't write a script which actually switches between X-part and element IDs and the web view and this view and we are not ready for it. But we don't say that. Since we don't say that, why we don't say that is because the person replacing us will not say it. You might say, but the person replacing us will not say it. So because the person replacing us will not say it, we go by the flow. You heard of that? Have you used that any time so far in your life? Go by the flow. So if you go by the flow, we get to where we have gotten to, okay? And then about the skill improvement. Now I was actually talking to a few people. If you are, you are in the business of changing culture first. Since you're in the business of changing the culture, you need a lot of skills which are towards influencing people. And there are two ways to influence people. Is A, by understanding humans, B, by building tools, okay? Now I see that the industry is neither focused on helping people add skills related to human connects to the way to influence human beings. We are not learning that. Most of the tests that I've come across, what is in your learning agenda? Selenium? EpiM? Is there any other popular tool in the market? Some of them don't wanna learn Java because they think that's gonna become obsolete. They wanna learn Python. It's not about problem solving. It's about, again, my resume building. So for generations of generations, we have not focused on solving problems and we are only focused on building our profile. So our profile is beautiful today. All of our profiles are very beautiful today. So if you compare about how you were fresh out of college and now, now looks way better. But the problems that we are continuing to live with, that's been there the same way. That has not changed. As a matter of fact, that's getting worse, sir. So that's degrading and we are upgrading and that's where we are. So for me, I think that those kind of, what's a skill improvement needs to happen for us to change the world. So as I said, Rahul Verma and Rahul Verma and I got together and said, okay, we can't do much about this unless we jump on and we try to make some impact, something here and there. And scale it. So we both, with no choice, moved away from being a tester to an entrepreneur. We, like you all think about your career growth path, right? Even I thought so that I would become a test architect. I would build nice, beautiful strategies and plans and set up labs and all that stuff. But I was, this problem that has been there in the industry has forced us to become entrepreneurs and say that let's try to show to the world some ways to solve these problems. So I wanna give you some glimpses of what we are trying to create. So first on the culture part of it. For testers like Shashank who is here who's been with Mulya for a while right now. And yesterday I discovered this interesting conversation he had with the VP engineering. So there's a new VP engineering who came in for the project that he's working on and said anybody can test. You've heard of that? We all have heard of that, right? There's no escape from it. Most of the other testers just shrugged and said, okay, yeah, so what? But then he challenged and said, not true. And then the VP engineering refreshed. Well, if good test cases are there. And then again, like the agile thing, he said, not true, not true. And then the VP engineering kept refraising. Well, actually this is what I meant. Actually this is what I meant. How often have these kind of questions been asked to the VP engineering and the CTOs? We have not asked these questions. So this has let the problem continue. So the VP engineering who moves from one place to another place would go and say, would make it a very bold statement. Anybody can test. But I hope this VP engineering who faced Shashank would now be cautious to say it outside because he knows that there are testers who challenge him. So that's the big part about the culture, that the first thing that we are trying to inculcate into our company is to say, you're not gonna lose your job. If a lot of fear is coming about your job and what will happen if you challenge, what if I give you a safety layer to say, whatever you challenge people, you're not gonna lose your job? Now people would just say, oh, that's bullshit. Right? They might have said, I slightly disagree with you, but now the slightly disagree with you can transform from I slightly disagree with you to, oh, that's bullshit. I don't think that's gonna work. In a very calm, nice way. I used to do this, but in a very aggressive way. And that's where marriage, children, and the gray hair helps very good. Okay, now I say, oh, yeah, that's bullshit. It doesn't gonna work like that. And so we're trying to set, and we have set this culture, that you're not gonna lose your job, make mistakes, we will back you up. For those of you who are in the position of leadership, not lead by designation, those of you who are in the position of leadership, and those of you aspiring to be a leader, this is what it is. It's to tell your team, make mistakes, I'm here to back you up, because if somebody is gonna lose the job, it's gonna be me first, not you. And I am putting myself to the risk so that you can do better, and that's what your teams need to do. Okay. The human approach, okay, hire people who know how to be happy. So, in our experience of having hired about 300 plus testers so far, one thing I realized is there are some people who don't know how to be happy, no matter what you give them. In, so in our form, in our interview application form, okay, today, we have questions about do you smile, how often do you smile, all of these things, and it's so important, and it's so important. Why, because these people bring a change, both good or bad, so it's important for us. And then, okay, now I'm gonna talk a little bit about the testing solutions we are trying to build. Yeah. So, a lot of us keep talking about test coverage, and here's something that we are trying to work towards, is to connect with the developers and the product owners and the BA, and ask them what do you care about? So, okay, you care about functionality, you care about user experience, you care about consistency, those and the error messages, APIs and all of that stuff, and we prioritize things based on what they care about for certain releases or for certain things. And then, look at the analytics and say what are the top five, six devices you care about based on the analytics? And then, we do tagging of the tests. So you can boil down the net result, to say pass or a fail, or we have achieved a 90% pass, or sanity has passed and things like that. But this gives the real story of testing. This gives the real story of testing. So, we have, since you mentioned that sometimes, the customers don't understand the value of the testing, laying them out the whole actually picture for them to say we are good on this device, but not on this device, we have not even touched on this device. Now for them, if they come to us and say, yeah, okay, are we good to make a release? I don't wanna tell you that, you figure that out. So, if you wanna implement a culture where everybody is responsible for quality, people should not be asking around, are we good to go? There is a central system that should tell them. So we, what we have done is we built this system for our customers to say that, well, you're a product owner, you're a developer, we, and I'm a helper, I'm an assistant for you to build things that are relevant for you to make decisions. And what I'm saying is this, what is business critical for you, right? And so you define this. Now there could be, now the conversation is this. So after we come up with this, there is another conversation that we have. How does it matter how many tests are actually showing a go or a no-go? It doesn't matter for them. There could be three tests, or there could be 3,000 tests, but that's not what they should be looking at. They should be looking at go or no-go. And our job as testers is to build this system for them to help them decide whether they should go or no-go. And now in the backend, there's a lot of tests, yes, but there's a lot of tagging of this test. If this test and this test fails, then it is business critical. If this test alone fails, it is not business critical. That's where our intelligence, our value as a tester should actually come in based on the business knowledge, what's it that we understand, right? So what we did is we automated the go no-go and told people, don't come to us. Only if I have given a sign off, you want to hold me accountable for it. Now, we all three of us have arrived at this dashboard. Now, there is nothing you need to ask me, right? If there is an issue in what's the production, I would as a tester want to look at what could I be missing, but that goes in as a learning cycle and not as an escalation. Who tells the bad story of testing? Even with a 100% test case pass or whatever you have done, even if they give you more time, can you tell, here is something I don't know. Here is something I have not done. Here is where we have done poor coverage. So we ended up building something which actually tells the bad story of the testing. Makes us look more vulnerable and more as an expert. Now, I understand in some organizations, people will say, oh, why are you not doing good? Then we can talk about the constraints of why we are not doing good. A, it could be time. B, it could be, you know, what's available, you know, devices and resources. Okay, B, it could be the, it could be the people that we don't have. So there could be a lot of things like this. And then, so what Rahul Verma is doing is Rahul Verma is building something where he's trying to put the test back into test automation. So he and I think that the word test is not as prominent as the word automation in test automation. There is a lot of automation, but very little on the testing front, which is what I mentioned. So he's trying to build this, you know, framework called Arjuna where a test can decide for itself. It's not AI, but it is something where a test can actually decide for itself. This is open source. So you can go, what's it, check that out. And, you know, what's the analytics? So we are trying to come up with a lot of test analytics and tester analytics. Now a lot of test analytics has been there, but there has not been a tester analytic. Can we have a heat map for your project? A heat map which tells these are the areas that the testers have touched. And these are the areas that the testers have not touched. It's a good feedback tool to the testers. So we are trying to think like this. I'm just giving you examples, right? Another thing about automation is every time there is a failure, okay, people go into investigation of is it a script failure? Is it a test data failure? Is it that failure? Is it this failure? Hey, why can't we have all these things built in that it clearly tells, this is where it is? Every time I see there is a failed script, there is an investigation before people can include what went wrong. So we started to think about it and we started to build saying, hey, this is broken. This script has not failed previously. This is a critical piece of the analysis that you do with automation, right? So all of these things is what we are trying to build. And then about, for those of you testing in the mobile applications, reporting bugs from a mobile phone is a massive pain. I feel people have gotten so used to this pain that every time they find a bug, they take a screenshot, they send it to the computer and then from the computer, they recover the screenshot, then go to JIRA, start composing, 30 minutes for every time somebody finds a bug is lost in reporting that bug. Now, do you wanna spend more time testing or more time reporting bugs? It's an opportunity cost problem. So we said, I don't wanna live with this problem and so we started to build a tool which actually helps capture the screenshot and in terms of roadmap for this is about, since I mentioned about the heat maps is to bring in heat maps and say, these were the portions tapped by the tester, these were the portions not tapped by the tester. This has never been tapped. Like how you saw the automation script failure which said this test has never failed before, this area has never been clicked before is a great, great feedback to the tester, right? So even for those companies where you want the developers to test, your users to test, your what's it beta users to test, this is going to be helpful in terms of saying that, hey, this area has never been tapped on, this area has never been what's it clicked upon and then the tester analytics to say how many flows and how many screenshots and in terms of the bugs reported and things like that and the coaching part of it. So why are we building these tools? We're building these tools because for a couple of reasons. The whole world is going to continue to do the automation that they think is automation. Okay, to people like me and Rahul Verma, okay, building these tools is an essential part of automation. Why these tools is because we are focused towards building self-reflection tools. In your companies, okay, let me come to your own behavior. How many of you have a watch or a fitness tracker that tracks your heart rate, your steps and all of that stuff, do you use that? Okay, now, why did we as a generation become so obsessive to tracking how many steps we walk? Like our forefathers, the monkeys, all of them, they never bothered about like how many steps we walk and all of a sudden we have become sensitive to it. Why? It was not required, okay, yeah, good. And we, yes, please. Yeah, so yes, please. It's just because of FOMO, okay. So here's what I think. Everything that the fitness tracker was telling me is what my wife told me, but I didn't listen to. You're not walking, you're sitting in the same place for a long time. Every time I get the message from my me band, I was like, this is my wife speaking to me, but I didn't listen to her. But now I listen to the me band, right? So that goes to say that if it's a technology or a tool, we pay a different attention, we don't attach bias to it. And that is essential. So the reason why you need to build tools in your companies, not just the tools for enabling your DevOps or something like that, but tools like this, which acts as a self-reflection tools, is to help people move, is to help them see that they're not moving, they're not walking enough, right? Okay, relate this to what could be you know, a parallel for your company. Okay, now in terms of the coaching, so when I became a product owner for these tools, one thing that I realized is that the testers working with me, they came and said, these three problems are very, very critical problems. And I was like, as a product owner, I was like, no. No way. But it's a crash. Yeah, it's a crash, but no, that's not a problem for me. Why? They didn't ask me why they just went away because here's the reason. The user is never getting into that screen at all. The user has stuck three screens before and we are trying to report a crash in an area where there's nobody there. So for me, this was a wake up call that as a product owner, I have people reporting some bug and calling it high severity, high priority. We would have all done that, right? And we would have also faced that nobody cared about it. The reason is this, that we don't yet understand the context better. So one thing that I realized is that since I moved from being a tester to a product owner for testing tools and I saw that the testers are not connecting with me well, I realized that no product owner that I have come across has coached the testers on what do they want, right? Not have the testers asked, can you coach me on testing? We have never asked a product owner to coach us on testing. We might have asked a developer to coach us on testing, but we have never asked a product owner or a BA to coach us on testing. They are the ones who are consuming testing. So for me, this became an eye-opener and I started to coach testers on the product owner perspective, on the BA perspective, and started helping people ask the right questions to the product owners. That clears a lot of air, that negates a lot of tests, that reduces the quantum of tests and boils it down to just five tests that is essential. So today, for the tools that I'm building, I have three, four criteria. The USP, right? The revenue or the usage. The first time experience. If these three things are good, I can make a release decision. But here is what I get. Six crashes, seven bugs, three high priority. What sense do I make out of it? Nothing. It's important for you, but I am the one who is consuming as a product owner. I am consuming your report. I don't have a clue of this, right? So I started to coach people for free about the product owner perspective and then I had started to do a tour of India, spending my money to go across India to coach testers for free. And then, as an outcome of that, this beautiful thing that happened, there was a tester who actually came up with the mind map of the Baghasura app and said, here is how all the connections work. Okay, bye, Janani. Bye, Sia. That's okay, right? Okay, here is how all the connections happen. And so do you think I've understood the flow really well? This gave me a lot of confidence as a product owner, which I didn't have in the past, right? So, okay, next. Yeah, so since I've been talking about building tools across the pain areas, I just wanna bring this up. I think that this is the spectrum of testing and there are pain areas everywhere for a tester. But what we are doing is we are just taking this part of the pain, which is running tests and automating just this part of it. For me, the pain is across and nobody is looking at the pain other than the run pain. And so I'm interested to build tools across, not just me. I want to, so when we talk about open source, we think about automation frameworks in the testing space, correct? But can we open source the thinking layer if you are thinking really good about how to investigate bugs? Can I open source that? I'm talking a little bit like Elon Musk, but not like Elon Musk. I'm trying to say, can we put a hook to your brain and get away, use your mechanism of investigating bugs to all testers? How can we do that? So this is another area where I'm trying to work on. So the new world that I'm imagining will have the deep thinking testers and then we have testers building tools, the kind of the tools that I've been talking about. And yes, and testers becoming more influential. If these three things don't happen, then the world looks as scary as it is today. And as a conclusion, I'd like to say that I'm, me and my teams, we are launching a tester app store this month, where there's gonna be a lot of testing tools, tester tools and testing tools. Like the way I split the problem. Ajira would not be a tester tool. It would be a testing, a test management or an issue management tool, but we are trying to come up with an app store for testers. And what we mean by testers, I just wanna qualify this, the future is everybody is going to test. The product owner is going to test, the developer is going to test and the tester is also going to test. But these three people will be complimenting each other in their testing approach. So we are trying to build tools and we are going to run this like the app store, where you can contribute your ideas and your tools so that more testers actually benefit from this. Now for those of you who don't know the code, okay? You can become the product owner, you can share, this is my pain point and we will match you to a developer who will build tools and that developer could be one of you in this room. So you are excited that you're solving a testing problem for the globe and somebody has this, what's a pain point. Now, once we announced this, I'll share it share it with these people so that the link can actually come across, come to all of you and you also please start to think about building these tools. Now when I say tools, it doesn't necessarily mean code. The dashboard that I showed you is a tool but it does not have code, right? There are other tools that I showed you that has code. So we are trying to think that this is the way that we can influence the world by building a lot of tools that helps people to test, that helps people to visualize, that helps people to think. And with that, thanks for this opportunity, thanks for the time. If you do have any questions, I will be happy to answer that. Okay, thank you, thank you. Yeah, yeah, yeah. So Pradeep, you just now mentioned like in today's world of testing, you know, we have a scenario where product owners are doing testing, developers are doing testing and testers are doing testing, right? So, but that is anyways happening because product owners are engaged in UAT. Developers are anyways engaged with their unit testing and all and testers are anyway, they are across the whole testing phase. So I'm just trying to understand, in that context, how different it would be what you are just now mentioning with today versus. Okay, so I'll give you an example and parallels to the testing thing. Previously, there used to be doctors who used to give a diet. Now there are dieticians, nutritionists and every family member today knows a lot about diet and nutrition. Everybody gives nutrition advice to me. I hope the same with you as well that everybody in our family knows about keto, how keto works, why keto is not good, all of that, everybody knows. Everybody today and we had a situation where if you want to get a blood glucose what's a test, you had to go to the hospital. Now today everybody is a doctor. You can do tests on yourself and there's a machine that'll give you, there's a tool that'll give you an instant result, right? Like that, the other industries have advanced quite well to make everybody test their blood glucose at home. Like that, we as a testing or the software engineering is moving to a space where everybody at some point is going to test for different things, right? Now today, as somebody mentioned that there was a phase where people had testers and said, oh, they are there, we will do other things. Now they're realizing that it's not working out, they also need to participate. Some people have realized but they don't have time and for those who have not realized the testers are trying to tell them and there is new roles of quality advocate and all of that stuff coming in to help them test for things. Now we can say you test but they don't know what to do beyond that word. They'll do some taps and here and there and they'll think that is what testing is. Can we have a guided way for them to test? For instance, today I know for sure a lot of these new age startup CEOs when a new version of the app goes live, they test, right? And they send a bug to their CT or somebody. Maybe we can guide them to test better, right? Maybe we can say, hey, this is the device specific issue the moment they want to report. That's the kind of tooling that I'm thinking about which is very different from solving the problems that the whole world is trying to solve. So for me, we as a community try to, we need to focus towards building that world to enable everybody to test so that a lot of test dependency is not on us but we complement each other. I may specialize in something, for instance, the CTO or the CEO can functionally test an app but you ask them to do a performance profiling of the app they'll not be able to do. That is where probably you come in. Even that, you can build a tool around it and say, now even now I'm not gonna do this and you will continuously keep finding what is that one thing that nobody else can do that I can do? That is where real value comes from. If we don't do that, then we are trying to do what everybody else can do and that's not going to add a phenomenal amount of value. Okay, primarily because they think that, oh, I can replace you. It's not a big deal, anybody can test. So I want everybody to test but only some people can test well. So that's what we are trying to move towards. I hope that helps in some way. Thank you. Okay, welcome. Yeah. Anybody else has anything? I have a question for you, sir. Five to six phones. I'm just trying to be curious of, I've not seen somebody with actually five to six phones. So, okay, can you help me understand why do you have so many phones? Oh, wow, okay. Oh, wow, nice. Awesome. Oh, wow, multitasking. Multi-threaded, multitasking. Awesome, awesome, very good. Yeah. Yeah. Awesome, awesome. Do you mind if I just, or if you can actually show it to people? Yeah, yeah. Oh wow, that's something I've not seen like this before. Yeah. It's quite common here. Oh, but you've seen people. Which planet do you come from? He carried 30 phones, all the... Yes. Oh, wow. Oh, awesome. Okay. Great, great. I was really curious. You know, I thought you were running some parallel automation sitting in here or something like that. Okay. Yes. Yes, please. For this student, I would just like to ask, how would you say like inculcate this, what do you say, culture of testing amongst those who are looking to graduate and look for jobs? The culture of testing for the college students. Okay. You know, today they are going by what they are hearing about, you know, testing from testers, not even from non-testers. And what the testers themselves are saying is it's not good. Now, here is what we all need to do. Instead of speaking, we need to show a value. We need to demonstrate a value. Make them come towards it. Till we get to that point, we will be talking and we will keep hearing, you know, different things. I was, you know, there's this company called Infosys for some of you who don't know. You're from Infosys, okay. I was the trainer for, you know, testing part for the Infosys, you know, Mysore campus. So I was a consultant trainer and I was brought in and I was brought in to sell testing to these, you know, students. So one student asked me this question. Why is it that for mainframe, nobody's coming and selling that it's a good future? Java, nobody's selling that it's a good future. Why only for testers, they are coming and saying that there is a good future in testing? There's a good future in testing. And he said, the more people are trying to sell to me, the more nervous I'm getting about testing. There's something wrong in it, right? So I felt that, yeah, it's a great question that I've faced in my life. I said, wow, I'm just impressed with your question. And here's what I told him that, hey, I can show you what a few people are doing in the name of testing. If it excites you, then you come on board to do this. If it doesn't excite you, then you can go do something else in life. And then, you know, to them, it's like this. Even in, even in my company, I tell people the first few years, just experience things. Don't frame opinions, don't frame biases. Anything you do is helpful to your career in the long run. So you gotta be open to doing things and not conclude in life. The earlier you conclude about things, the more bigger mistakes you're likely to do. This is a message that has to pass on to the people with no gray hair so that when they gray, they gray more gracefully. Right, yeah, yes. Yeah. Why is the motivation there actually encourage you to coach people for free? Especially you're trying to make sure you travel around India at different stage. I'm just curious about this part. Okay, why do I coach testers for free? Okay, two reasons. One is that's not the way I wanna make money. You know, the second thing is that I know a lot of passionate testers who in some organizations, they don't have a budget for the training. And I don't want to prevent those people from actually coming. And then in my workshops, I get some of the tools tested by them. So we are exchanging value. So they are helping me test the tools that I am building and I am helping them learn the product owner perspective. So since there is an exchange of a value, I don't want to charge. Now, there is a charge there because we conduct these things in the hotels and such places, they pay for their own meal but nothing that I want out of it. So basically, logistic part. I mean, basically- The logistics is what they pay for themselves, the food especially. And my biggest motivation is this, that if, as I said, if I die without seeing the testing space, be the same way, I will not rest in peace. So this is my attempt. At least at that time, I can see what's a half rest in peace saying that, I did put in some effort. It didn't work out, but that's a different story. So my motivation, my larger motivation is to see things change. And for that, whatever needs to be done is what I'm trying to do. Okay, that's fantastic. I'm just curious about your wife's weather complain you a lot, like because of putting the priority as testing at first. I mean, rather than- Yeah, yeah, my wife, right? Yeah, absolutely. My wife is, here's an interesting thing that happened. So when she passed out of college, she attended a testing, some class somewhere, and she thought that this is the most horrible thing to be in based on the way that she was coached. And then when I got married, and then we were once, only once I spoke about testing after that, no. And she said, this is what, and then I tried to explain to her, that's not testing, this is what testing is. And we had our first fight that day. So I decided, not gonna talk about, you know, testing to her, and we have been living peacefully together forever after. Yeah, okay. Thanks for answer. Yeah. Bagasura, yeah. Yes, we are building an iOS version. Yeah, we are actually building an iOS version, and by about the end of October, it should go live. It's there only for Android right now. Oh yeah. Yeah. Right now I'm using it on iOS. Okay, yeah. Yeah. Yeah, it's gonna be there for the iOS and the web as well. Yeah, yeah, web as well. Yeah. Okay. Yeah. Do you intend to write a book? Do I intend to write a book? I've written a lot of books, never published it. Very true. Right now I'm writing a book called, you know, Buddha in Testing. And the reason why I'm writing this book is, you know, today I feel one thing that's missing for people in actually testing is the peace. So we are continuously disturbed by a lot of things, a lot of confusion. So there are a lot of testing textbooks, but there is no book which says how to be peaceful amid chaos for testers. So that's what I'm trying to write about. I am, you know, midway through this. And I hope, you know, if I complete it and if I feel good about it, I will publish it. Okay, thank you. Yeah. Very one question. Yeah. So back in the waterfall days, right? Yeah. There are a lot of testing processes that what they find right from the test planning phase to the execution to the closure and so on. Yeah. These processes are now being redefined in agile space. Yeah. What are your thoughts on all these processes? Are they necessary or are they just some waste of time? Okay. I don't think that any of the strategy or plan is going away. The documentation of that has gone away in some form. A lot of the strategy planning, the test design is happening here and this has become a black box for people. If it's in a document, they can see. If it's something is happening inside your head, they can't scan your, you know, that what's their technology is not yet there. Is he really thinking about, you know, test design or he's thinking about something else that is not there. So till that comes, it's become a black box and people are trying to do a lot of this in the head. So it is happening. It is what's a necessary. It is essential. There is no doubt about it, but it is not happening the way it used to happen. There were some benefits of that. There were some drawbacks of that, but people wiping something off completely is a price that they are continuing to pay for that. So you'd have all heard of what's a tech debt, right? Massive tech debt I see in a lot of companies. Oh my goodness. I think there is another 40 years of backlog that we can just simply live upon without doing anything new. That's really the way I feel that there's so many things to fix based on what we have done that we have a long career just to fix the backlogs. So there is a high tech debt that these people are paying. Now, we all go through this cycle as an industry. So to a lot of veterans, they were not at all surprised by agile because they were like, isn't this how we used to build software long ago? Now, people gave it a brand name, people sold it very well, people evangelized it very well and all of those things happened. So we will go through this cycle that people think, oh, that's not important and then people will come to think that's important. So even yesterday at the conference, somebody was asking about, are there any test data generator tools? I'm like, oh my God, there's so many, but still this question keeps coming up, right? So those are the problems that we are trying to fix. So one of the things in the tools category that we are trying to launch is to say, visualizing tools, we want to be able to mimic the app store. And in the app store, like how there is categories, we have a test data as one category, a test visualization as one category and all of this stuff. And we want to ask you, in which of these areas can you contribute the tool? So that is going to influence the world is what I'd like to believe. So as a bottom line to your question, is it essential? Everybody knows it is, but we are actually bypassing things that we right now think it's okay to bypass, but that bypass comes at a price and that price comes later, not right now. So people live with it till they are actually pushed to pay the price. Yeah, okay, yes. We have seen from many decades, we are writing test cases for each and everything. And in last couple of years, I think everyone has started promoting mind maps instead of test cases. So I want to know what value mind map adds instead of test cases and how helpful are those when a new testers join our team? Okay, so beat Excel or beat mind maps, we have to know what are we trying to accomplish. I've seen extremely good test case documentation and extremely poor mind maps. Mind maps are certainly helpful like the one that I actually showed. It helps in terms of, as long as you're concise, it really helps. But if you're trying to elaborate too much into a mind map, then the purpose of the mind map is actually defeated. The mind map helps in this way that I can tell you how I've used it. I've used it as a documentation, test status also, and the test reporting as well. So it's not about the tool, it's about how you learn to use the tool and how many different ways you apply the tool to solve the problems that you're trying to apply. Right, okay. Great. Guys, I'm sorry. So this will be the last question. Yeah. I charge after that. Yes, just kidding. Yeah. You mean to say about the security space? Okay, security and the performance and all that stuff, okay. Yesterday, one of the, I was having this conversation with one of the tester and then they said, oh, there's a great scope for security testing companies in Singapore. I asked like, wow, how? They said, sometimes the government wants a certain certificate and there's an agency which will run a tool and say these vulnerabilities, go fix it. So there are two kinds of, security folks that I've actually seen, okay. Those who run these tools and give a report, and those who try to think like a hacker, and who try to mimic like a hacker, and all of that stuff. Now, there is these kind of roles don't have a continuous role in any company. They don't have a continuous role. Unless, unless the company wants a culture of secure coding, where they want a person to look at the code, every line of code that's written and to assess whether it's secure or not. There you have a full-time work on that front. But otherwise, these kind of, what's a skill sets, come in and you would have to establish yourself. You have to establish a name for yourself or become a group of people who are fond of doing this, and that's where the value can come out. So largely, although I've seen across the companies, the security part is outsourced to a specialist group. So, and so was actually performance as well. So I was talking about some of the IT services, you know, companies, and I asked them, what's your challenge? And they said that keeping the performance testers actively engaged throughout is a challenge. So these kind of, you know, what's a skill sets, need a certain different path. Now, the good news is, it has not been corrupted too much as much as functional testing has been corrupted. Right? So, they're already in a certain greener field. But, there is, even there, there is a lot of shallow thinking. You know, a bunch of people learn, what's a SQL injection and URL editing and all of that stuff and they think that they're a security tester. They learn about it, but they don't go deeper beyond that front. So I would say that some of this is, is also applicable over to them, that the deep thinking part and all of that stuff. But that's a different, you know, what's a tangent overall. And that's what my opinion is. And Rahul Verma, if you follow Rahul Verma, he is a specialist at it and he does a lot of workshops around the security testing. So he is the right person, you know, to talk about. And someday I hope Rahul Verma comes to Singapore and you hear Rahul Verma's version of the same talk. That'll be interesting. Yeah, okay? Yeah. The last but one question, okay. Yeah. So, how do you see future of automation testing? Like I am a functional tester since seven years now. I do various kind of testing, web, API, mobile. Yeah. But the problem is whenever I am looking for a new job, everywhere it's written, they need automation tester, not completely manual. So this is a problem with manual testers nowadays and how do you see it in future, coming future? Will automation testers completely replace functional testers or how it will be? So that we can prepare ourselves for the coming future. Okay. So, you're, you're, where you're right is that there seems to be a lot of opportunities around automation and less so for, less so. I won't say they're not there. Okay, less so. Here is one great advice my mentor gave me long ago. Saying if you look at a JD and feel like you don't have those skills, there could be two things that could be happening. A, you could be right or you could be applying to the wrong job. Okay. Now we look around and we see all of these jobs and we are tempted to apply to those jobs while they may not be the relevant jobs for us. Now, yes. You know, here is the way I look at it. There's a, there's a hands-on, you know, tester. Then there's somebody who can write automation scripts. On top of that is somebody who can build automation frameworks. On top of that are people who can build tools. And on top of that are the product developers. Even in that, there are certain, you know, layers like this. So I see a lot of people wanting to move from being a hands-on tester to a script writer, from a script writer to a framework developer, from a framework developer to a tool developer. This is a path some people are taking. Now here is what my piece of understanding is. There are two clear roles that I'm seeing for the testers. If you are code savvy, become a tool developer within the testing space. If you're not code savvy, don't force it upon yourself. Choose to specialize in a certain domain or an industry or become a general functional, you know, specialist. Look at the complex word, general functional specialist. Right? I'm gonna tell you what it means. So what's it today? I've been actively studying general systems thinking. The general systems thinking helps me learn what I need to learn. And this has made me not feel intimidated by any technology, any domain. And I have a, I have a meta layer of learning so I can quickly demonstrate value irrespective of what actually domain I go. So this is what I meant by the general functional, you know, specialist. You specialize in being, you know, generalized, right? So to me, either you become super business savvy or you become super tech savvy but still need to have a layer of the business. This are the two. Now all the testers who are facing problem are in between this. I'm neither too good a developer nor too good a tester. This being in the middle is like, is like being in the middle of the sandwich. Nobody likes it, right? So that's what I would say that you ask yourself, where is your inclination? If you wanna become a good programmer, then that's the focus. Don't apply for jobs. You know, one to two years focus on building that and improving that layer of the skill. Then the jobs come to you. If you know what's, otherwise, you're trying to fit yourself in the market and that's a forever game. You'll have to keep trying to fit yourself in the market. So please ask yourself, what do you more suit for? Do you suit to be a business savvy? And that is about the domain and functional, what's the understanding and the specializing part of it? Or do you fit in the tech aspect of it? But never in between. The techno functional managers are the ones who've been replaced quite a lot, I think so, right? So please do pick what is it that actually suits you. Okay, with that I think the time's up and thank you very much. Thanks a lot. Thank you. Okay, for it. I really appreciate the time that each one of you took. And I'm gonna be here for some time. So for those of you whose spouse is as kind as mine and you wanna stay and ask some more questions, I'm here for a while. Okay, bye. Thank you.