Hell of a Tester

Want to measure employee engagement? Here is one way how to do it: 1. Measure by a survey sent twice a year But what if people just happen to have a bit sucky day when answering? It can cause quite a distortion.  2. Base it on one question that is: how likely is it that you would recommend the whole company as a great workplace People might be very engaged on their work and/or in their team, while thinking that overall the company is not as good a place to work in. 3. Score based on  NPS  grading Using NPS when everybody knows the valuation behind the numbering distorts the overall grade. 4. Say it is  voluntary to answer but give a lot of pressure to get a 100% answer rate Like, why do stuff like this? 5. If the team score is finally too low, threaten it  by certain negative actions I can't even... (If this sounds a bit too specific to be a general example and more like a real life experience, you might be on to something) An alternat...

Should all testers learn to automate? Or shift left? Or shift right? Are the wrong questions. The correct question is, should everyone in the team do what is in the long run the most valuable thing to do for the good of the team & product & customers.  The answer to that question is Yes. This is the question you should be pondering, when thinking about what and how to do stuff.  This is the question you should be pondering, when thinking what you are best at, and how you can best help the team.  Forget your role. Forget the hype.  Instead ask yourself, what should I do now that will in the long run provide most value to the team & product & customers. Then (learn to) do that. And you are going to do great. Now, and in the future.

I've worked in quite a many places, all having different levels of hierarchy and bureaucracy. I hate that stuff. If a team needs a tool that they think will help them to do better work, why do a "request" from some manager not let the team decide? If a team thinks they would benefit of a new coworker, why let a manager decide who and where to hire and not the team. If team members think they want some yearly reviews, why not let them do those themselves (or just skip those and do something else instead)? And if there are issues why not let the team sort them out, instead of waiting for a manager to "do their job". The more I've worked, the more I've started to think that good teams should just be allowed to do all this. Give them the freedom and responsibility, and expect great results. Lead by providing resources, giving feedback, communicating about the vision. Let the team decide what to do, and how to do it. Let people work to their full...

Our normal work week is currently organised like this: Monday morning, and the #weeklyStartUp We start the week with a short 15 minute meeting the whole team (20 people) participates, called "The weekly startup". In that meeting we go briefly through our main goals for the week, and decide in which kind of work groups to solve them. People can themselves decide which goals they want to work with, and based on that we decide our work groups. This goal list is a one page google doc with 5-10 goals, each written in the format of Do what , in order to get why accomplished. And the goal list is not meant to include everything anybody is going to work on, just the most important goals. We allow and expect people to engage on various other things too, as long as those won't come with a big expense on the main goals. Monday-Thursday, we work Work groups have full freedom and responsibility to plan, implement, test, deploy, and communicate what they believe is nece...

Our team has a practice of dynamically splitting down to work groups to solve different goals. Grouping happens through our normal weekly process , respecting these common ideas: ***** 1. Each bigger task or project should be done within a work group of at least 2 devs + qa + ba Because we believe that in the long run it is through teamwork that we can “deliver fast and with good quality every time” ***** 2. Work group is created based on (suggested) people voluntarily deciding to work on it, but still ensuring enough competence. Because being able to affect on what you work on is good for your motivation. And motivation is key. ***** 3. Work group is responsible for deciding, planning, implementing, and releasing the next most important task(s) on the project. Giving freedom and responsibility to the people who know best. ***** 4. Planning is done with whole group; when needed, when starting on the next task(s), or if there is a need to do some planning. “P...

Uncalled because we all already know this right? As great people such as Cem Kaner already told us about it a long time ago http://kaner.com/pdfs/PracticalApproachToSoftwareMetrics.pdf Uncalled as I haven't used these in years. Written because I was just asked by management to report product fault statistics. Using any sort of defect/bug/fault count related metrics in sw development is harmful. Bug counts fall apart already as they are trying to quantify something that is inherently qualitative. Additionally they make people focus on reporting problems rather than solving them. And really bug counts tell nothing about the product that involved people wouldn't already know. The only thing good in bug statistics on sw development is that it gives test managers a very easy way to provide meaningful and professional looking but totally hollow metrics.  And that is not good. Using any sort of test case count related metric in sw development is harmful.  ...

