 Welcome again, everyone, to the APM Light Conference. Without too much of a due, I will hand it over to Marat. I'm really, really glad that she's able to join us here and talk about the many hats to make a tester. What a brilliant topic. Thank you, Marat, and over to you. Thank you. It's great to be here. So I was thinking what would make sense to talk about in APM Conference because when I looked at the conference programs, like, oh, I want to join that conference. But all of the conference program is kind of speaking to just one part of all the interests that I have as someone who is doing testing. It's speaking to the part around the tool and using the tool to solve whatever problems we have in the test automation space. But a lot of times, especially looking at things right now in my team, well, my team isn't doing mobile automation, but we are definitely doing automation. Some of the expectations that we are managing in the team are not just about kind of, you know, creating that automation and solving the technical problems, but there's also other things around it. So I wanted to kind of address the expectations of what does it mean to be a tester or to work within the testing space and give you an overview into the types of things that are... I'm having a conversation on this in my current organization now. So first of all, if you think of yourself, you know, at some point you join an organization, you join a project and they give you a role. They might call you a developer, they might call you a tester, they might call you a product owner, but kind of the roles that I have in mind in this case are the ones that are working with hands-on work towards delivering software, contributing in any of the various roles around software. And regardless of what the role that we have there is, well, it might be a tester role, but we're probably expected to do some testing. If we are expected to do some testing, they're probably going to give us some kind of a test environment in the case of things around Appium. It's probably going to be some kind of mobile application form. Hopefully someone has either already set it up or they can give it us to as a service or they are going to give it to us as a kind of like the first task we had is to set up some kind of a mini environment in which we can do the testing we're going to do. Hopefully they don't just give us the devices, but they also give us kind of the tools or we are just going to go and get the tools because all of the things around testing nowadays come from the fact that we are using automation tools, both for robotic process automation. We might do that even in the mobile space, but we're definitely doing that in the web space and Appium is kind of a nice tool in that space, so it's an option to work across various different platforms and user interface technologies. So we're giving those tools, we have some knowledge, we have some information, maybe it's already being built, maybe we have already a framework or maybe it's kind of like an empty slate that we get start to start with. So we know that there will be these tools but we need to start drawing from our own experiences or maybe even collecting the experiences or organization that hasn't done it before. But this is a typical thing we get. We also usually get, this is a conversation I've had with many, many testers in the last two weeks, we get some kind of an expectation of how quick we are. I've been looking at numbers of pool requests in the last few days and I have an expectation that if I have a software developer who is focusing on mostly the code and not doing much of the other work around quality, two pool requests a month sounds like a small amount of results for four full weeks or 40 hours of work. And I don't know what the right number is but really small numbers make me curious. So kind of expecting some kind of schedule and expecting some kind of progress to be made in a reasonably short amount or chunk of time. So that's probably going to be given to you as well. Some kind of an expectation on how quickly you're going to be contributing and how often you keep on contributing and how you continuously taking things forward, whether it's radiators or other mechanisms, that's still going to be an expectation. And you're probably also going to be given some colleagues. Some of the colleagues will do exactly the same thing as you will do. So if you were hired as a tester in that organization, there might be other testers in the organization as well. But there's also going to be other roles and those other roles will also be taking part in testing in whatever agreement, shared agreement that you create in that team. So talking to the other people, working with them and making something useful for the whole of you is going to be part of the work you do. So as an expectation, as an outcome, you're probably going to be providing well, some kind of list of problems, information of what works, what doesn't, information of what's been implemented, what we could still be adding, having those conversations around that information, some test automation, which I think of as the better and the more modern way of doing any test documentation. I basically refuse to write much of other test documentation than automation. And I think sometimes the most important thing that you're expected to deliver is a better version of you that is better tomorrow than you were today and again better in a week than you were this week. So this kind of continuously growing self, but also making sure the others are not going backwards but rather forwards with you. So keeping everyone on board is a expectation. So this is kind of a simplified way of saying the work we're expected to do around testing, regardless of the role we end up being in, is something of this sort. And because it's not that complicated, you might have also heard that there's been this whole conversation in the community around this idea that the tester is, it's just a role in a team that anyone in the team could pick up. And I'm kind of here today to share on the idea that, yes, that's true, but there's still kind of, and there's more. So one of the things that happened in the last couple of months is that John shared on Twitter this nice based on responsibilities of engineering manager. And when I was looking at this picture, kind of like all the different hats that engineering manager has to carry. I was noticing that a lot of the labels he was using are kind of like from the designer space in a way, kind of thinking around how to build products and how to understand what kind of features are right for it. And the piece that I find myself contributing in, the piece of being a tester in these teams, it's kind of hidden there on that one line as one of those black little post-it notes. On the side of writing code, there's a thing called testing. So under the role of code and pixels. So probably, you know, you could explore this and try explaining in a way the role or the main roles of a tester. And that's exactly what I then did on the day following John's tweet. So I created a listing based on observations from the last year in the project that I'm currently working on, where I was trying to explain that we have five people we call system testers. And yet we have 10 other people we call developers in that team. And the five system testers can do all the testing, but we need to somehow figure out across the whole team of 15 people, how do we distribute the hats that we know the work that we consider to be testing. And I had given it already some kind of, like an outline, an earlier outline of sorts of things I was seeing people do, but I attached kind of these labels. I made them kind of more condensed and I attached them into a similar visual inspired by the work that John had done. And also I looked at four exemplary people from my team. You can imagine that the D4 there is someone who identifies completely as a developer. Developers do a lot of the test automation work in my current team, whereas then different kinds of testers actually still end up somehow picking up a little bit different kind of profile of work. So let's talk about the roles a little bit. So we are in Appium Light Conference. So we definitely need to start from the core of what the modern software testing I think looks like, which is that automation is not a thing we question. It exists, it should exist. The question is just how much today and how much more do we need to learn before we are on a sufficient level in our organizations. But every step forward is taking us that, you know, one day better mindset that should always be part of every activity that we're trying to do. So we'll definitely start from kind of, you know, the hats that come to you if you join that organization as a test automation developer type of a person, a tester with automation specialism. So we will definitely be expecting there to be code. Like you are going to be writing code and if there are no, you know, commits and pull requests into the version control, if you don't change anything, the test automation won't get any better. But the other part of what you're probably kind of on the first level expected to do is to contribute in the conversations around features in helping shape, how can they be more testable and what are they like so that you know what kind of cases, even the basic positive cases, which is only a small part of the things we need to test. What would that look like? You participate actively in those conversations. Definitely these roles are the forefront of it. The two other roles that I picked up are things where all of the test automation specialists that I work with in my current team can have challenges with. So I wanted to emphasize that to you today. The on-caller is this idea of a role that you are always expected to be available for your team within the working hours in the sense that when there is a change coming to your system, you will also make changes to the test automation system that match whatever is going on in the system under test that you are trying to do. So you're kind of like trying to make sure that if something breaks today, you could be able to test with your pipeline designs or at least someone having a conversation in the team that this is now broken. Maybe we should be fixing it and it wasn't broken before. So kind of like that reaction, creating that service in the team. But also the other side of it, the designer hat is equally important. So it's not enough to just do the BDD positive. This is how we show that it can work. But we also need to do what we called in the past and call it negative testing. So trying out various different things that you shouldn't be doing, but also trying out combinations of all kinds of features so that you can let the bugs kind of, you know, reveal themselves out of the software. We're expected to design the ideas that make all the relevant issues somehow surface. Then on the other roles or the other hats that you'd have as a tester. Well, probably building that pipeline and keeping it up to date. I hope it isn't as painful and as effort worthy work for all of you as it has been in my team in the last year. In the last month, we've been measuring how many days out of our month we had the test automation radiator green. And that was four out of 22 days. So not a very high percentage. But four out of 22 is much better than the one out of 22 that we saw in the previous month. So definitely we are making progress in that. But it also means that the pipeline maintenance, keeping kind of things up to date. It is actually a fairly large amount of work. And some of my colleagues in testing or test automation said that when you've invested in the test automation, you can expect that it's going to take half of your next year in just keeping it alive. So a separate hat for that is a good idea in the sense that it helps talking to the managers about the expectations of what you will be doing as a tester. If you have that device farm or like right now I have a farm of devices, IOT devices, which are some kind of mobile devices but not the common purpose ones. We're doing embedded software. It's probably going to be a huge amount of work to set up an environment of all of those devices that you can run. And we do that definitely for automation purposes. Set up remote abilities to connect. And also then, of course, you need to think in future like what would it take to make our test automation better? Then there's this idea or area of the things that a test manager used to do. I put this label collection here as a reminder that this is work that I find myself doing but I also find myself to be the only tester remaining in my organization who does this. So the future of these labels, even though they are test oriented labels, is that the managers, the product owners learn to think in terms of testing as well. But unless you teach them and unless you negotiate with them, unless you help them understand these things, they won't be able to help and contribute to these areas. But it might be something that is also expected of you. And then finally, my three favorite things here are the hats. The product historian, I find that that's a role that some people very naturally take who have been testers in the past. So when you ask about how did we decide on having this feature like this or how do we decide having this problem out there, they can give you the exact jury ticket that shows that we decided this is okay. And they can give you the documentation that is 157 pages long. This is from a couple of weeks ago at my office. And they can point out that it's on page 37 on the second half at this point where you want to read for that one piece of information you were looking for. Parafunctionalist as a role or as a hat, it's reminding us that it's not just a functional stuff. So we need to figure out security, reliability, performance, usability, at least those four. In addition, maybe you could add testability there as well. But I would kind of like to see it as part of the other roles. And if you are technically inclined, nothing says that you should stick to only shaping system automation. You could just be participating in the unit level, development work, and also help make sure that we do a good job on that area. So all of this together, it's basically being that the tester label, the one role that we don't need to put on one person, we need to actually explode it. You might find your own labels in your own organization of these same things, but it might be that across your team, you will figure out who of your team will take which of these. And even if all of these are things of testing, they might not be things that the person with a tester or test automation label in your team does. So instead of thinking free amigos, the business person, the developer and the tester, I suggest you would think in terms of, for example, the bonus six thinking hats approaching the problem from six different perspectives. Or if you want to make it a little simpler, make sure you have two pairs of eyes. And the two pairs of eyes is basically your way of saying that never leave your colleague alone with something as important as making software for multiple users to use and enjoy. Finally, I wanted to conclude with the idea that this is what I call job crafting. You are making the job you have, the job you want, but to be a really good professional in whatever you are doing in software development. I believe you need to make it visible which bits and pieces of the vague hat or the vague role of testers you are going to be taken and what do you expect of the other people on you. And if you really intend and others see what you are doing, they might be picking up the other pieces or you might be needing to say those out loud. So that's the message that I had for you today. And I hope you have a time testing and enjoy your conference in the Appian space. All right. Thank you, Marat. That was brilliant. I think you finished dot on time. So greatly appreciate that. And what a lovely message to leave the audience with, you know, take the job and make it what you really want to make out of it, like make it into what you love, actually. And so that's great. If there are any questions, we could take some questions now. If you want to leave the questions in the Q&A section, please, we can take some questions. Alternatively, Marat is also going to be available in the Hangout section. So on your screens, you will see on the left-hand side in the menu, you would see Hangout. So you can go there and you'd find a table with Marat's name on it. And you can go join the table at any point in time up to eight people can have a live video face-to-face discussion and rest of folks can watch the video without necessarily having to join the table. And we're hoping that this will allow you to peep in, see a conversation and decide if it's interesting you want to join in or not, you know, check before you commit kind of a situation. So if there are any questions, I see there is one question. Okay, I have an anonymous attendee, a question from an anonymous attendee. What is the D1, D2, D3 and D4 refers to? Being in your slides, you had the D1, D2, D3, D4. It's a developer one, developer two, developer three and developer four. I have a big belief that all testers are developers and I would rather call us all developers than separate us anymore into the rows silos. Okay, cool. Any other questions? All right. I don't see any other questions for now, but I think we can have folks join the table and have face-to-face discussion with Marat over there. Again, I want to thank all the folks for joining in this session. Greatly appreciate that. Also would like to thank all the volunteers behind the scene who have made this possible without whom this conference wouldn't be possible. And last but not the least, the sponsors who helped us put this conference together. So greatly want to appreciate them as well. If during the, there are 10 minutes breaks between the sessions for you to get out of one session and join another session. You could also take time to visit the sponsor booth. So if you click on the left on the sponsor section, you would be able to see all the sponsor logos. And then if you click on that, you get to visit the sponsor booths. They have some interesting goodies over there. So I would appreciate if you can visit the sponsors, see what they're up to as well. So without too much delay, I will try and close this session and have Marat kind of continue to the Hangout session. So folks can meet her there. Thank you again so much. Thanks everyone. Take care. Bye.