Sunday, May 13, 2018

Six reasons why testers should do code reviews


I have had quite a lot of discussions about code reviews. Quite many also with testers, by which I have understood that many do not do those.

I will not start arguing here on whether code reviews are good/important or not. But I will list a few things why I think testers would benefit of doing them.

1. Code is the only documentation that is up to date. If you really want to know how something really functions, you want to be able to see and read the code.

2. Knowing more about the thing done enables you to do better testing. You can spot things that you should definitely test, and things that you probably don't need to test that much. Like extra things added by coder, usage&modifications of existing functions, data types, etc.

And to arguments thinking that one loses their "independence" as a tester by knowing too much, I would worry a lot less about that than about testing stuff that you have no idea on how it has been built.


3. Improve logging. I obsess on logging. I am always asking to add more, more details, and in correct levels. Logs can help a ton when testing. Logs will be indispensable when tracking down those problems in production. Logs can help you analyse the usage, and non-usage of your system to spot further improvements.

If you are a tester and you are not obsessed on logs. Why?

4. Add testability. Logs are kind of a part of this already. But knowing how stuff has been built, can help you to ask for more control on some parts, or more visibility on others.

5. Read the unit tests. In my experience this is the most overlooked place when developers are doing the code reviews. And tests are something that testers should be pretty good at... Some examples be suggesting new tests, deleting of unnecessary tests, better input variables, and stronger assertions.

6. You might spot some other things too! Asking on unclear parts may reveal unnecessarily complex code OR you might learn something. Variable names can often be better. And occasionally one might even spot some functional issues too. But I would suggest to be quite careful when offering the feedback. Asking why something was done in this way is usually better, than telling how you think it should have been done.


Not doing them and still not convinced? It might not be for everybody, but based on my own experiences I do suggest at least trying it out a few times.

No access to the source control system? Ask and thou shall be given.

Can't read the code? Read it anyway. You will learn, and get better at it. And reading good code is a lot easier than writing it. Kind of like reading good books is easier than writing them.

Other team members think it is not useful for testers to do code reviews? Hard to think that this would be an actual issue.. But if it would be, ask them to read this post and to leave a comment telling why. If they will and I cannot counter comment - shame on me. If they won't - have a good time doing those code reviews!



Sunday, April 29, 2018

10x tools #2: Clipboard history


Back with  the 10x tools journey! 

Last time I talked about the Kipling method, and this time it is turn for the tool why I wanted to do the 10x talk in the first place. The tool is so simple, yet so useful that I really would not want to work anymore with a computer not having this tool.  

The tool is, tat ta da daa, clipboard history. 

You know how mint windows & mac operating system's clipboard works. Copy something to clipboard, and it is there. Copy something else to clipboard and the previous record is lost. And that is really sucky. As a result of this, you might end up going back and forth two documents copy pasting, or have a separate place to paste intermediate stuff. Or sometimes you might accidentally copy something new and lose the previous item from the clipboard. 

So clipboard history saves you on those cases. But after using it for a while, I've started to use it for other things as well. For example when I see something I think I might need later on, I'll just copy it. If I am editing something that is not autosaved like a web form, I'll take backups every now and then with the good ol ctrl/cmd+c. And if I am deleting something, I don't. I'll cut instead and have it in my clipboard just in case. And then when I need to find "that one uuid" I used yesterday, I'll just go and find it from my clipboard. 

I've been doing more and more programming too, and copy paste is very common there as well. At least when I do it :)

So you really want one of this tools. 

These days I use a Mac, so my tool is currently Flycut - which is not that good as it has quite short memory (91 items) and it only stores text. Alfred costs a bit but will give you longer history and also images in the history + a lot of other useful things I've heard. So I should upgrade to that. 

The only thing I miss from the Windows world (on top of the forced updates and daily reboots :D ) is Ditto, which will give you even history of files, a great search, and great usability. Man I reeeally liked that tool.

So that's it, number 2 of the 10x tester tools. And it's a life changer. 

Don't believe me? Just check these user reviews of flycut from Mac appstore (try to read them in a shopping tv channel voice):
"The only think I can say about this app is as a programmer and a power user, this app has changed my life. "


"Indispensible. I must use this a dozens of times a day - can’t imagine doing without."

So why wait, get it today for free!