I don't report bugs . Bug is such a loaded word that people understand very differently, that instead of using it and explaining what I mean by it I rather just use other words. Like observations, thoughts, surprises, ideas, alternatives, or something similar. (And no I don't use fault, defect, or error either). Bug has also quite a negative connotation. "Reporting a bug" is kind of like telling someone that they've been served. And as we are actually giving away the gift of information, why wrap it in such a nasty package? And maybe more importantly it is very likely that whatever you might have to say is wrong. If not plain wrong, then at least incomplete. So I like to approach the kind of situations with the assumption that I am probably wrong. Cutting off anything that might sound arrogant makes stuff quite a lot easier. Especially after you realise later on that you have been wrong. I leave plenty of observations unreported . I don't want to waste...

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

This post continues from Mob programming - the heaven of a tester. Part1: the beginning . I will next describe the formula of a rather common and a rather good mob development session. It consists of four parts; The initiation, The planning, The implementation, and The finishing. _____________ 1. Initiation We started arranging the mobbing sessions by booking a few 2 hour slots for the week ahead where our aim would be to do some work in a mob. This was especially important in the beginning as the mobs did not seem to happen adhoc. Even if pretty much everyone always liked and wanted the mobs, people often did not arrange them by themselves. So this kind of forced us to do the stuff we like to do :) Now after starting to make mobbing a habit, and starting to understand where it is especially effective, we have gotten better in initiating mob sessions ad-hoc. So these days it is the most common way to start implementing a solution for problems that seem hard to tackle, on som...

Have you heard of mob programming? Probably you have. If you haven't I stroooongly recommend you to take a look (https://youtu.be/8cy64qkgTyI) or listen (https://soundcloud.com/cucumber-podcast/mob-programming) to Woody Zuill describing the process. My team has been doing mob development (we call it rather that than mob programming) now for two years, and it is superb. We don't do it all the time, but when we do it is inspiring to be part of a mob. And I think it is very efficient too! Also in my role I have several reasons to argue  Why every tester needs a mob (and ever mob a tester) , and I want to tell about what usually happens in our mobs , but those are future blog posts. This time I will tell the story of how and why we started mobbing. I first heard of mob programming from Woody Zuill in Tampere Goes Agile conference 2014. It sounded kind of crazy, five people working on one machine, but at the same time many of the things I heard really resonated. So I was intri...

Here's another chat I have had many times. It starts with the golden and notorious question of "how much should you test". And it then drifts a bit from there. ******** How much should you test? "Well, you know, I used to work once in this team doing a medical device where releasing frequently was not really possible due to the many constraints. And even doing a small release would cost a lot . And it being a class C (death or serious injury may occur) device all issues found on a released product would have been a pretty big deal. So this meant that we took unbugginess very seriously, and thus that I had a lot of time to spend testing the device. And boy did I. I spent sometimes almost like the entire week just in front of the machine testing, thinking of ways how it could fail, unrolling all the test techniques I got in me, learning the ins and outs of the product. And then one day when the new release was done.... several problems were found. So taken ...

I share this story every once and then when talking to people, so thought to write it here too. About 8 years ago I had got my second consulting gig, working on a big company and on a huge project. And as huge projects normally go it was already very late and presumably very over budget. This had caused a pretty tense atmosphere around the project and things that delayed it further were not looked very fondly on.  And so it happened that I made a mistake of that sort. It was kind of done by a person I was "coordinating", failing to provide a complete set of specifications we had worked on to a vendor, resulting in a release missing a lot of important stuff. I was very stressed being a pretty new kid on the block and considering my options, whether to lay low, blame the coordinate or the vendor, quit, etc. But in the end decided that I would go for admittance. So I walked to the office of the rather intimidating program manager, knocked, went in and said that "I messe...