Learn
Events
Discussions
Contribute
JOIN NOW
Help
Sign In
Peet Michielsen - Code Reviews for Testers v2
- Hello, good evening, and welcome to today's 99 minute workshop. My name is Peet Michielsen. Can somebody in the chat let me know if you can hear and see me? Ah, great, thanks. Thanks, Deborah. Good. So as said, yes, my name is Peet Michielsen and I'm a senior verification engineer at Optos. We make medical devices, eye examining software. And today I will talk about how you can get involved as a tester in code reviews and how you can benefit from that. So what's on the agenda today? We are going to look at code reviews and how you can get involved as a tester and how you can benefit as a test from that. We want to address a few learning outcomes today. We are going to look at, if you look at a piece of code, how can you formulate test ideas from that? How you can identify potential issues, plainly by looking at a piece of code. And if you're getting involved in code reviews, how can you make it as respectful and meaningful as possible? So code reviews and how to get involved. First of all, let's have a brief look at what a code review actually is. And I didn't come up with this definition myself. I just Googled it and I found this represented a good way of saying what a code review is. A code review is a piece of software, is a software quality assurance activity in which one or several people check a programme mainly by viewing and reading parts of its source code. So fairly clearly, you are not actively executing the code, you're just a static analysis on a piece of code, and you give feedback on that. Before we go to the next slide, I forgot to ask if you've got a question to ask that is at the bottom of your screen in Ask a Question section. Please use that. And during the exercises, I will try to answer the questions for you. But you might think code reviews, is that not something for developers? What have I got to benefit from that as a tester or as a quality assurance specialist? And as you see this, I've worked in plenty of organisations where testers were never really getting involved into code reviews. Code reviews is not always an activity testers are getting involved in, and that can be by choice. Testers can say, "Hey, oh, well, that bit is way too technical for me. Just let me focus on GUI testing, frontend testing. That is where my specialty lie." Or yeah, "I am too busy testing the piece of software. I cannot get involved with any other activities than me doing the testing." Or if it is not by choice of the tester, it can be quite often, and I've seen it in practises that it is due to the culture of an organisation, things like where a project team says, "Nah, code reviews is not for testers. You just test. You don't need to get involved in our technical stuff." Or what I've heard said as well to me, "Oh, sure you wouldn't understand any of this. This is way to technical. You don't need to get involved." So be it by choice, be it by the culture of the organisation, for whatever reason, it is a shame, because I believe as a tester, there are lots of benefits to be gained by actively participating in code reviews. And that is what we're going to look at during this workshop. So first of all, I want to touch on this is how you can use code reviews to formulate test ideas. There are lots of different sources where you can get ideas to define your test cases. For example, the most obvious one is look at the requirements of the piece of software you want to test and define your test cases based on that. Or during your daily regular team communication, activation planning, requirement refinement, triaging, three amigos, that sort of stuff is a valuable source of information that you can use as an input for your test. Look at domain experts online within your community. Ask them questions on possible test cases for the piece of functionality you want to test. What I quite often do, is look at what competitors have in their product. The kind of features, the kind of approaches they have in their products. And I translate that into tests that I want to execute against our products and services. And then, of course, there is the code. Just by looking at some code or changes that have been made to code, it can give you... Yes, bye Mark. Mark is saying bye in the chat. We'll catch up with you later, Mark. Okay, good. So just by looking at some code or changes to the code that have been made, you can determine which things you might want to test. If it is change to a piece of code then you can say, "Let me focus all my test effort, only on that specific change or around that change." No need to test things that are not related to that piece of code or the changes to that piece of code. And that brings us to the first exercise, how you can formulate test ideas just by looking at a piece of code. I've got here a piece of pseudo code, and hopefully everybody can read that. It is very straightforward. This is an example, at least in the UK, if you're 17 or older, you can start taking driving lessons. So this piece of code determines if you're old enough to take driving lessons. So if you look at this piece of code, this is, how do you want to test that? What kind of potential inputs do I want to use to validate if this piece of code works? Then we can have the most obvious ones, 16, 17, 18 using a test specification technique called boundary value analysis. 17, which is there straight into the code, which is there in the code, have a value slightly before that, have a value slightly after that, and see what the output would be. Classic one, a negative value. A value of zero, a value of one, a ridiculously old, a ridiculously high number. Whoever is 188, I don't think they should even consider start driving lessons. You can use a piece of text or you can use special characters or just type in nothing. Yes, Cornelia, the classical QA walks into a bar joke and see what comes from that. So let me see. Now I need to see if I can get the URL of the first exercise into the activity bar. You should see a button in the bottom of your screen called Exercise 1. If you click on that, that will bring you to Miro board. Let me see. Can people say if they can get into the Miro board? Good. That is good to hear. So what you see there is a piece of other code. It's not a piece of pseudo code. Just to determine which of three numbers is the higher number. And what you need to do there is copy a sticky and type in potential values for that for the three numbers. And we'll roughly have about 15 minutes for that. I already can see that Lee has started to put a sticky on the board. So I'll give you about 15 minutes to come up with potential inputs for this piece of code. And if we go along this, I will try to, what do you call that? Group them. So good luck with your first exercise. As you can see in the left top corner, there is a sticky that you could copy and paste, make it easier for yourself. Yes, Charlie. So potential numbers or potential inputs, it can be whatever you want. The last time I did this exercise, I'm not going to give anything away, but people started to use emojis as input, which is quite a common thing to do. Good. Thanks for confirming, Charlie. Seeing some good things appearing on the board. Oh, where did I see? Yep. Good. Good. I'm moving stickies around. So don't be offended if you can't find your stickies. I'm not deleting any of those, I'm just moving them around. People are still typing away I see. It's good. Also, I'm wondering is that I gave a few possible sources where you can formulate test ideas from. Feel free to leave in the chat other suggestions of sources that can be used to formulate test ideas from. No, Yuku, if I pronounce your name correctly, you can put as many stickies as you want. The more, the better. Yep. Okay, I'll give it a couple more minutes and then we'll go to do a recap. Yes. Observability data. Very good, AJ. And that's a good source is what is the sort of information that you can get out of your system? Analyse that, have a look at that and determine further tests based on that. Another thing that we did as well, is that because we are producing medical devices, which are used by ophthalmologists, is looking at how doctors are using our devices and derive test cases or test ideas from that. But yes, observability data. Very good one. Right. Good. Let me see if I can share that Miro board. Stop sharing my screen. Whoa. Now see my big face. Let's see if I can share that. Yep. Good. So hopefully you can also see the Miro board now on the Crowdcast screen. So what I've done is I moved a few of the interesting stickies to the side here. And you can fairly clearly see is that a lot of people have got the same ideas and almost that you can ask the question, "What exactly is a number that is not being clearly specified in this piece of code?" So this notation, the square root of minus one, it is a number, but is it a number that will be taken by the system. Or here is, I saw, 0xA, which is a notation of a number. Similar as here is the 0xFF or 0x01, 0x99, that are all in computer language that can be classified as a number. And then a few that try to explore the boundaries of what a system can handle. I'm not going to attempt how any zeros are in this one, but there are an awful lot. Can the system handle that? Here's another one with fairly big numbers or a fairly small number. It hasn't been specified. Does it need to be a whole number or can it be a number with decimal points? Just try it as a test case. Here, another big number. 2 million, or I think it's even more, 2 billion, 147 million, 483,648. There you go. Characters. Classic one. It's the limit of end. Ah, there you go, Ash. I didn't know that. That's good to know. So everybody out there, take note of that specific number and use that in your next test case. A number, obviously, can also be written out, one, two, three. Negative numbers. Can the system handle that? An at sign, which is not a number, but does the system handle that? Is all things... Oh, and here, yeah, I wanted to highlight this one as well. So 1.3e + 1 is also a way to express a number. Can the system handle that? Oh, here again. One, two, three. So there you go. So even with this simple piece of code, you can come up with a numerous amount of things you can use as a test input. So yeah, just keep that in mind. And already, one of the things that I took away from it is that the limit of end is obviously 2 billion, 147 million, 483,648. There you go. That is something I will take away from this session today. Okay, in Java. (laughs) Who knows what other systems will do. So there you go. So that was the first exercise is that you can see is just by looking at a piece of code, that you can formulate tests based on that. So if you haven't got requirements, if the team communication is limited, if you haven't got access to other sources, even if you've got access to other sources, this is always a good source to add to your arsenal. That's a very good one as well, Katie, what you said in the chat, that we should be minded of that. If a system could accept an input or shoot it, accept an input. So yes. And it might well mean, is that the developers of this piece of code just need to bolster up their piece of code a bit better. Indeed. So let's get back to... Where is my most pointer? Yes. So let's share my presentation again. So, good. And thanks, AJ. That is what I'm going to add to this slide next time I'm going to give this workshop, observability data. Good. So. Getting involved in code reviews is a good source to generate test ideas. The next point is this. It is a good way to identify potential issues with the piece of code without even having to actually execute the code. I'm keeping, watching too much on the chat. Thanks, Ash. Yeah, the HICCUPS mnemonic is good for test idea generation, yes. Indeed. So let's look at identifying potential issues just by looking at the code and without actually executing the code. You can find potential bugs. Clearly looking at the code, seeing is this, oh, this is just plain wrong executing. This if statement will end up in a nil point exception. Don't have to go to the expansive exercise of deploying it onto a system, then making the system available for testing, and then actually testing it. Even without doing that, you've already caught your first bug. But also, you can flag up inconsistent coding styles. Doesn't necessarily mean that you will prevent bugs with that, but it will enhance the maintainability of the code base, especially if you've got a really big code base. And if there is a big inconsistency in how that code is written, it is more difficult to maintain that code, but also it will hamper the learning curve for when new team members come on board and try to understand the code base that they need to work with. Poor naming conventions of variables, functions. If you just call the variable X and Y. Okay, in a geospatial system, that is absolutely fine. But if you're working with financial data, X and Y doesn't mean anything. So flag those kind of things up. It improves the readability of code, again, which enhances the maintainability. And it is easier to learn what a code is actually doing. Also, you can flag things up like that. There might be a lack of documentation. Okay, maybe this is a very controversial topic, but I always have been taught that every line of code should have at least one line of comments in the code, roughly. So every line of code, one line of comment in the code, so that if you look at a piece of code that you can understand what that code is supposed to be doing. Then again, saying that it might be a controversial topic, because there are advocates that are saying this good written code with good naming conventions and consistent coding style should explain itself. But then again, if you declare a function in the code, it never can do any harm to write a few lines of what this function is meant to do. Let me see, Cornelia is asking a question. "How to explain to a team member that he or she should try to name things better and possibly look at other method names written by other developers without sounding like an arsehole?" (Peet laughs) Hold that thought, Cornelia. Our last section of this workshop will tap into addressing that. So keep that for now. I will come back to your comment, Cornelia. (laughs) Good. So yes, lack of documentation, that are things that can be flagged up. And it might be okay not to have documentation now with this, but if you've written a piece of code, and if you have to come back to it six months down the line or a year down the line, if you look again at that code, will you still understand what that code's supposed to be doing? Hold that thought, as well, I will come back to that in the exercise I'm going to show you in a bit. You can flag up code duplication. If you've got a function with several if statements, and if those if statements are doing sort of the similar thing, it might be better to hoist that code out of there, put that in a separate function. It improves, again, the maintainability of the code base. And again, if you have to duplicate code over and over again, and then if you have to make a change because of a bug or as some refactoring. Who is to say that you make that change in all the instances where a similar logic is being used? It's quite easy to overlook all the 30 instances where one of the 30 instances where a specific thing needs to be changed. And yes, Ash, a person's code is a very personal thing at times, but in any professional organisation, agreeing on a standard on how you want to code makes life a lot easier. So let's just look at what that means with an example. So here, we've got another piece of pseudo code to determine if you're younger than 15 or older than 65, if you're eligible for a discount, for example, in a cinema, or for example, you take the train. And I've taken that example from the BBC website, Bitesize, which is actually a really good source of anything to do with computers. This is highly recommend to have a look on that website. This is if you want to learn more about coding. If you look at this piece of code, you would say, "Is this all well?" There is not anything obviously wrong. But if you look at it, there are four issues that can be identified here. The code here, if you look this statement, if age equals 65. It doesn't deal with older than 65. So only if you're exactly 65, then you're eligible for a discount. If you're 66, 67 or, from the example, 188, you won't be eligible for a discount. So there is an issue that is a potential bug, and we didn't even have to execute this piece of code. The code deals only with 15 or over. And the requirement clearly states that you're eligible for a discount if you are 15 or younger. So this piece of code doesn't deal with the case if you're exactly 15 years old. If you execute this code, if you type in your age as being 15, you don't get a discount. And then for completeness, there is no statement for ages between 15 and 65. So I would have expected to have an else statement after this as saying, is this print not eligible for a discount to deal with all the other cases that are not covered by these first two statements. And then again, there is a bit of code duplication. Okay, this is a very trivial one because there is only one line of code in each statement. But if this would have consisted of multiple lines of code that technically are the same as this, it would've been much better to make a separate function for that, called that separate function. Now, thinking about it and looking at it again, one thing you could comment on is where is the documentation? There is only one line of comment, which eligible for the discount, question mark. It doesn't specify that this code is meant to, if you're 65 or over, or 15 or younger, that you're eligible for a discount. But that is a bit of nitpicking. That could be a potential fifth issue with this piece of code. So let's look at another example. What I'm going to do now is, here, we've got a real piece of Python code that I've written one and a half year ago, I think. I must say I did alter it a bit for this exercise, but most of it is, and the functioning, I have not touched it at all. And rest assured, you don't have to be a Python programmer or a programmer at all. You don't need to be able to read this theta test pseudo code. But surely you will be able to find potential issues in this piece of code. So give me a second so that I can put up the URL for the second exercise in the bottom of this screen. So that has changed to Exercise 2. Again, it is Miro board. And if you go to that Miro board, you see a canvas with on the right hand side, that piece of Python code. And again, similar exercises, put a sticky on the left hand side and type in the potential issue you have found with that. Please don't please don't move the code itself. So that is there as a reference. I will keep the slide up as well on the screen here. So again, about 15 minutes to come up with potential issues in this piece of genuine code written by me that I used for something back in the day. Good luck. I see some people adding stickies to the board. Very good. Please let me know if any of you are having difficulty getting onto Miro. I always like this bit because I can give my voice a bit of a rest and I can see all the amazing stuff that you people come up with. And again, you might find that your stickies are moving. That is just me trying to point them out. And the items that I want to touch on. So if you need more space, I will expand. Oh, I like some of these that are coming in. Good. There are the few that make me choke, all of this, they are all fairly valid comments, the potential issues that you come up with. I assume you could actually mean the cursors on the Miro board is there are quite a lot of people of us today. So there are about 20-odd people, all trying to do something on the Miro board at the same time, which can be a bit tricky, yes. Again, give it a few more minutes. Wow. And again, I see some that I haven't even thought of. Great stuff. Right. Let me see. Good. Let's go to the recap of this exercise. Let me stop sharing this screen and then go to the Miro board. Wait, cancel that, move this to another screen. Good. Try that again. Ah, thanks for the tip, Katie. I will try that. I will try that again. I will try that as well to get rid of other people's cursors. Good stuff. And again, I learned something from this session as well. Excellent. So let's have a look at what you all came up with. These here, all in this cluster, is this, yes, naming conventions. I did change a few of them, but I left a lot when I originally wrote this piece of magnificent code. So yes, people have said this is, it is a mishmash of capital case, using capital letters, using underscores between words in a variable or a method. Also, d_t, you need to read the rest of the code to gather that datetime is meant with that. So please, use whole words in a variable, if you can. And then here, somebody said "Who is x?" Indeed, who is x? Doesn't make any sense at all. Here a few that have said, "No code is commented to explain what the code does" or "More comments to know what it is trying to do." Yes. And a big confession, I wish I did the same. I hadn't done that, writing more comments in the code, because when I look back at it, this is after one, one and a half year, after I have written this code. I know that it is doing something with reading log files and then get information out of it. But I don't, honestly, I don't know what I have written this piece of code for. So. Yes. So there is that. Let me see if, why can I... Yes, more info on why the seventh digit of the milliseconds need to be trimmed. Didn't explain that at all when I said that here. So that is actually the only piece of comment I made to the code, seventh digit of the milliseconds needs to be trimmed. Why? I can't remember anymore. Yes, again, formatting though, inconsistent method name cases. This timestamp format, not correct. Actually, the timestamp format is actually how it is written in Python. But seeing this bit of gibberish, it is a valid comment to make. Is this actually correct? Same with... Where did I see that? Oh, yes, that the spacing and the formatting is messy. Hate it, or love it, that is Python. There is actually nothing wrong with the spacing and formatting in this one. So sorry for who wrote this. But again, if you're very familiar with another programming language, then this can come across a bit arcane, yes. Say, for somebody commented on this is that there is a rogue comma here. Again, it is a matter of preference, this. I like to write lists like this with an additional comma, because I might want to add more items to the list later. And in this specific programming language, Python, it doesn't break the code, and some people actually prefer it to be written like this. But again, a very valid question to ask. In this whole big list or big board of stickies, somebody also made a comment that there is not actually passing going on. This is if this will be taken by if you write the row. Does it need to be three items? Can it be both? Does it need to be less? Another few things is that I picked up when I looked at my own code again, for example, and this is nitpicking, but that is a single quote and double quotes are used interchangeably. Most of the stuff is using double quotes. But for example, here, when you open the output file, there is rogue single quotes here. Again, Python doesn't prevent you from doing it, but it is messy. So agree on the format. Are we going to use single quotes or are we going to use double quotes? And try to stick with that. Makes code reviews a lot easier. So I think that are roughly the... Oh yeah, here again, single quotes, double quotes. Yeah. Also somebody commented on that the same variables are declared. Oh yes. Very good one, Ash. This piece of code doesn't output any log itself. So if there is anything going wrong, good luck debugging this piece of code. Yes. Very valid comment, Ash. But what I was going to say is, people saying, yeah, that variables are redeclared. It's quite common to do. This is because it can enhance the readability. But again, that comes down to preference and the agreed coding standards, because you could declare the input file all on one line if you wanted that. Yes. So lots of lessons learned for myself is mainly be consistent in variable naming, and please, please comment your own code so that when you have to come back to it, that at least you don't have to spend half a day trying to figure out what it's supposed to be doing. Yes. Redeclaring variables, Ash. That is something you can do in Python quite easily. But yes, it's, again, a Marmite case. Love it or hate it. Right, I think we need to move on to our last section. I do like Marmite as well. (laughs) Let's move on to our last section. Let me put up the presentation again. There we go. Good. Respectful and meaningful feedback. And now pay attention, Cornelia. This is where we are going to address this, how you can give feedback without sounding like an arsehole. Let me see. So, because if you fail to be respectful and meaningful, that can have a lot of negative implications. So striking a harsh tone in code reviews, either, yeah, in the comments or being unclear, this can have unwanted side effects. So it slows down the review process. All in all, this is because if you are fairly short in your feedback, which raise a lot of questions, that slows down the process. And also, it can escalate, and then it needs to be dealt with on a manager's level and that sort of stuff. So, yeah. Be respectful and meaningful. It will keep the whole review process to running more smoothly. Also, because of it slows down that particular of code change, code changes, lots of other code changes that come after that will be blocked till that one is solved. So all in all, you are slowing the whole process down. Also, it hampers learning for everybody involved in the process. If, as a person that puts up a piece of code review, if you don't give any description at all why you've made that change, what a change is supposed to be doing, then people, and especially the less experienced people, are guessing and not getting on board enough with the whole code base. And also, if you're reviewing a piece of code of a developer that just recently joined the company, and if you give feedback like "This is wrong" or "This won't work," that new person wouldn't necessarily know why it doesn't work or why it is wrong. Try to give a bit of context. It enhances the learning for everybody involved. And again, failing to be respectful and meaningful, it just fosters negative relationships. I'm not saying you need to try to be best friends with everybody on your team. But likewise, don't actively try to alienate people that you're working with on a day to day basis. So, yes. So when you're going to participate into code reviews, here are some dos and don'ts that you can keep in mind. First of all, is do assume a certain level of competence. We are working in a professional organisation with well trained people. You can assume that they know their stuff to a certain level. So don't try to, what I'm trying to say is, assume competence, a certain level of competencies and don't try to explain things, fairly basic things, over and over and over again. Don't belittle people in that way. Also provide rationale or context. In both cases, if you put up code for review, try to provide the rationale or context of why you've made a certain change, explain what the change is doing. Also refer to best practises, guidelines, design principles, that sort of stuff. And that applies to giving feedback too in a code review. As well as, if you see a piece of code that goes against the agreed system architecture, don't say "This is wrong," but try to refer to that specific architecture principles or guidelines that have been set out for that project. So provide that rationale and context. So that serves two purposes. So that the feedback you are giving can be backed up, but also it, again, to the previous point, it enhances the learning of everybody within the team. Also, be fairly conscious of how comments might be interpreted by people. So be mindful of the differing ways, hyperboles, jokes and emojis may be perceived. And this is where cultural differences might come in. So be aware of that. Especially because most times, the most cases where code reviews are put in place, it are written exercises, and a written word will come across differently than verbal communication. So be very aware of that. Also try to provide specific and actionable feedback. So please refrain form single statements. I've mentioned it before. Don't say "This won't work." Explain why, in this certain situation, the code change or the piece of code might not be working. So provide that feedback. And if you're saying "This won't work," try to offer alternatives or different approaches, but which might be better suited in that certain circumstances. And also, especially if you have a few things to comment on in a piece of code, try to split them out in things that definitely need to be addressed because of a thing that will cause a bug in production, or that it is not implemented the way it should be because it doesn't meet the requirements. So things that have to be addressed. And then the nitpicks, the minor things like typos, which can be deemed important to address, but a missing comment, that sort of stuff, the minor things, you can list them out separately so that a person having to deal with that feedback knows the things that definitely have to be changed and things that are not necessarily need to be changed straight away to be able to close out that code review cycle. And then please do not, and that is to answer Cornelius's comment, don't be an arsehole. (laughs) Just by trying to do the things that I've said in the previous slides, but please do not directly criticise the person. It is not a personal thing. It is about the code. So please don't start attack the person directly. Because most likely, you will have to work with them for a long time to come. So try to foster that good working relationship. So keep it focused on the thing you're dealing with and that is the code. Don't use harsh language. It is less likely that it gets you anywhere. I'm not sure if that is completely same saying in English, but in Dutch they say it is the tone that makes the music. So try to be mindful how you write your feedback, and try to understand how that feedback might be perceived by the receiver of that feedback. Then again, as we said in the dos, assume competence, but in the same sentence, you could say, but do assume things. So yes, you need to assume that we are all professionals, but if you are dealing with a highly complicated piece of code that just do a fairly tricky thing, don't assume that everybody straight away understands. So a bit more context might need to be given. If you present a piece of code for review, give that context of what that code is supposed to be doing, what are are the design principles that you've used for implementing it. But again, also, if you're giving that feedback, don't assume that the person will completely understand the highbrow or high level of detailed feedback that you're giving, especially if you're dealing with people that have not been with your team for that long, or if you're working with junior developers, for example. And the last thing is please never ever start a ping-pong contest in code review comments. For example, you're reviewing something, "This is wrong," because this of that and that and that, and then as a response from the reviewer saying, "Oh no, so you're wrong," because it is such and such and such. Don't go back and forth in the comments. If you see that that is might likely to happen, take it offline, start talking directly to the person in question and try to explain each other's standpoint and see if you can reach a common ground. And if need be, get a third person involved that can mediate, if need be, if things might be getting nasty. So I hope that touches on what you were trying to say, Cornelia, in the comments, this is how not trying to be a bad person when you're giving feedback. So the last example that I'm going to show are three examples of code review comments. Instead of writing this, you could try another wording for it. For example, if you saying, "Why didn't you just do dot dot dot here?" You could say, "You could do this instead of the," then the solution that you've provided, which has the benefit of dot dot dot dot. Few things, what's happening in here, as in the rephrasing, is you're not criticising the person, you're giving an alternative for a potentially better solution, and you're giving some context, it has the benefit of dot dot dot dot. A one line comment. "I don't understand this." What are you supposed to do with a review comment like that? It doesn't add anything. It will... It doesn't get you anywhere. So instead of that, you could rephrase it, "If this is an optimization, can you please add some comments so that we understand what it's supposed to be doing?" So it's a much nicer approach than "I don't understand this." And here, "This line will cause the function to return early," sad, smiley face, "which is bad," crying, smiley face, crying emoji, "Please fix!" smiley, smiley, smiley, smiley, smiley, smiley, smiley, smiley. There are organisations where this is totally accepted, this kind of feedback, but not everywhere. So try to strike at a slightly different tone. For example, "This line will cause the function to return early. I'm sure that is not what you intended," smiley face. Makes all the difference, I think, I would say. So what we're going to do is is I'm going to put up a third Miro board where you will see tables with three other examples that should not be used here. "Why are you using this approach? You're adding unnecessary complexity. Plz fix, m8." Your exercise is to rewrite the following comments that are more respectful and more meaningful. Let me get the URL of the last board up for you. And I will give 10, 15 minutes for you to rewrite those comments. I see somebody else asked a question as well, which I will address once I've done. Did I do it correct? No, I did not do it correctly. Better. So that is the button to Exercise 3. Oh, and there are a few questions. First, let me see if people are on. What you will see on that Miro board are a lot of tables. At the top of each table, there is a section where you can type in your name with that you can claim that specific table and that you can rewrite your piece in there. So. Yep. I see some. Cornelia claimed one of the boards, Melissa claimed one of the tables. Very good. What I will do in a few minutes, the ones that are left empty, I will move them to the side. We give a couple of minutes, a good couple of minutes for you to come up with rewrites of those bad comments. And then I will start looking at the questions. So yes, if it is okay with you all, this is while you are doing that exercise, I will try to answer the questions that have been asked. So I see that Melissa asked a question, "Developers in my company currently do the code reviews. What would you suggest to get our foot in the door and how to deal with 'You are not tech enough, there's no value in you reviewing.'?" This is a very interesting one. I had a coffee chat last week with Abarechi. I think she is in today's workshop as well. And she had the exact same question is how I would approach that and what I suggested to her is by make a list of the benefits you see of getting participated in code reviews. And I think we've touched on plenty of benefits. Like it gives you test ideas, you can spot potential issues, that sort of stuff, and discuss that with your manager. See what they think if they agree, and then they can be your advocate or your sponsor to get involved in code reviews. Thanks, Abarechi, for confirming that. So yes. And of course, show them the recording of this workshop. (laughs) Good. Okay, two questions from Ash. "If there are no unit tests with the code and you think there should be some, how do you approach that situation?" That is a good one because I think is that unit tests, yeah, yes, I strongly believe that there should be unit tests as well. But before you go into the code review process, the code review is not a way to get unit tests done as part of your development cycle, because I think that is not the right place to address that. Because that, I think it is a discussion that needs to be happening on another level, this is because I think a lack of units tests shows that the organisation is not following proper software development principles. Yes. Okay. Yeah, yeah. That is a bit more context as is here. But sometimes they are missed when under pressure, for example, then I would refer to saying, "Hey, I've noticed that for this change request, there are no unit tests. Can I ask why?" So, yeah, you're giving, oh, we were under pressure. You could say, "Should we add a ticket to the backlog to retrospectively add unit tests?" Maybe that's an approach. Definitely, I would leave, yeah, make a comment about it during the review process. "Hey, I've noticed that there are no unit tests. May I ask why unit tests have the benefit of," blah di, blah di, blah di, blah di blah. Yes. Be respectful. Because if you want, okay, not saying that developers are toddlers. If you're saying to a toddler, "You haven't done this, you haven't done that, you should do this, you should do that," it doesn't always work. What is a code review? "What if a code review is for hundreds of files, which doesn't happen, unfortunately, what approach would you take?" First of all, if the person that put up that code review doesn't put a disclaimer in the comments of the PR, so this is a very big one because of such and such, but we had big code reviews, and what we suggested there was instead of everybody plotting through it on their own, we've asked the developer to organise a walkthrough of the code. So we spend an hour, the developer explaining the changes, and then us commenting on it. So sort of an in-person code review process. Okay, Melissa, see you later. I see that you have to drop off. Cool. So yes, as a person putting up the review, with lots of files and lots of changes, I expect that they put in an explanation of why it needs to be so big. And then as a reviewer, if it is not done, suggest if you can do an in-person walkthrough, slash review session. Which I must say, worked really, really well in our situation. Even we've done it remotely and it worked great. Good. Glad to hear this. So yes, definitely big, big changes. Definitely, that is a code, that is bad code reviews, Mel, yes, I totally agree with that, as you said. Then highlighting that fact also, hopefully, will learn for the people to put code requests forward in a more manageable chunks. Last question, Cornelia. "What could I do if I sometimes feel that a person I'm doing a code review for doesn't want to hear my feedback or seems like he/she, because of his/her more advanced career and he does not want to come along with my suggestions yet?" That is a good point. Then again, I hope that you can discuss that kind of stuff and behaviour from your colleagues with your manager. A manager should be a person that is your sponsor that can advocate for you, that you should be able to see them as an ally in that. If the working relationship is good enough, you could ask the person that doesn't... Okay, bye Tracy. Thanks for dropping along, coming along, I must say. So, yeah. What I was going to say, if the working relationship is good enough within your organisation, ask the person, the more senior person, why your suggestions are not listened to, and have that conversation. Because if they are willing, they will explain. And that is a learning opportunity then for you as well, I suppose. Okay. I'm quickly going through here. Getting close to the 99 minutes. I hope that you will all be able to hang on for a bit, wee bit longer. Just going to look at some of the stuff that has been written. Yep. Good stuff. See if I can, if there is a possibility to delete the empty ones. Maybe I was a bit too ambitious with creating all the tables. Okay. Okay. Now let's see if I missed. Good. Come on. Oh, because that, okay, I see. Good. (laughing) Okay, good. Let's go review the, recap the exercise. I had a good look. They are all great. Great. Great rewrites. So I would invite everybody to keep on the board or keep a link to the board. I don't think it should go away. And written in your own time. This made me really laugh as well. I think it was Ash. "Plz fix m8." He's double down on it. This, "M8, you've done gone and busted this bit. It's not." (Peet laughing) I like that. So you just rephrasing the sentence. "Can you add some comments to clarify your approach, please? It will help the next person who might need to change this area." Fairly, fairly sensible thing to rewrite. Here, putting it with some questions. "Tabs should not be used here" statement. And that is something that Lee has put in. "I don't think tabs can be used here. Is that correct?" Question mark. "If so, what format is best?" Yes. And if you've got coding guidelines, you can refer to them. All right. So not sure about this one. "Oh God," this is, not sure if that is the best way to start a review. (laughs) Leaving that bit out, then the rest is absolutely on point. "I'm struggling to understand this. Can you go through this please to help me understand? I'm finding it complex." So, yes. Okay, "Plz fix m8." I've noticed this possible issue in your code, was it intended to be done this way?" Very good. So then you're opening it up, this is for the person that put up the code to explain. So thanks for that, Jeff. As I said, there are plenty more. I'm conscious of time. So I will have a detailed look at them later. But I would invite you all to do the same. Have a look at them. There are some really good rewriting styles in here. Yes. So thanks for that. This is, so I see... Okay. Ritchie's saying one quick suggestion for when you have a fair few negatives. Also add some positives in. Yes. Yep. Very good one. A feedback bug. And that's the thing to do. Positive, negative, positive. Yes. Yes. It is marked. This is peer reviews in person, or one to one, this is, yeah. Can work better in silos, but the organisation you need to be tuned in for that. The text is interesting that British people speak. Cornelia recently participated in giving and receiving feedback in the sandwich method. Oh, it's not considered a good approach, instead negative and positive things should be brought out separately. But, okay. Yes. Yep. Yes. Comes down to people's preference and what, again, what is accepted within your organisation as well, I suppose. We are on the home stretch now. So let's wrap this up. As the title says, let's wrap this up. So I hope you all enjoyed this workshop. I am aware we've gone a bit over time, but I blame you all for that because of the great input you all gave today. But just a reminder of the things where I believe a tester can benefit in getting involved in code reviews. So for yourself, it is a great source for defining test ideas. You're catching potential issues early, which benefits your project, benefits your organisation. And it will improve the relationship with your team members. And, last but not least, it is always a great source for learning for all people involved, for the people giving review because you get to learn the code more, but also for the people that put the code up for review, they can learn a lot from the feedback that is given on their piece of magnificent code. And that is it. Again, I want to thank you all for joining in today and for the really good participation you have done today. Wherever you are in the world, if you're in the UK or in Europe, have a great evening. If you're in the US, have a great rest of your day. If you're on the other end of the world, Australia, New Zealand, have a good start of the day, and I will catch up with you all at some point in the future.