Monday, April 16, 2018

10x tools #1: the Kipling method


This time I'll start another series of posts (which I will not probably finish) called 

10x tools for 10x tester

which is a little bit modified version of a talk I've given a couple of times. 

The initial talk was demoing 10 tools from a wide range of categories that I use to increase my efficiency, in 30 minutes. Which is super duper fast. It was actually quite funny, because with this talk I first sent the proposal thinking that 3 minutes per tool is more than enough. But then after the talk was accepted and I started rehearsing and did in my opinion a really quick demo of the first tool, I was quite surprised to see the clock stop at 8 minutes. So I really had to cut everything extra away from the demos, and even skip demoing a couple of tools I originally wanted to. So now for the blog version I might demonstrate a bit different tools. 

But definitely 10.

And definitely 10x.

And the first one is the same as it was in the talk, called the Kipling method and combined with MindMup.

MindMup (https://www.mindmup.com/) is a nice online mind mapping tool. It's free, enables collaboration on a shared map, and is constantly getting better too. But collaboration is the key here because the Kipling method is about planning, and good planning is all about collaboration.

So the Kipling method can be applied when you have something you would want to plan a bit. Could be a problem, a request, a project, a testing task, a family vacation, or whatever basically. And when using it with MindMup, you start by writing the task into the center, and then start asking Why.


Why would you want to do this? What problem would it solve? Why this solution and not something else?

These questions are crucial. These questions can save you days or even weeks of time spent on doing something that is not needed. And these questions raise beautiful discussions. 

Sometimes this is actually as far as you get, as you might here notice that you do not know enough of the reasons behind the task, you don't get the business value, or you just plain disagree. And that is one hell of a good planning session you just had. 

But if you kind of can agree on the why, you continue to the What.



What are the impacts you would want to achieve with this? What other impacts might happen? How would you know if that impact will be reached?

This will help deepening the understanding, but also starting to think about the things and problems that the solution should solve. Can't come up with any? Or only something very vague and something you cannot verify afterwards? Impacts don't match with the reasons you came up on the why? Better go back and talk more to some stakeholders.

But if you can come up with impacts too, then you can proceed to How.





So here we can start thinking of how can we actually solve the problem. Doesn't have to get too specific here, details will come out later, but rather consider all the different ways the problem could be solved. How could you do it without any coding? What different kind of architectures could be used? What different kind of UI's you could think of?

It would be important to come up with at least couple of different alternative approaches, which could then maybe be combined. Or you might decide on the most probable or easy solution. Or go crazy and do a prototype on something totally strange. As long as those would somehow relate to the impacts discussed before.

Ok so you got this far now, and you might wantto end it now. But continue for a moment still to briefly consider other needs and limitations,




Who do you need to get this done? Who would help you in this? Who are you afraid of :D

Where can this be done? Do we have the environments and tools? 

When should this be ready? Do we have some hard deadlines? Are those deadlines based on facts? When would we start getting value out of this.

And now you are done! And you have this beautiful mindmap! 

That you can toss away.

Yes. 

Because the plan is useless, but the planning is everything (smart words of D.D.Eisenhower). 

The power of the planning comes from having many people discussing stuff together, bringing in different views, ideas, critique. And going off with shared understanding. You do not really the plan anymore, as you have the understanding. It's magnificent :)



So the Kipling method is a simple planning framework, and a mindmup is a nice tool to do this quickly on. And this kicks the shit out of any project plan template ever created. 


Oh yeah, you might wonder why do I call it the Kipling method? It comes from a poem from Rudyard Kipling called Elephant's Child, which starts like this:

I KEEP six honest serving-men
 (They taught me all I knew);
Their names are What and Why and When 
 And How and Where and Who 

alas, the Kipling method (™Anssi Lehtelä).

Sunday, April 1, 2018

Nothing helps you more than helping others


This week I dived into the drafts folder of my blog posts. There were many interesting titles that I would want to write on, like for example one with title "The crying game". It had no content and I have no idea what I have thought of when writing that down in the year 2013. But what a great title!

But this other one that I'm now writing on had some content and is a pretty dear idea for me, so I'll now finish this post I started back year 2012. And that is, that nothing helps you more than helping others.

I have had this principle for a long time now that whenever someone asks for help, that I always do. Even if I'm swamped with work and in the middle of something and someone interrupts to ask if I could help I'll reply "of course!". Some might argue that asking to come back in an hour would be better, but the bad side on that is that potentially this other person is then stuck for an hour - and this is one hour lost. As opposed to helping them out immediately, everybody can go back and continue on full force.

So I think always helping others out is a good way for the efficiency of the team. And even for you, as if you help others then it is more likely that you will also be helped when you have a problem.

My wife was saying to me while discussing this, that sometimes some people might not want to help because they think keeping some knowledge to them self could be considered an advantage. Kind of like a superpower that other's don't have. I replied that I can maybe see someone thinking like that, but I think that not helping is still more of an disadvantage even for the person holding the information. Because good ideas can always get better and a great way to improve them is to share them and let others offer their own in return. Things I thought were pretty darn good already have gotten a lot better when I have shared them to others, by them offering their criticism and ideas in return.

So helping out improves also the ideas and knowledge you have.

And then there's the humanity factor.

I was a few years ago collecting money for Unicef with my son. Me and him (four years old back then), were standing on the center of Helsinki with a small box where we were asking people to donate some coins for the sake of poor people in Africa. I was quite sure that the box would get filled up in like minutes, the cause being so good and my son being pretty cute with an over sized Unicef vest almost touching the ground - but people were just walking on by. Hundreds of people just walking on by.

I was many times on the verge of losing my faith to the humanity, but then someone came, and dropped a few coins with a smile. And it rose us so much. It didn't even matter was it 2, 1, or .10 euros, just the fact of someone took the time to notice and give out something meant so much.

So these times when I see people collecting money for a good cause, I always give something. Like 10 cents. Because I know how much it means for the people who are giving out their own time for free, in order to help others.

So even in the context of the whole planet and human race, nothing helps us more than helping others.

I'll just close this one with a link to one of my favorite Beatles songs, you may guess what it is :)

https://youtu.be/ZNahS3OHPwA


Sunday, March 18, 2018

Retro for the past week



Keeping up to the deal with my colleague Mili for the total 52 posts during year 2018, this is my sixth one (Mili blogs here http://meeleetester.blogspot.fi/).  I am not really in the mood of finishing any of my draft versions and do not have solid things on my mind that I would want to write about. So I thought to do a little retro of my past week, with the classic glad - sad - mad pattern. (nice machine to help coming up with other ideas to retro's here https://plans-for-retrospectives.com/ btw).

Here goes:

**************
  • personal retro week 11
    • Sad
      • Had to spend very much time on solving issues and questions coming from support and stakeholders
      • A lot of people away from office this week
      • Meal on the lunch on new restaurant sucked
      • Few things on "my own backlog" stuck the whole week
      • Lost a query to a report I did couple of months ago
        that was asked from me again, need to redo
      • Could not do the mob programming sessions I had booked
      • Another problem with Git (root cause was that I had wrong branch as base)
    • Mad
    • Glad
      • Was able to squeeze in a few hours doing some programming on improving an existing feature
      • Tried one new restaurant for lunch
      • We were able to get quite a lot further with the goals in the workgroup I'm in
      • Was able to test and provide some feedback on some things done quite quickly after done by dev
      • Sent out a team stakeholder satisfaction survey, and got high grades on it
      • Came up with a maybe funny idea on a presentation I will give in two weeks
      • Survived one very hard meeting, and got good advice after it from my team members
      • Got help on a git issue once again
      • Tried kanbabflow as a kanbanboard for a workgroup I am in, so far like it
      • Got help from a team member to understand the reason why another one was maybe upset
      • Nice interactions with our support team
      • (https://www.mindmup.com/ copying the mind map and pasting it as text comes out as a really nice bulleted list. And also the productivity beta version works nicely

Then a few possible action items for next week:
  • Arrange a meeting for showing how I regularly work with support support (with some example case), invite the whole team (or maybe two meetings people split to two) as optional in case someone would like to help there a bit
  • Push some of the things from my "own" backlog for the team to look at
  • Book new mob sessions
  • Start saving the queries I use more often to the useful queries file I have in git 
  • Choose some implementation task for next week too
  • Book a retro for our work group til the end of next week.
****************

That was fun! And I feel a lot better from the past week, and looking forward to the new one :)