 A week before, two weeks before again. I see. Mr. Newton, you're exactly the reason for it. Oh, that's great. All right, good afternoon. We're going to begin our next talk, which is, you can see, this title is Sinif. I'm missing role in Padraal's game. And, of course, our president here is Deepak Cohen, who is an associate manager in quality engineering as is stated on this slide. So, how would you go further ado? All right. Am I audible? At the back? Okay. So, my name is Deepak. I'm an QE, basically. And I started in 2007. This was the year when the global economic recession also started, incidentally. And the Selenium and the WebDriver projects also merged, which would then go on to become the de facto web testing standard. So, I did five years in PTC, which is paramedic technology. And before coming to Boston, I was not aware that PTCs had quartered 19 miles from here. And after that, I did six years in Red Hat. And I've been doing the same thing for last 11 years, like accepting user stories, writing automated test cases, and finding bugs. So, you will say it is a monotonous job, right? But if you have an eye for it, it throws a bit of nuances and challenges every day. All right. Anyone in this room whose responsibility is the software quality? All right. So, there are a couple of people who fell in the trap. So, this was already discussed in one of the earlier sessions that quality is everyone's responsibility. And the agile recipe. So, my talk is an agile recipe. So, it is only fair that I give you the disclaimer that the most important ingredient of any agile recipe is the people which practice that success recipe, right? So, you cannot copy a successful agile recipe and paste it on a different team and expect similar results. So, it can either do really well, better than this other team, or fail really bad. All right. So, let's start with the heartbreaking story. So, has anyone seen this progress bar on a web page? GitLab has it. Okay. So, it was back four years ago. I was working on a user story. And it was a ticket management tool. Single page web app, ticket management tool which had, let's say, hundreds of fields. And out of those hundreds of fields, two were the fields which used to be pulled regularly because we had to show users the correct data. A very updated data. So, what we used to do till that time was we used to discreetly update those two fields by pulling, making two network calls in the backend without telling the user. So, in that sprint, there came an enhancement request that you need to give users a visual clue that you are fetching the fresh data for those two particular fields. So, my developer friend used this JavaScript library. I really liked it because it was on GitLab. It was on my favorite e-commerce site. So, I thought it was cool. So, as a QE, I tested on different browsers because JavaScript, and then I did regression tests as well. And one Friday morning, eastern time, and unfortunately the Friday evening, India time, we released it. And I had this habit, like teenagers, when they put their cute selfies on Facebook or Instagram, they refresh the feed to see how many likes. So, after every release, I had this habit of, you know, monitoring emails, IRC, as well as the bugzilla feed to see whether there is some backlash or not. Till 30 minutes, there was nothing. And after 30 minutes, there was a huge outrage. These are not the actual flippings. I just made them. So, there was a huge outrage. So, everyone said that this is a usability disaster. This change, this particular loader is distracting us from working. And if we don't work on cases, Red Hat loses business. So, we quickly reverted the change and to bring back the saneness in the system. And then we had a retro, right? Like every team, we had a retro. And out of the retro, everyone said that this happens. We could not gauge the user behavior, right? We thought it was a good way of implementing this change, but we could not. So, we actually brushed it under the carpet. But then I did a retro with myself. I'll explain in another slide that the retro which you do with your inner self is the best retro ever. So, this was the struggle. So, this is the user. Support engineers in our case. And this is the QE and this is the developer. If you look at these three categories of people, which two are more likely to go for a drink together? Or maybe share a laugh or go on a team outing? Like QA and developer, right? Because they have that team bond proximity. And because of that proximity, which is a psychological thing, right? You cannot change it. Because of that proximity, what QE does normally in agile teams is they test the change. They don't test why did the developer implement that code change, right? So, very existential question. But QEs mostly fail to do that. And more so in today's time when we don't have traditional QEs, right? Every QE is also a developer of some different kind. They are writing code day in and day out, right? So, once you see a piece of code on your developer friend's machine, your mind becomes biased. So, now you have three ways of breaking that code, which you have already seen. But it's not a black box to you now. So, there were hundred other ways of breaking that code, which you will miss now. Then we thought about why don't we do one thing? Why don't we bring fresher perspective into the QE thing? So, same work stream, we bought another QE, right? But without making any capacity changes. So, there was user story one, there was user story two. And there was first QE and primary QE and secondary QE. So, primary QE will work on user story one for 50% of his time and on user story two for 50% of his time. And the same thing secondary QE will do. So, because no two people think alike, I haven't made it up, it is neuroscience. Our mind is connected like our fingerprints, it's different. So, different people perceive things differently. So, if you look at crowd sourcing testing platforms, which have, you know, boomed up recently, they exploit this thing. So, they'll take a website and throw it to 500 testers all over the globe. So, we thought that this will at least make some improvement in our process. It did. But there was still a gap because to work in this system, both the QEs needed to attend all scrum ceremonies like daily stand-up planning, retro everything. And the proximity challenge which the primary QE earlier had, the same thing happened with the secondary QE as well. Then we came up with a new thing called Cineq. Cineq is someone who is not part of this work stream, a completely different person of maybe a different project or someone else on the bay. So, what does Cineq do? So, how do you, the first thing is how do you find a Cineq? So, these are the qualities of a Cineq. Cineq should not belong to your work stream or project, which means that he is shielded from the project-related discussions, right? The Cineq should be naturally a vocal and SRT person. So, we don't need to make any effort on finding these people in red hat, right? And the third and most important thing, he should be willing to help. Again, in red hat, you will find, because people contribute to different projects. So, you will find Cineqs. And then, if you don't find, then you have to incentivize. Right? Now, what does a Cineq do? Cineq gives a very fresh and mostly end-user perspective to your work, because he's not seen the code, right? He's not been part of planning or grooming or scrum. So, he is looking at your changes as a user. And Cineq is your accountability. And if we go back to this line, what we have to do is, we have to nudge this person from here to slightly here, right? And Cineq does that. He nudges the primary, secondary QE towards the building the right product side. Now, the take-aways from this talk. So, if you look at what happened after that incident, that usability incident, first we tried to introduce a secondary tester, right? Then we identified the gaps. Then we tried to implement a Cineq. So, we were constantly improving, finding gaps and improving the system, which is the essence of an agile team. And then, again, the thing which I said earlier, best retrospectives are the ones which you do with your NSL, right? Because the actual retrospectives are very formal. The third thing which you can do is, you can sign up a Cineq. You can find a person in your bay who is not part of your project and ask him if he can give 30 minutes per week to you and see if it works for you. As I said, this is a recipe that can work for you. It can work better for you than it works for us. Because in our team, we have a UI work stream, a mid-tier work stream, a services work stream. So, the QE working in UI work stream automatically become natural cynics of, because they are the consumers of the service layer, right? They become natural cynics of the service layer work stream. So, what you can do is you can find a Cineq, a very assertive and vocal person, and try to sign him up for your project and some physical takeaways. So, if you look at this Tiffin carrying duty bag, I have bought this, three of them from the mountains of Kashmir in the north of India. So, I actually want the feedback for this. So, for that, I am incentivizing. That's a nice bag. So... Why aren't you taking off the Cineq? Sorry? Are you taking the process by buying this in its affections? Maybe. But right now, I just want feedback for this talk. So, whoever uses this hashtag, you can take the photo as well. So, whoever uses this hashtag in the next 30 minutes and provides a tweet as a feedback. And because I have bought them with my hard-earned money, so I'll choose the best it reads and I'll give away these bags. All right. Any questions? Great talk. I really enjoyed the Cineq as part of the team and that aspect to it. But I noticed that there was a bit of a similarity between the secondary QA and the Cineq because you're already pulling in an engineer from some other... There is no similarity between Cineq and secondary QA. Secondary QA is part of your work stream. So, he has to attend your scrum ceremonies. But doesn't the Cineq also have to... No. So, for Cineq, you have to... The only interface between your project and Cineq is the primary QA. So, just like code review, you write code, you get your code reviewed from your body developer, right? So, let's say all the stuff which was developed came on the QA environment. Now I have to test it. But before testing, I demo it to a Cineq to get a fresher perspective. 30 minutes for per-spirit. It's not much to ask for. So, my secondary question. So, if QA chooses a single Cineq and like frequently demos with them, after some point, they're going to become buddies. And so, they're going to have to find a new Cineq. And so, maybe Redhead won't have this problem. But at smaller companies, they might have trouble finding enough Cineqs to... See, if primary QA and Cineq become buddies, that's okay. That won't make any difference, right? Because it does not put any bias in Cineq's mind towards the work which developers are doing, right? If they're buddies, I think there's going to be a little bit of a bias. But he's a QA, right? The job of QA was initially to start with to break the code, right? But then we went into simply rubber stamping the code. So, we need... See, if you go to GIM, right? The most common example of accountability partner is the weight loss thing, right? You start with weight loss. You make a new resolution, you start with weight loss. And over a period of time, let's say by 3rd January, you stop going to GIM, right? But if there are two people who are each other's accountability partners, then there are chances that this weight loss resolution will go till March or maybe mid of April. Thank you. Any other questions? Feedback? Me? You need a professional sign? Yeah. I'm a hire. All right. Thank you, everyone. Thank you for your time. Don't forget about the bags. I don't want to take them back because I have done shopping from Boston. So, everybody probably remembers, we're going to be men's job for the afternoon, the closing afternoon. So, that'll be a three. Okay. So, you have to find a time.