 Welcome. I'd like to start with a simple question. Who of you wrote some code? Please raise your hand. For those watching us online, welcome. If you are here, you would see every single hand up. And silly me, yes, it's Defconn, right? Or all coders will understand it. Now let me change the question slightly. Who of you intentionally wrote code which doesn't do what you want it to do? And the word intentionally is important. And I don't mean hex. I don't mean some exploits. We have one. I guess you are a teacher. You wrote something. Yeah, you wrote something for your students. So it was intended so that it doesn't work. I have never met a developer who tries to write crappy code. But yet, here we are. A lot of crappy releases out there. A lot of customer bugs. What's going on? Where is the disconnect? Should we blame the testers? Ladies and gentlemen, welcome. My name is Michael Chadda. And this is my take on quality engineering mindset. And if we have time, I would like to look into testing breakdown structure to see some kind of questions and how to apply the QE mindset itself. We will talk about what QE mindset is not, what it is, and why it's important for the company to adopt. So let's start with what QE mindset is not. And I heard this more times than I would like to. It's rejecting responsibility. The I told you so mindset. You are a tester. You say, hey, this isn't right. Something is wrong there. But hey, it's not a priority to fix. Then you go to production. Something goes wrong. And you say, eh, I told you so. This is not what we want. We want collaboration. We don't want compromise. We want everyone to understand that quality is responsibility of everyone. And if you are not happy, if you see some risks which are there, don't stay silent. Narrow focus. And that is more true for some historical testing approaches where QE mindset is not about just writing tests, going through automation. It's about more. It's about the whole development lifecycle. Checklist mentality. You cannot blindly take standards and apply them to your situation. Every team is different. Every product service is different. And just ticking some boxes that might not be the priority which you currently need. You don't want to become a roadblock. You don't want the team to see you as someone who is holding us back, someone who is slowing the development down. I did a short survey with my friends and colleagues about what they think the QE mindset is. And all of these you see on the screen are part of the QE mindset. But I would like to touch some of these anyways and share some of the risks and limitations. So it's a mindset to deliver quality above else. Imagine a team writing an amazing product, something where quality is above else. They do everything properly. They have the best processes. It's the most robust service in the universe. And then they go to market 15 years after the competition. Desire for things to be always better than they are. While that's true continuous improvement is something we want, sometimes good enough is good enough. Passion for things to be perfect for the customer. And I would like to use a quote here. Don't let the perfect be the enemy of the good. And often we can have thousands of customers. And the perfect for one customer might not be the same what is perfect for another customer. Also, we might have a different vision of our product than what customers have. Attention to detail and critical thinking. This is a good one because we can apply it to the whole development lifecycle. And yes, it's a strong part of quality engineering mindset. But also, sometimes you don't need to go as deep. Sometimes you need to understand the big picture. Don't have a narrow focus. And the ability to understand and mitigate what can go wrong for a customer. We are back to our customers who sometimes don't know what they want. And yes, we want to predict what might go wrong. But quality engineering mindset is not just about our product. It's not just about our service. It's about our processes. It's about our automation. It's about our documentation. It's more. So how do we define quality? Users getting the intended value. But how can we verify that? Can we test our way to quality? Can we reach quality? And I would say no. I think it's similar to security, where you can test for known issues, known exploits. You can analyze where we are to what we know. But you can never say, hey, we reached security. You cannot breach us. And I see quality similarly. You cannot really reach quality. Talking about quality, I think it's important to touch types of quality anomalies. And to see that it really is a big picture, we are not limited to just bucks. We have functional problems, performance, security, usability, and many, many others. And in order to understand quality as a whole, it's crucial we focus on monitoring. You want to monitor not only your product, but you want to monitor your processes. You want to find where the bottlenecks are and how you can improve quality by focusing where the constraints are. Otherwise, your innovation will not be visible at all. With this slide, I don't want to go into details here, but you can see that software quality field is really, it has its own history. It's almost 80 years old. And we started with code inspections, with first formulation of beginnings of some guidelines, testing maturity models, benchmarks. And we had this agile manifesto revolution with Scrum and Kanban. And last 15 years, it's DevOps, machine learning, AI, and questions for everyone. Where is your team stuck in history? Are you still doing manual tests? Are you doing checklists? Or do you already have DevOps in place? Do you leverage machine learning and other types of automation and AI? And you have seen that the evolution is there. It's very visible. And I feel like it's important to mention evolution from QA, from quality assurance to quality engineering. And there are three main differences. In mindset, in role, in scope. For quality assurance, the mindset is really narrow. You focus on vulnerabilities, on verification, on writing automation. The role, it's usually done by a tester, or worst case, by PMs who are trying whether it works. And the scope is very limited. Whereas quality engineering is a mindset. It's something which should be adopted by everyone in the company. So the scope is the whole development lifecycle. And I would like to divert you a bit and talk about the primary objective of IT department. And maybe go even one level higher. What is the primary objective of business? Well, in most cases, to earn money. How do we earn money? We deliver value to customers. And in IT companies, usually, we try to deliver some products or services. And we would like to maximize our gains. And you can maximize gains by either limiting the costs or increasing the value, increasing the amount which you can deliver. And where limiting the costs has limit at zero, delivering the value, that goes only up. Well, not only up. But you want it to go up. There is no limit. So really, the focus of IT department should be to make sure that our developers are as efficient as possible. So that the roadblocks, not roadblocks, so that the constraints, the bottlenecks, are in development and not in our releases, not in our automation, not in our testing. And how can we achieve that? By implementing ongoing improvements, trying to make things automated better, faster, by making sure that quality is really shared between all the roles, and by focusing on fast loops, fast feedback, to prevent as soon as possible. Here we get to a definition. I came up with, and let me read it. It's a bit long. So quality engineering mindset is a proactive and holistic approach to software quality that permeates throughout an organization. It encompasses a set of attitudes, beliefs, and behaviors that prioritize and promote quality at every stage of the software development lifecycle. Did you notice something? Isn't it a bit vague? Isn't it a blank statement? When you share this definition with a team, they say, OK, and what? Like, why should we do anything? It's only common sense. And I thought about it for a long time and realized that it needs to be vague, because quality is not a solved problem. You cannot reach quality. You can just look for regressions, verify against the knowns, and check out some other anomalies. So why is it such a big deal? Why we can see in the history the evolution of quality? Well, it's important for business. Everyone understands that you need to deliver good quality to our customers, otherwise you will not be successful. And I don't want to go deep into each of these fields. We have a lot. Customer satisfaction, product quality, efficiency, productivity, collaboration, communication, et cetera, et cetera. It's a lot. So how can a tester make sure that you have quality in all of these? It's simple. Testors cannot. So that's why we evolved from quality assurance to quality engineering mindset. That's where the tester takes a role of an ambassador of quality and not someone who just writes tests. Testors are educating the whole team. And advocating for quality throughout the whole development lifecycle. And for testers, this slide is mostly for you, but others might find it interesting as well. We have some common pitfalls, and here's my take on this. We are under tremendous pressure. Features, features, features. That's all people want. We need to deliver features to customers. We need to deliver it fast. Ideally, yesterday, we don't have time for quality. What can we do about it? And I would argue that this approach already shows that you are not embedding quality in the development process. Because delivering a feature should already include the quality. You should bake the quality into all your processes based on your needs. If not, then it results in bad practices. You have some anti-patterns. You have hardening sprints. You have tech depth sprints, and the accumulation of QE backlog. Then the developer slips, the window for testing shrinks, and you know the drill. You go down with a downward spiral. And then you pay. The whole company pays. And I guess if you have been in this role, you met some of those pitfalls. Overtimes, missed deadlines, cutting corners. And yes, we are awesome. We can do that for one release, for two, for three. But it accumulates. It accumulates, and at some point, it will all crumble. So the answer, what we can do about it, what we can do about these symptoms of not having quality into the development lifecycle, it lies in the definition. Lies in the definition of QE mindset. The whole team needs to adopt quality. And together, we need to implement process of ongoing improvement. We need to focus on where it makes sense, where it matters. We need to pick our battles, and we need to find our constraints. How to do it? I apologize. I need to skip this one, because that would be another presentation, just this one part. But to shortly sum it up, it's a cultural shift. Everyone in the organization needs to buy in on quality. And together, you need to build a quality vision which makes sense for your team, for your product, for your service. And sometimes it might not be writing automation what you should focus on. Testing breakdown structure. It's something we need to do in order to find out what the quality vision is for the whole team. We need to ask questions, because quality is not a solved problem. And it's not about creating a checklist. It's really about collaborating, finding the right quality vision. And yes, even asking questions can be misused. But if we don't do that, we will never know what is it we want. Because it's not only about common sense. Yes, quality might be a common sense, but common sense is different for everyone. So the ability to articulate what the quality vision is is crucial. Some areas to ask questions about work-tracking tools and workflows. Usually, this is something you design before you start working on your product. And then sometimes it's forgotten. But it has its own risks. You can have public service. You can have public JIRA project. And you can leak information there. That is part of quality. It's important to think about the design, how we do things. Is it easy? Is it difficult? Is it efficient? Does it really cover reality? Every team evolves. And at some point, our tracking and processes, the tools we are using, they lose touch with reality. Documentation. And that's a good one. It's a love and hate relationship. When you are working on something which is well-documented, you love it. Because whatever you need, you will find it there. But someone needed to maintain it. Imagine a situation where your company is losing money every minute your service is down. And it's down because the main subject matter expert was abducted by aliens. And, well, yes, you can get second best person or the whole rest of the team and try to dig deeper, analyze what's going on. What can we do? We don't know because there is no documentation. And at these points, you tell yourself, I wish we spent 30 minutes on documenting this stuff. It would be so valuable. Process definition. And similar to workflows, usually you create a process so that it's clear how you develop your service. Everyone knows what they are supposed to do, what is their role in the process, where they can see the backlog, where is the input, where is the output. But even if you design the best process there is, I guarantee that in a year or two, it will be obsolete. Evolution is fast, IT is moving very fast, and we need to adapt. We need to focus on what gives us the most value, even from process perspective. And it depends on what the team needs, whether it's consistency, performance, speed, robustness. We should still keep in mind that this continuous improvement in processes will improve our developer's efficiency. And this will improve the value we get from our products, and this will improve our revenue. Testing. And once again, we don't have to go deep into this. This is the part of quality assurance, focus on what we should test, how we should test it, where we should test it, what makes sense for us. It will be different. It might be even different, service by service. But you still need to ask those questions. What makes sense to do what does not? Continuous integration. That's something we are all trying to achieve. It's modern. It's good. And if you compare it with humanity and our progress, usually we did the most progress when we were able to automate something. When something happens without us putting attention to it, whether it's water, electricity, or productization pipelines, how can we make sure that our CI stays on top of what we are doing without asking the right questions? Are we doing things manually? Can we automate the process? Can we make it easier? And this one is a bit tricky because if you create difficult CI, then yes, you need to maintain it. You need to make sure that your environments are stable. You need to make sure that your testing environment is similar to what you have in production so that you actually don't have some false positives, et cetera. But it still buys you time. And you can save dozens and dozens of hours by properly automating things, making sure that whatever you do, next time it will be better. And I mentioned some other areas like security, dependencies, definitions so that people are on the same page, performance optimization, code, maintainability. All of these, at some point in your product lifecycle, well, someone needs to say, this is what we want. This is what we don't want. Someone needs to decide. Someone needs to ask these questions to formulate the quality vision for the whole team so that everyone is on board with that. And the three main takeaways from the presentation, I would like you to know that quality engineering mindset is not just about testing. It's about cultural shift. It's about having everyone on board. And it's about baking quality in the whole development lifecycle. The second takeaway is there is no one-size-fits-all solution. Everything is different. Your requirements are different. What you know from the past might not apply in the future. So collaborate, communicate, implement the continuous improvements into your sprints and your quarterly plannings. And last but not least, we inherit the main purpose of our business. We try to make our company successful by trying to make our developers as efficient as possible. Thank you, everyone. That will be all for today. If you have any questions, now is the time. And I know the topic is a bit philosophical, not necessarily technical. And the questions might be hard to come by. But if you want to discuss anything, just let me know. When you get into the process, I'm ready. So we don't need to do that again. So the question was, if we identify our gaps, what can we do to make sure that once we close those gaps, they don't open somewhere else? And I would like to actually use something which I heard from a different presentation. And that was about agile integration. I believe it was Fernando who did the presentation. Apologies if I'm wrong. But the idea was that you cannot finish agile transformation. It's an ongoing process. You will never reach it. And the same way, you can never reach quality. So what you are looking for, what you are trying to implement, is really this process of ongoing improvements. Make sure that quality has place in your planning and in your capacity. Make sure that you are continuously evolving. Because the quality field, software quality field, will evolve as well. And your approaches at some point will be obsolete. So you cannot all you need is process of ongoing improvement. Thank you for the question. So the question was whether we can design team where development and quality are in balance, where this quality engineering mindset is in place. I would say so, but it's difficult. And since you cannot reach quality and everyone has their own specialization, first you need buying of everyone. You need buying of the whole company. You need to shift your mindset. You need others to understand that we really need to talk about quality at every stage and properly prioritize. So it's a lot about communication, about soft skills, about building quality vision with every stakeholder which has some kind of role in the development lifecycle. Without this communication and buying from everyone, you will just not be successful. So if you are a quality engineer, you don't have buying, you either will become a roadblock or you will get crazy. Or what you can do and what would be my recommendation is pick one small thing. Focus or find the constraint. For this, value stream mapping is a great tool. Find what is it that slows down your developers and work on it, improve it. If it's good, it will be visible. If it will be visible, it will be adopted by others. And this way, slowly but surely, you will incrementally get better.