Hell of a Tester

  "You got nothing, not a single thing?! Well lets just end this here then." I remember well when I said this, being very frustrated. About ten years ago I had been working as a Scrum master for a team some months, and putting quite a lot of effort into planning our scrum teams sprint retrospectives. Lot of work also because I felt we were not getting too much out from them; not very good discussions, very few actions, and even the few actions we did come up with did not stick.  And then it happened: a retro where none of the participants came up with anything to say about the sprint. Regardless of the retro topic boxes, reading of books on retrospectives, getting inspiration from tools like retromat.org, having them in different places, using all kinds of different formats and rainbow coloured post-it notes. Not a single thing. Blank.  So then I said the words, out of frustration, mainly to myself. Why couldn't I get this thing everyone is so hyped about to work? Af...

  I lately was asked to participate into workshopping in creation of "career paths and titles" in a software development organisation. I have seen a few. Some with a lot of work put to them. And all wrong. Is it them or me? Definitely me. That's because I don’t in general like titles, the way are assigned to people. I think it would be more reasonable to discuss the responsibilities a person has and things they do, periodically. And help everyone pick a title that describes this well. And adjust it whenever they want. Seniority is also a hard concept. Is it about years in field? Or years in life? Or about specific knowledge, or knowledge in general? Or about the successes and mistakes you have been part of? Or on how you treat yourself and other people? Or on how you compare to another random coworker? I don't know, and maybe I don't care. Why other people do, at least because of the money. And the way salary raise is usually tied up to a promotion. For that I hav...

Attended a week ago the Frogs (friends of good software) online unconference https://frogsconf.nl/. Unconference type of events are these days pretty much the only type of conference I wish to participate. They almost automatically establish what many more traditional desperately try - discussions and interactivity. Frogs was no exception, and was also extremely well organized. It followed a typical unconference/openspace format, of creating the content and schedule of the conference in the beginning, and then people attending the ones they find most interesting. The conference organizers have background in testing/qa type of work, which is why there where a lot of testing minded people attending, but happily there were also a lot of people from different backgrounds.  We were using Welo as the platform for the unconference and it worked well, allowing you to move virtually between rooms and hangaround places.  Depending on the timeslot, there were 3-5 topics happening at the ...

Are managers valuable? Or useless? Or harmful?! I can admit that during my 17 years career in sw development, I have developed sometimes a bit cynical view on managers. And therefore a sound interest on ideas around not having any, like teal and holocracy (although I am not a big fan of those either 😀). Cynicism comes from managers who think it is their job to make decisions for other people. Decisions like what information to share and for whom, who to hire where, and how to do things. So decisions which mostly affect other peoples work. And these type of managers are not just useless, I think they are extremely harmful. I'd rather take a manager that does nothing than this type of a manager. But I've also had privilege to work with managers who advice, share, participate, challenge and empower. Managers who get the best out of teams and individuals. Managers that give me hope. My question to all managers is: what type do you want to be?

  "Does everyone have something to work on?" Is a question I sometimes hear from a product owner (or similar role), often in the end of some planning/coordination meet. And I consider it a big red flag. As it is an indicator of trying to keep developers busy and attempting to get a lot of tasks and features done. Which is not the goal. The goal is to maximise the impact of the team for delivering long term business value. So instead of "is everyone busy enough", I'd suggest to try rather asking something like: 1. Do we agree that the work we have planned and prioritised is meaningful and valuable based on our current knowledge 2. Can we somehow assess and evaluate that later on 3. Are we excited!? And then as a team organise and start to work around those goals. Yeah it will be harder, but a lot more engaging. And yeah you will not get as much features out, but you might just get the right ones.

There often seems to be a thought around sw development especially in bigger orgs, that if you plan something very well it will be then easy to allocate the work to individuals in a team, and then fast for them to do. And that way you can get plenty of "tasks done on a sprint". Which may be true. But forgotten are the months the thing has been "planned" in various ways.  And forgotten are the hours and days of planning things that eventually never even get done.  And in the end, forgotten are the goals and impacts one originally hoped the product to achieve. Instead of all this effort planning it would be often way more effective to spend the time to clarify and generate shared understanding on the objectives of the work. And then let the team do the work with planning, implementing and analysing being intertwined activities, focusing on the impacts you are aiming to achieve.

I got to listen to a discussion today where a topic was if a team kanban board should have a "ready for testing" column. I am happy that the discussion ended with the decision not to have it. I am happy on that because in the world of software development, testing is  not a phase to happen somewhere after programming and before pushing something to production.  If/as testing is about raising good questions, seeking answers to those questions, and about exploring risks and opportunities - it should happen all the time. From the beginning when  thinking if the thing should be built at all, into the end when analysing and observing the actual impacts. Everything that happens between is about doing, and any extra column, phase and handover you create inside this is going to hurt you.

Prologue: One of my most important roles currently at work includes responsibility on improving our ways of working. Yet when I am asked by someone on what I believe is a good way of working - I have trouble answering in a simple manner. Below is my attempt to answer it. 

Been noticing two a bit conflicting themes lately. 1. Testers getting (or pushed) to be more technical and write test automation code 2. Articles listing future IT core skills as widely non-technical So whereas many testers are moving to work more on test automation, the vital skills of the future may be such as: - Creativity -  Analytical (critical) thinking  -  Activ e  learning  with a growth mindset   -  Judgment and decision making -  Interpersonal communication skills - Complex Problem Solving Which sounds almost like a list of vital skills needed for an exploratory tester.  So we should perhaps remind the ones starting a testing career or moving away from it, that also these skills are something that can be quite valuable in the future as well. Maybe even the most valuable.

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