Hell of a Tester

Improvements in how things are being done don't help that much if you are doing the wrong things. Focusing on cutting down the deployment/production pipeline, using the latest and greatest languages and tools, exploratory testing, mob programming, etc will surely be a boost to efficiency. But efficiency is not key if you are doing the wrong things. And quite often we are. And a big reason for that is, that we suck at prioritisation. We suck at it because we: - spend too little time on it: "But we could save minutes of talking by hours of coding!" - do it too rarely: "Welcome to our annual roadmap revision meeting." - try to have specific people/roles be responsible for it: "Ask the PO..." - do not think about different dimensions enough: "But the customer needs it!" But mainly we suck at it because it is so hard. Here tho is list of 10 things I think might help. 1. Don't keep a big backlog. Focus on the things being done ...

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 obse...

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 ...

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 met...

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...

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 (...

I've been thinking quite a lot about tester's moving to do test automation.  Lately beause of these three things: 1.  European testing conference , a great testing conference I attended couple of weeks ago. It is very cool due to many things; the way the speakers get compensated, the focus on the conferring side of conferences making it very easy for people to discuss stuff, the way the talks are chosen, and because there are also a lot of developers joining. So anyway when I was talking with several of the attendees, it was a bit strange how it was easier for me to talk about the product development as a whole with the developers, where as with the testers it more naturally moved into talk of automation and tools. Also on the open space, I think the majority of the topics pitched was automation or tool related. And quite little on the process or on the customer facing side of product development.  2. In my company there are a lot of different products and...