 So let's start folks. I'll start off with a disclaimer. This is probably going to be the least of your technical sessions amongst all the sessions that you've been attending today and tomorrow. But I think Navigla is a very important topic for us as software testers. So firstly, to that extent, I'm very thankful to the conference committee for having chosen this presentation. Because I think it's all about prioritization at the end of the day, whatever we do and especially for us as software testers. So we're going to basically look at what really is prioritization. What are the varied styles of prioritization? We may all think, hey, what's new about prioritization? We all know prioritization. We do it in all walks of our life. But interestingly, there are varied styles of prioritization. So we look at some of those styles because what works for one is not what is going to work for the other. What works for me today is not what's going to work for me say a few years down the line. So we look at a few prioritization styles. We look at the scope areas of prioritization in software testing specifically, and essentially walk away with some actionable items on how we can prioritize to be better software testers. So that's simple enough in terms of the agenda. Typically, I like to start it off with a story or end it with a story or some kind of an illustration. So that's what I'm going to start it off here with. So Joe buys a brand new Lexus car. He wants to show off his luxury car to his office colleagues. So he drives it into his office. As he gets out of the car, there is a truck that comes roaring past and slams into Joe's car door. So Joe is obviously very, very furious. He immediately calls the cops. Cops come in in disbelief. They're in complete denial. They come in shaking their head saying Joe is really infuriated about the car's door which has been slammed into. Obviously, for the right reasons, Joe is extremely unhappy. But why are the cops really furious with Joe? Least has Joe realized that in the process, his hand was also slammed into, but the guy did not realize that. And as soon as the cops said that, oh my God, is it my left hand? My Rolex watch has also gone away. So priorities are very, very different for all of us, right? So in this case, Joe's priorities were being completely materialistic. He didn't care for his left hand which was slammed into, but it was his Rolex watch that was his priority. So starting off with the message that it's all about priorities at the end of the day. We're all driven by priorities. So let's start off with a couple of simple codes, right? So Dalin Oaks is a religious leader. He talks about how desires drive our priorities. Priorities drive our choices, and choices drive our actions. End of the day, our actions are all driven by our priorities. And this is something which Mahatma Gandhi had mentioned back then itself, that actions express priorities. So I believe at the end of the day, no one here is busy. If someone were to get up here and say, I'm extremely busy, I think we're just not prioritizing things well on our plate. So skill and capability is one, but on top of it, prioritization is very, very important. So a quick definition of what prioritization is before we look at some of these styles. So any quick takers, anyone wants to quickly define priorities in literally like two words. What is prioritization? It's like a word we all know, kids know. All right, did you look up online? I'm just kidding, awesome. So as a principle, it's basically doing first things first. And as a process, it basically means you stack rank a group of items based on their urgency and importance. So there are two things I want you all to walk away with at the end of the presentation, right? So how do you prioritize? Basically, look at what is the urgency of a certain item, what is the importance of a certain item. And when I say urgency, it is timeline-based, and when it is importance, it is impact-based. So there's a huge difference between the two. If we understand that, that is the first step towards prioritizing whatever we do. So let's take a very, very simple example. Again, a non-technical example. Let's say our utility bills, right? Our electricity bills, water bill, whatever it is, it is due as of today. So it's an urgent task where I've got to pay it by today. I'm driven by a certain deadline out here. So it's an urgent task. But if you ask me, is it important? Probably not, you know, what if I don't pay it today? I pay it tomorrow with a penalty, as simple as that. But the same thing, if I wait for another 30 days into the penalty period, and I've not paid my utility bills still, and at that point, I get a notice saying, by today, if you don't pay it, your connection is gonna be taken off. Then it becomes important as well, because there is an impact to it. So I understand, anytime we do a prioritization, do this kind of a basic difference first, because some tasks are gonna be urgent, but not important, important, but not urgent, both important and urgent, neither important nor urgent. Use this as a basic matrix when you do any kind of prioritization in whatever activities we do. Let's move on, right? Some of the core prioritization techniques. You may wonder, I've taken examples of all women leaders out here, but I found their techniques to be very, very exciting and interesting, that's why I picked. The first one by Indra Nui, she is the chairman of the PepsiCo group of industries that most of us obviously know her. By the way, do go watch her videos, great sense of humor, excellent points that she's got to convey. So she says her style of prioritization is scoping mechanism, and she gives a very interesting example as well. So she says, growing up when my kids were young and I was already an exec at that point in time, it was very difficult for me to prioritize my personal and professional life. And every Wednesday morning at her kid's school, there used to be a coffee meeting where the moms had to attend. And how am I gonna be able to attend those meetings as a working mom? The first few times I was extremely guilty that I was not able to attend, and the kid would come back home saying all these moms were there, but you weren't there. So initial few times while she was guilty, later on she built a coping mechanism where before the daughter comes to her, she would have collected data from the school saying which other moms did not come for the meeting. So when the daughter says these were the moms that came, Indra Nui would go, these were the other moms that did not come, did you know that? So that is one style, coping mechanism is one style, so see if this would work for you at your workplace. The second one, optimization. We all optimize, right? As software testers, optimization of our test matrices, test coverage, compatibility is basically driven on optimization. So this, yes, is a standard mechanism. We all use as testers. Third one, procrastination. So Julie Larson Green, she heads the customer experience division of Microsoft. She says procrastination is my style. I push things out until the very end, until they become both urgent and important. Now I'm not saying again that's right or wrong. I personally am not a person who burns midnight oil, but looks like that works for some people. So procrastination is one such style. A few other styles are, you know, easiest first, quickest first, hardest first. It really depends on what really motivates the individual. Some prefer to have some quick wins first. So when they prioritize, they say, oh, let me first finish off some of these quick items. Or no, let me finish the hard item. So I have a huge amount of confidence to then go and attack the easy ones. So really pick to see which is the style of prioritization that works for you. But amongst all of these, this last one is what really struck me. So this was mentioned by Adrienne. She heads the human resources for Starbucks, the coffee giant. And what she says is the power of your yes can only be as strong as the power of your no when you prioritize. Learning to say no for the right reasons when you've got to push back. I think that is very, very important. And I wanted to bring this to the room because I've personally been bitten by this as well. So when Microsoft was my client back in Seattle, I had my teams here working in India. And every time I used to get this feedback from the client, especially Indians. Again, sorry, no, nothing racial out here. What they used to say is for the fear of not wanting to say no, they would say yes. But ultimately struggle not being able to finish everything. So I think the power of saying yes is only as much as the power of saying no, whether it is a scope creek, whether it is something else that's been added onto your plate, whether that is a trespassing that's happening, a wrong resource allocation, a wrong tester allocation, whatever the case may be. Learn to say no for the right reasons. And that's a very important aspect in your prioritization technique. So now why do we have to prioritize it in software testing, right? Let's move on specific to software testing. So the first thing, what is it that strikes us when it comes to prioritization in software testing? We immediately think of defect management, right? What is the priority of a bug? What is the severity of the bug? That's the standard thing that we think, but it's much beyond than your standard defect management. And why is it increasingly becoming important for us to prioritize? Primarily because we are increasingly doing bigger and better things as software testers. We are collaborating with a lot more people on the team. The products that we are testing are increasingly complex. The technologies are diverse. The platforms are diverse. So with all of this and the increasing scope, we cannot afford to not prioritize what we are doing. And that is exactly what we will see. So far, so good. You're okay with the non-technical pace? Good. So what is that scope for prioritization, right? So I'm looking at prioritization specific to software testers under four major buckets. I'm not saying this is an exhaustive list, but I think this is a fair enough list. And if we start prioritizing under these buckets, at least we are fair enough on the right path to prioritize what we do. So firstly, at a people level, at a process level, at an activity level, and finally at a communication level. So these are the four buckets I'm basically gonna be looking at. So firstly, at a people level, increasingly testers are having the most number of interaction points or touch points on a product team. A month back when we were all in ATA in Pune, the Agile Testing Alliance, Ajay, I'm sure several of you must have heard of Ajay Balmurgadas, he had a very interesting presentation on 50 tips to increase the developer-tester interaction. I think that is turning out to be an interaction which is very, very critical amongst the varied interaction points that we have. So I think for us as testers, that should be our number one priority. Focus on that relationship that we build, the rapport that we build with developers. High context switching is happening in our interactions. You know, we are interacting with XX, we are interacting with peer testers, with people from other product teams. So prioritize your interactions based on the sensitivity as well, so as to determine what to say, when to say, and how to say. Moving on at a team level, at an organization level, we, you know, this is quite standard. Most organizations do have SMEs. We have SMEs at a performance level, at say an accessibility level, at a security level, but I think where we fall short in prioritization is making sure the right testers are available for the right projects when the need actually comes in. So I'll take our own example, right? So I didn't introduce myself at the very start, so I come from a company called QA Infotech, we are into software testing and quality services. So we provide quality services for clients, for varied product companies. So there are quite a few clients of ours where the work is not flowing in on a consistent basis, it keeps coming and going. So how do we prioritize the test of allocation in such situations, where we know that the client also wants the same testers, and for our own reasons as well, we know it is best to allocate the same testers to the same projects. So we have this SME pool, let's say we have about 10 testers, tester A and B are SMEs for project A. Tester says C and D are SMEs for project two, so on and so forth. So anytime a project comes in for which I am an SME on, so even if I'm working on another project, the company will take me out and put me back on the project that I am an SME on. So I think that kind of a tester allocation prioritization pool has to be maintained at a people level. If you've got to build your niche, if the project has got to do well, and you have the right amount of resource allocation without as much bench as possible in the organization. And finally, for organizations out here, I think it is a topmost priority to brand and rate people as the number one asset in the organization. If people are invested on as the number one asset, prioritized as a number one asset when the organization is certainly well on its success path. So these are some of the core two or three things I would call as top priorities at a people level. At a process level, right, I think a topic that's been beaten to death pretty much in the last decade. You know, how much should I be spending on documentation? What kind of processes do I adopt? Test strategy, test planning, test cases, test scripts, what level of documentation? So that I think still continues to be a custom choice. As much as we try adhering to the agile manifesto, agile manifesto is never saying don't do away with the documentation completely. So I think that's a very custom choice, but what is important is to prioritize the revisiting of processes with every release and make sure you're learning from your previous experiences and carrying those on a prioritized manner to your subsequent set of releases. I'll give you a few examples out here. We talked about optimization, how it's increasingly important to optimize. We do a lot of mobile testing in our organization, and these are some of the core practices we keep in mind anytime we optimize our test matrices for mobile testing. For instance, functional issues are more operating system dependent rather than the device or screen resolution. UI issues are more specific to the device or screen resolution rather than the operating system. So these are some of the bylaws we keep in mind in determining what is the matrix that I really want to build. So build such practices, basically learning from previous experiences to determine how you're gonna do your optimization. Secondly, it's becoming an increasing priority to invest in newer processes. You cannot continue to stick on with your old processes. For example, most clients of ours are increasingly asking for crowdsource testing. And crowdsource testing, as simple as it may sound, you may just say, what is a big deal? Bring in the crowd and it's all an open source community and we can just implement it. It's not as simple as that. Crowd source testing does have a lot of planning that goes into it. What, how, when exactly to take it on, stakeholders approval, a bunch of things. So any new process that you prioritize on has its own intricacies and nuances. So prioritize the number of newer processes you wanna introduce and invest in them. I'll give you one example out here. Again, from our experience, there are a bunch of clients who ask us for crowdsource testing. But for varied reasons, we are not able to take on crowdsource testing on an ongoing basis. We still have a traditional in-house testing that is happening. But on a quarterly basis for such clients, we do take on crowdsource testing. We've built a platform for this called dub-dub-dub.bugmoney.com. So these are like bug hunts that happen on a quarterly basis, either on a client request or on an ongoing manner to participate in the community. So anyone who's interested as well can go in and register. But what I'm trying to say out here is as a company at a process level or as a tester at a process level, prioritize innovation. Innovation is going to be absolutely important moving forward. Now at a third level, right, at an activity level, combine test efforts whenever possible. We're all testers out here, extremely technical, involved in Selenium. You guys are all here for the conference. But how many of you actually use your Selenium test scripts for doing a bunch of other test efforts? Do you take on primarily functional testing or are there other areas also that you touch upon with your test scripts? Any other test areas? Accessibility, usability, security, anything else that you do with Selenium? Security you do. Anyone else? So I think this has to become our priority moving forward to see how Selenium, the base functional scripts or the base automation that we write can be used for other areas. There are two more people from QA Infotech coming here tomorrow. They're going to be speaking exactly on this. One person, I'm sure, is going to be talking about how Selenium test scripts can be used for accessibility testing. The other guy is going to be talking about how Selenium test scripts can be used for security testing. So I think as testers, it's becoming an increasing priority for us to not just focus on the core functional testing, but see how we can leverage those scripts for non-functional test areas as well. So that is number one. Secondly, increasingly important for us to keep the automation very, very simple, right? Because we're having a bunch of other people use our automation as well. End of the day, no one is really going to be worried or care about how complex this person's automation is, how geeky, your geekiness is not going to be determined based on how complex your entire automation framework is, right? Rather based on how many people have been able to use it, how non-business people, non-technical, your business folks, your marketing folks, increasingly they're all using your automation code. And with that, how the stakeholders are able to make that release sign-off call as well. So I think increasingly a priority for software testers to see how to simplify the automation, making it more usable and scalable across an increased number of user base. Finally, keep prioritizing your test productivity. And when I say test productivity out here, a couple of years back we had demoed this in a conference as well, saying how newer technologies like augmented reality don't just focus on testing for augmented reality, but also look at how augmented reality can help testers increase their productivity. So very soon, for instance, we may hit a point where saying a thumbs up means a test pass, thumbs down means a test fail. So leverage, prioritize on using such techniques to improve your testers overall productivity itself. And finally, balance between functional and non-functional testing. Increasingly, as I said, see how Selenium, how your functional scripts can be used for non-functional areas, because things like linguistic testing, things such as accessibility testing are going to determine the legal acceptance and the overall user acceptance of your product. So if I may say here a quick example, we did this webinar for Eurostar just couple of days back, today is Friday. So Wednesday night, I did this webinar with another colleague of mine for Eurostar. I'll give you this simple example. This was back in 1994. Henneken Beer was coming out with a marketing campaign for the 94 soccer finals. And what it wanted to do was print the labels, the flags of all countries that were finalists on its label and attach it to the beer bottle. Saudi Arabia was one of the finalists too. So it had Saudi Arabia's flag on the beer bottle, but it extremely impacted the religious sentiments of Saudi Arabians because the flag has an inscription from the Holy Quran. And to have that on a beer bottle was completely detrimental. So Henneken had to quickly pull it off. So this is an example of how cultural sensitivity and context is also becoming increasingly important in what we do, increasingly impacting the software that we develop as it all becomes more global. So balance between functional and non-functional testing and also try to see how your functional test automation can help in some of these other non-functional areas as well. At a communication level, right? So I should have, I'll probably ask the question right here before I move to the next slide. Any idea what percentage of time we all spend on emails on a daily basis? Sorry, sometimes 80% on an average, 40. Okay, so you're higher than the average study still. 20, 25. So studies say that we spend 25% of our time every day on emails, which is a significant amount of time, right? It's like one quarter. And if I think that is significant, he says, there are days where he spends 80% of his time on emails. So imagine if that is the kind of time we spend our overall efficiency and productivity. Bangalore again, if we were to take Bangalore's case as an example, I'm sure several of you would vouch that a work from home is much better, right? Otherwise we're spending a significant amount of time just on the roads. So with all of this that's happening and we as testers are increasingly social animals. We talked about how the interaction points for us as software testers is much more than anyone else on the team. So with all of this, I think we've got to prioritize communication to see how it is productive and effective to make sure it doesn't impact what we do on a daily basis. So leverage tools, right? Whatever it is, whether it's sometimes in-person meetings are absolutely important. There is significant value coming out of it, no doubt. But as much as possible leverage other tools, messaging apps, Skype, Slack, for instance, several of us in our company, we use Slack. So whatever the case may be, do that because end of the day, this is a picture which I typically show in most of my presentations. James Bach talks about the varied types of testers. I'm not gonna walk through each one of these, but if you see most of these types of testers, whether you're a social tester, a user expert, an empathetic tester, we spend a lot of our time in communication. So we've got to prioritize and balance it to understand saying, is this really urgent? Is this really important? Should I be spending this amount of time on communication? Draw that balance also because studies show that testers are increasingly social beings. So if you were to go and ask a tester, how are you keeping up with the latest and greatest of what's happening? Most of them talk about social media, right? Whether it is Twitter, Facebook, and all of these can easily get distracting, right? So how many of us actually go in there for the purpose and come out? At least I don't, I easily get distracted. So with all of this that's happening at a prioritization level, I think communication is also very, very important. So these were the four main heads that I wanted to bring to you all today. At a people level, at a process level, at an effort level, and at a communication level because end of the day, prioritization is inevitable. Whether conscious or not, it is absolutely, increasingly inevitable. Not every style works for every individual. What has worked for me doesn't work for another. Again, as I said, for me as well in different scenarios. Control your actions. Most importantly, what we prioritize is what we end up doing. So our actions are all controlled by our priorities. And at the end of it, you may ask me what's really new, right? What have I really learned new in this whole session? I think what is important is we may have been doing prioritization in a mode where we didn't really understand that we were prioritizing. But if we do it consciously, understanding the difference between urgency and importance, the timeline, the impact, the entire thing coming in together, prioritization comes into our control, which means our actions come into our control as well. That's all I wanted to share with you all today. So hopefully a decent break from your other technical sessions, but any questions, open it this time, okay? No questions? How many of you think that you really do prioritize? Consciously, okay, a few hands raised. So with that note, I'll walk out with one small example. I was just telling Anand as I walked in today. So there's an ex-Microsoft senior guy who's joined as a technical advisor for the Washington governor today. So he says, one of my main tasks, the priority for me is to prioritize for him. Because all of us out here, we can never do everything. And according to him, if there's one person who can really get to every level of detail and manage everything without prioritization, he says it's Bill Gates. So apparently, according to him, in his experience is that I cannot vouch for it, but this is going to be his job. So end of the day, it's all about prioritization. So hopefully we'll have more conscious prioritization coming up for us as testers down the line. Thank you.