 Welcome everyone to the session is quality really everyone's responsibility the quality accountability conundrum by Deepak. Thank you. Hello everyone. My name is Deepak and today I'm going to present is quality really everyone's responsibility. There is this quality accountability conundrum which we regularly face as testers, so I'll throw some light on it. About me, I spent 2007 to 2012 five years in PTC and then around eight and a half years in Red Hat. I'm still working in Red Hat as a quality engineering manager. I'm also running a ministry of testing QE meter for Pune City. This is about me. I love psychology. I'm a bit of a psychology buff and I also love some comedy. I do memes and everything. So you'll probably have you'll probably notice that going forward in this. All right. So the thing I like to start with is that ambiguity responsibility a virgin is something which is very intrinsic to human nature. So for an example, when you buy a pack of potato wafers from outside, you see this sign light right this sign keep your city clean keeping our city clean is a universal truth. Right. Everyone should keep their city clean, but it and it is such a statement just like quality is everyone's responsibility that it does not mean that each one of us is intrinsically inclined to keep our city clean. Right. Unless that's why we have these signs that when you when you eat a pack of chips or wafers you have to throw that pack into a trash can and not throw that in a road. So they are clearly they clearly know that we won't be throwing the trash into a trash can. That's why that's why these symbols are there. And in an alternate example, if you remember back in the days we had this Selenium users Google group. Right. So what happened was back in, I think 2010 when somebody used to send a send a problem to Selenium users Google group. Who's responsibility do you think it was to reply to that person. Right. Nobody's it was everyone's responsibility who were part of that emailing list but eventually if you did not get if you sent out a request to that group and you did not get an answer for maybe two weeks then nobody was actually responsible for that right. So it was not something that you could actually expect people to respond because there was no responsibility there. They who who body whoever was responding to your questions was doing doing in good faith and trying to help you out but there is there is no concept of responsibility when when the whole responsibility is laid down on a group and there is no accountability principle. Nobody is going to hold me accountable for not responding to someone's request on Selenium user Google group or or any other maybe Stack Overflow or any other thing right. So the first thing we learn is that we as humans try to avoid responsibility as because it is very natural and evolutionary so we cannot do anything about it. The second thing is about quality when we talk about quality in a broader context of things. Quality is we have been interchangeingly using quality with testing even my job title is quality manager right but it's not actually quality of the software what we do is just a testing of the software not the overall quality quality is a huge term right. So Jerry Weinberg in back in I think 1940s gave the definition of quality as fit for use or something which provides value to someone. And that definition was then extended by other testing experts as value to someone who matters right this is the well this is the definition of quality in a software context. It's not it's not something which a test engineer can wholly and solely own right it has to be divided across the organization not just the engineering teams but across the organization. So in their book called people where I think Tori Moore mentioned mentioned that and remarked that quality might be equal to chocolate sauce on a Sunday right and it is totally stakeholder driven. So if your customers are demanding X amount of chocolate sauce you provide them X amount of chocolate sauce and if some customers like more chocolate sauce you give them more chocolate sauce and and eventually increase the cost as well. So if it was if it was not the case if it was not the case so I will give you a simple example of quality not related to success. So if you look at lot of lot of movies with glaring portholes that bad acting bad music and everything is still very successful but what can explain that our movies. If we think of movies and an analogy of softwares right our movies with bad acting bad story lines and everything bad about them every technical aspect is totally ridiculous and then still they go ahead and make. Millions at the box office why is that and what about how would you explain India's top selling cars right the Maruti cars. So if if you if you take any global crash test they they just fail spectacularly there and then if you look at the top 10 selling cars in India you will find top five of those spots are held by Maruti cars. So if I was let's say if Maruti also was a software and I was a testing engineer I'll punch its bonnet and tell my project manager that I don't think you can ship it right it's it just 0.2 mm of steel. It would be very dangerous for the users right I'll I'll try to become an obstructive tester not not getting that thing released into market which my my company already knows that is already a successful model right. They don't they don't need to test more quality into that product they know it is a successful product. So the point I'm trying to make is that overall quality of a product including software depends on lot of factors one is pricing right. What if you make a great software which is which has great accessibility very minute bugs and you have done almost all great things as a testing team but your company decides that they'll price it higher than their competitors and then it does not become so successful. What about your sales engineers and other marketing people they they did a poor job and now your software which was a great software does not work. What about after sale support consumption models what if your company is trying to sell a software as a five year five year. License model and not a very small bite size consumption model right there are multiple factors we decide the success and actually the quality of the software rather than testing. So the point I'm trying to make is that as testers we should not think that we are the safety net around the software and its quality. Okay so what did we learn so far a responsibility a virgin right members of a team are not instinctively inclined for quality accountability they are not nobody is not just software teams anybody in this world. If you tell me that this is a village or a city and its citizens are totally inclined as a group they are totally inclined and accountable I'll I'll I'll not believe in that. The second thing which we learned is that quality is relative great testing is not does not mean great quality because everything is not under a testers control your softwares pricing models and after sale support and lots of other stuff. The third thing is software development which most of us do right most of us do is not science 90% of the software which we create is not even high ticket is social software development. Sitting in a garage and creating Linux is high tech software development but using that Linux to write a Python script is not. Creating Kubernetes or Ansible is high tech but using Ansible playbooks to spawn a VM is not that is that is you are you are just making your life easy using existing tools and high tech technology. But to make sure that you are helping a business by providing them some functionality or features right. So based on based on all of this the burning question is in in burning question as you know what I mean words if quality is relative and value to someone how can tested find that out right. So we we think about shift left testing right we want to start early as early as people are trying to gather requirements and everything but is that is that the actual early we want to start or is can we go further left. So I call this I call this I want to take this platform to announce that there is a way to go further left. So you just don't shift left you shift extreme left. So if you are a flat or that you will probably fall down off the edge of the so left. So shift extreme left means you go to a point where you know that why on the earth is this company is my organization putting valuable resources and money and so much effort into creating a software are we replacing a human. Let's think about this platform right this platform on which we are doing this Selenium conference today. I think I haven't seen a platform like this ever before right so a group of people created this software for us right what were they doing. Were they replacing a monolithic software no were they replacing a legacy app no was it a completely new blue ocean idea. Yes probably I haven't seen because I haven't heard about any other conference platform like this and were they replacing a human. Yes because earlier in 2016 and 18 I used to go to a Mahesh lunch home in Bangalore and have lunch today I have to I have to cook my own lunch while using this software right. So yes we replaced human this software has replaced all human interaction in a physical way to a virtual way. But but that is the motive right you understand the strategy of the company who build this software. So you have to if you want to go extreme left you have to understand the strategy at organization level. Why is our company putting so much money and effort into this software at our department level if I am I am from an engineering department or maybe an R&D department. What is my department strategy where does this strategy fit into the my organization strategy. And what is my team strategy the very micro level strategy of my team and what is expected from my team. And once you start doing this because each one of you let's say you are in this. Three to five or three to seven years of experience doing testing and doing test automation solving x path versus CSS problems but five years down the line it's not going to remain the same right you have to grow in your roles and each one of you has to probably Probably go into more so go into to solve bigger problems than x path versus CSS right and the most amazing by product of understanding your company strategy and aligning your testing that strategy is that you automatically become very very sticky to the company's culture and companies growth that means your growth as well. So OCR is one model so I won't go into detail but I think as individuals OCR is something which is used in most of the organizations as a strategy communication versus focus tool. So think about try to find out what your OCRs are for your team for your department and for your company as well. And this is okay okay so this is the accountability model I'm talking about so as testers I I encourage you all to not be the obstructionist testers right you're not here to break the software in those technical terms. You are here to help software release on time by building a context of what quality means for your company and your customers right so this grid model is something which which I like which I like you all to read and probably implement at your end. So the summary what we learned today is that go to the root of the purpose of building a software right extreme left as I said. Build context to quality as I said testing is not equal to quality you need to you need to know where the fine line between quality and testing lies. If you are crossing that line then you will be termed as as a tester who is very obstructionist and does not help the team release the software on time right. As per the as per the grid model your job is just to recommend what can be the better quality measures for your software but not fight for them right you cannot fight for those. See it is it is you must have read in blogs and books it is a very common almost a conventional wisdom right now that a tester needs to be very persistent and needs to fight for its bugs and stuff like that. I think that is that is just ridiculous it should not be like that in a in a in an agile team. We should not think of ourselves as someone who is actually there to break the software or to stop the release because it does not meet my personal getting criteria right. So that you should align yourself to your team's purpose and not follow your separate purpose of quality. So the shared quality vision of your team including you must match what's the quality vision of your company is that is that is the golden golden area in which you want to stay as a tester. Thank you once again Deepak for your time and your wisdom with us.