Bad testers and the power of words in turning things true

Here's a twitter-inspired post. A visible discussion seems to be about anyone as tester, and I felt I need to also write down some of my thoughts. For the inspiring originals, see:

• http://jarilaakso.blogspot.fi/2014/04/anyone-can-be-bad-tester.html
• http://www.morethanfunctional.co.uk/1/post/2014/04/anyone-can-be-a-tester.html

I found it interesting, that I got a feeling of being offended from the title Jari selected - adding the "bad" qualifier - whereas the other one saying anyone can be a tester did not offend me. Reading the texts, the first one had all the potential to annoy, with the style of remarks. I found myself feeling more sympathies to the message saying that anyone can be a tester. I've dedicated all my career on being a professional tester. But the troubles I keep experiencing are not about my skills, but about our common attitudes and skills in testing in the teams I work.

The organization I work for realized they could use a professional tester after 20 years of developing software without a dedicated / skilled tester. As I joined and pair tested with people, I learned a lot about attitudes. A developer told me that he is "too valuable to test as he can code", completely missing out on the fact that the people who he deemed less valuable were the direct source of incoming money paying our salaries dealing with sales and other customer-facing support, and time away from that work isn't what the organization needed. A product manager told me he hates testing, because no one likes the results and it's always stuff to do on top of all the other duties. In general, I entered a place where everyone was looking for excuses not to test.

As I started my work, we soon learned there was something I do differently to see problems that others miss. And as I was deemed 'good' at testing and everyone else got confirmation they were 'bad', the situation just got worse assuming all testing should happen in the realm of 'good' - why waste time on doing the work with 'bad' skills.

I've spent a significant amount of time emphasizing that everyone can test, and everyone should test. Some of us are better at it, but every one of us can get better at it given the time and focus, and believing it is possible. I would hate the idea that my developers and product managers would hang out with testers who emphasize how they are 'good" while others are 'bad'. Realistically, I'm not good at everything in testing. I get better by actively learning, and learning happens often with people with diverse background. Setting a label 'bad' on some testers becomes a self-fulfilling prophecy. I'm bad, I can't get better, why bother even trying? I feel that in software development, we need to put effort into removing excuses of not thinking about flow of value from idea to use, and emphasizing we absolutely need dedicated testers to do testing has been one of those excuses. Could we emphasize the need of professional testers without making that the center of the message?

Everyone needs to be a tester. We need everyone hands-on, empirically experiencing and thinking from different perspectives. Some will be better at it than others, but only through doing we improve as teams. We can't ask developers or product managers to distance themselves from testing as there's someone else better at it - and often later in time. Time is important. And attitudes count. Simple bugs are simple to be found. Many of them could be spotted if non-testers would feel they need to test while working through the requirements and implementation. I hate the experience of simple bugs being caught over and over again by the professional tester, just because others don't care about testing.

As for professional testers, some of us enter the cycle of realizing they are good at it, spending time on it and getting better. We might also learn that its fun, needed, important, useful and valuable work to provide information on quality. As professional testers, we enter new domains (at least I do) and learn the domain in layers, to get from simple quicktests to in-depth understanding of customer value. We learn this from domain experts, with significant effort on learning, but in a style where we can already test before we're fully into all the aspects of the domain. Domain knowledge does not come automatically just because I'm a professional tester.  The domain experts could make better testers of that area while I don't have the domain knowledge. But, they also tends to have other duties that stop them from using their time of testing, without that making them 'bad' testers.

Here's an example of building the domain expertise. About three months ago, I overheard developers saying that my team's remote tester could participate on a new feature, but it would be June before she is able to contribute anything useful, as the domain of that area is pretty complex. The domain is energy - electricity, water consumption and the kinds - and the tester has absolutely no background in the domain. However, she has a background in mathematics. She has a curious mind, and ability to create models, deduct and ask for information.  On the first month, her testing would see simple things. But after three months, everyone in the team acknowledges her as a valuable member, saying they could not get this done this way without her. There was no option of asking all the others to learn hands-on with the product as much (testing) - we would have needed an extra person's effort on the team anyway. The product managers could have done what she did. But there was no product manager with the info and enough time available. But there was a good and skilled tester available. And we should be glad there was. It's not just skill, but it's also the ability to use time to build that skill to the most recent details.

Everyone can and should test. Not everyone is equally skilled in in. Even the professional testers are different. Every day is a learning opportunity, for all of us. And with that idea directing me as tester, I am better, every day. Saying someone is 'bad' is unfair and cuts down motivation for those who need to learn. If professional testers get offended with the idea of being unneeded, are we supposed to reply by attacking so that others feel as bad as we do?

Collaboration review - take the driver's seat

I had my collaboration review today. You know, the annual routine of discussing how you did and how you will develop, the routine that I'd prefer to just become a natural way of how we work together continuously. And as usual, as I want things to be different, I tend to take them differently and pretend I don't know how others do it.

As so many organizations I've been to before this, there's a form to fill out that presumably guides the discussion. The bits in the form are supposed to be filled in collaboration with your assigned manager, and they include points like feedback on the previous year. 

What I enjoy most is taking the routine where someone else plans my future with me into my own hands - it's my future anyway. So I stopped to reflect on stuff I've done over the past year, things I've learned and things that I keep on avoiding.

With the feedback taken care of (doing good job, and my enthusiasm to seek better ways is still surprising to my manager in the difference to the status quo he is used to)  we quickly moved to talk about stuff I would like his support on.

With my preparations, we walked through areas of my work. And as a result, I draw up a silly picture of it.

 

What I mostly do is testing - with the recent changes, finally with a focus of delivering continually whenever a feature is ready. Continuous delivery is new for my team, we just started with that this week so that will be still the baseline of a lot of what I will do this year. I work with test perspective before implementing anything, and will help with feedback while implementing so that we complete the delivery together. The 'before implementing' seems to be a bigger challenge with us, with a short-term history of delivering the same thing a few times as we learned together too late. I'm pretty comfortable testing and would seem to deliver value in the team in just that. Yet, the application and our implementation does not bring me so many learning experiences right now, more on repeating the lesson on the difficulties of making the choices of what to spend time on and how to track what I learned by now to build on.

On top of that, what I need to work on is my skills on helping the team change its culture. People are much more difficult than our application and how it would be tested if I did the testing. We have somewhat of a role-based idea to software development, where developers do just implementation and I need to continuously work with practical ideas of how we could not assume that the one tester (me) will do all the testing. We'll need a bit more of team building and goal setting work, and it was nice to notice that a team building budget can result from discussing how this goal of mine could be supported by the organization. 

Another area that I felt I wanted to seek into my goals is working on how we measure value delivered. I want to work out ways of seeing if (and to what extent) we're actually delivering valuable features, to move away from counting the tasks. In the last year we've learned that being busy and delivering many "Jira issues" may not tell anything about the value outcome - especially if we redo same things over and over again. Learning to talk about value we deliver might also help with breaking the silo thinking that keeps popping up. 

Third area I brought on the discussion was that I will start coding with the team. Reviewing the code, adding unit tests, and adding features. I realize I will be limited with this, as the trouble still is that while I test I see problems that are there, and others in the team miss them. And I will do much of this by pairing with the developers, who refuse to pair on stuff that I currently do "my way" - exploring. But taking this into my goals of what I do will help me with two things that I hold dear: I get to prove a point of skills being learnable (if I code, why the developers couldn't keep their eyes and mind open when they test) and working on the automated checks on a level where we as a team can't escape into the "task is done but the value isn't delivered"-mode we so easily slip into. 

The final bit on my things to do is the smallest: I wanted to reserve time this year to work out how to run the basic security tools on our software. 

I look forward to another great year of learning. Apparently I'm the only one in my team who actively sets their own direction and negotiates on the contents of the work, but I also feel the reward is that I do get the support I need from my manager. No magic wands available, but a helping hand and perspective.

Reading and writing code could be two different skills

Yesterday's workshop 'Brutal Refactoring Game' left me thinking about the regular discussion about testers coding skills. The workshop was about writing beautiful, well-structured code. While I consider myself a non-coding tester, I've done some programming in my years in software development - I still keep realizing that with all the things I could learn that are related to testing, programming isn't that high on my list.

The workshop left me thinking about my relationship with code.

We were supposed to pair up to create tic tac toe -game. With the first smell note of 'no code', we (a team of two testers) googled up a solution to copypaste, knowing that the next smell note would be lack of tests. And that the idea of the exercise is not to show copypasting and googling skills, but actually learn stuff on programming.

We looked at the solution we had, with the idea of adding tests and changing the code so that tests would be possible. We could easily read the implementation, we could see it was not beautiful in how it was structured. And that adding tests on that structure would not be a straightforward task.

We started working with our own solution, to run into problems with inexperience with the actual coding part. So again I faded out to googling, looking at examples with tests. I found some really nice implementations that were a pleasure to read.

I realized I do this as part of my work regularly. I read code, usually with the purpose of understanding what is included to guide particular ideas I would test with. Reading code is not that difficult and it gives me a lot for the testing. I don't read the code to cover it, but more from the point of view of understanding complexities or exceptions, and the scope of the actual implementation.

Just like with the workshop-time googling, I feel I recognize good and bad, and different styles. With the bad ones, I can tell why it's bad (againts a set of expectations I've learned) but it's clear I can't do it better myself. I feel awful when this happens, to a scale that makes me not speak out loud  about it depriving the developers the chance of feedback. Instead of talking about the code, I turn to using the software and showing problems the code has in execution.

So just an idea: could reading and writing code be two different skills, and when we talk of testers needing to code, reading - even shallow reading - might be sufficient? Feeling apologetic for what I can and can't do isn't helpful, and just leads to not optimize what we can do in the team together.

I think I'll try actively doing more of code reviews and talk about my perception with the developers. My lovely team mates would appreciate my effort regardless of my inability to tell how that should be.

Are we all selling our time or is contracting different?

This post is a longer version of a tweet I posted earlier this week: "How many times can a contractor sell a full-time tester to different projects without losing trust? I'd say one is enough. Need to blog."

In a way, we're all contractors selling our time. As a full-time employee, my company expects to have 37,5 hours of my dedicated time each week. Some of the employers limit my right to do what I want with my free time. And some appreciate that I mix work and hobbies so that a lot of my self-development happens outside project work and office hours. I happen to be employed at a company that is fine with me selling my free time for other companies for money as It was part of the contract and salary level we negotiated when I joined.

We realize that splitting focus is just that - that it can and occasionally will  - lower my presence and focus level even if the hours are full. On the other hand, from fullfilling my needs of autonomy and self-development, there can be support and extra energy  available for the working hours.

On my usual month, my choices bring me to 'selling' 60 hours a week for different types of work. Some of it is paid by different parties, and some is investment into building my professional path that may pay back eventually but also serves other purposes.

With years of practice, this model works for me. I'm happy and convinced I have a career.

While I, on individual professional's level, am fine with how I organize this, I find the very same issue to be different from a contractor (group of employees and employer) point of view. If I, in the role of a customer, contract for a monthly fee a full time tester of 40 hours a week, I don't expect to contract someone like me selling 60 hours a week unless I'm told that. And when I'm told, I can address if I want that.

The employee I'm contracting for may be just as ambitious as I am, and think that their free time is theirs - as it is - and just make sure the hours for contracting are in the right slot and the other stuff happens after hours.

The employer however, has a contracting business to run and develop. With an atmosphere of mutual ownership of the company's future and personal learning emphasis, it's easy to justify other projects on the side. As employee, you might do those with your free time, but from employer point of view, your free time generates profit or is investing into the future the company would hopefully make money of later.

The customer unaware of the level of things that happen on free time, expects your focused effort. And may even believe in 'sustainable pace' and limits of hours anyone should be encouraged to put in.

This all leads me to think that in contracting customer relationship, you need to manage the expectation of what your employees will do on their free time, just as you need to manage the expectation when you sell yourself as an employee. When the customer learns that the person fully allocated to you is now part of a new business of doing trainings, drawing the conclusion that this is the employee's free time used to run employers business feels like a stretch.

From the employee point of view, I support following your calling and taking side tasks that increase your energy. From employer point of view, there's a risk of being half there in the project that needs managing.

Losing trust is easy. To give back trust that was lost, I needed to talk about this in detail. I trust the tester to assess her ability to juggle many things, and I trust she will lower her hours somewhere if it's all too much. But I also deduct from my personal experiences that it takes a burnout to know what leads to it, and feel it's the responsibility of seniority to bring concerns for the younger bright mind to consider.

I still struggle with this, which is funny. I'm fine with myself doing long days for a long time, why is it that I'm not fine with the contractor's employee doing the same?

The little thing that made my week

In last months, me and my remote tester have ended up with different products. I'm still the test manager for the product the remote tester works on, but I've cut down my hours to a level where I spend no time testing. Then again I spend most of my time testing without managing anyone in the other team.

At EuroStar 2013, I pointed out to the remote tester (face to face time, nice!) that I feel alone with the developers. I'm considered the odd one as I like - LOVE - testing and the puzzles that unveil while testing. And on the two teams with 15 developers, the connection with developers just isn't the same, it's great too and built around purpose of the product. But none of them gets excited about testing.

So we agreed to spend half a day testing together, with a talk connection open while we test the same thing. Every second round is devoted to each product, and the session theme comes from the one that spends more time testing that particular product.

We've been doing this for two months now, and for our latest session a developer had a perfect timing. He asked if we would by any chance have some time to spare on testing an area he refactored and if he should even check it in at this point. We agreed that the only way is forward, and he mentioned he'd spend the next few days doing own testing. I promised to find time to help and talked about that to the remote tester. She immediately suggested that the side-by- side session on her product should have that change as the theme. Mentioning this to the developer, he went apologetic telling he has not tested that completely yet, as he's been told our process works. But he committed the changes and was happy to get the perspective he asked for.

We tested the area and found problems. And the developer fixed them, right there and then. We got a nice idea of the state of the area, and while the dev might have found some of the issues himself, I was glad he didn't. It felt like we were actually working together, instead of being forced to be the ones who told the developer that his best attempt on testing just did not do the trick.

Towards the end of the session I realized there was an opportunity to invite the developer to listen in to us debriefing what we had covered, and he seemed happy to join. In a short meeting, we told what we had covered and identified as areas of more focus. And agreed on how to go forward.

It was a great experience. The right timing, the right collaboration. And left me wondering: why don't we manage to do more of this? But the story of this experience worked great on the manager who tends to think that saving my time is more important than great flow of collaboration. So, I'm hopeful.    

Careers on coffee table

Coffee discussions seem be good food for thought. My company / colleagues have a principle of not talking about work, so we talk about all sorts of things - sometimes related to work. Today the topic turned out to be career - or sense of missing one completely.

As the remark of no career for a colleague made me curious, I had to ask how he defines career. With the answer, I learned that he joined the company (medium sized company) quite a number of years ago, same time with other people still in the company as a summer trainee. He felt he did the same job as programmer then and he does the same job now, whereas the other people who joined (traditional engineers) have had first more responsibilities in design and customer relationships, and later become managers. And he keeps on coding.

This left me wondering how strongly the idea sticks of career ladders always leading to management positions. And, how differently we perceive career - in particular the personal responsibility to one's career instead of waiting for it to land from somewhere outside.

Personally, I've felt making progress in my career for many reasons - ability to learn and to turn the learning into more effective (team)work in development being a core to it. The discussion made me dig out a slide I put together years ago on how I perceived career back then.

Looking at the categories I put together to make sense of my career, I feel the same things still make me feel I'm actually on path. First of all, I love the impact I have on results as the team's tester. I enjoy being recognized for making a difference, and I've seen ways of making the results of the team something I've enjoyed keeping on my personal agenda, where ever I work. Another core of my personal sense of career is that I'm not at a dead end, I have choices, and I actively take them. Money on the other hand is not so important to me. And again today, we came to discuss that it is really more of a relational aspect, a measure of respect for my contribution in the organization than an absolute of more is better.

For me career is good use of my time - work is such a big portion of life (and fun too!) - in a way that I feel is taking me forward. But the discussion today left me thinking: what if you feel you are not going forward? Is that true (all programming problems are same?) or just a perception? And does it actually rise from the idea of externalizing the responsibility of our career to a manager handed over to us by the organization? And since all my colleagues deserve to be happy and satisfied, is there anything I can do to help them?

Sharpening the sharp minds

A bunch of nice people got together for lunch yesterday to talk about software development. From the discussion opener ideas, we picked up the idea that testing (amongst other things) could be failure demand, that is, creating need for more of it because of suboptimization within the value chain.

That topic is probably worth a post on it's own, but for the purposes of this post, it gives me a trigger to think of things I do. I work as a tester in my teams. And as I was reminded of yesterday in late hours of team building, a catalyst for change, a voice of concerns people are afraid to speak out on and a source of team motivation (wow, I feel appreciated) as they succeed and can change things for better with the feedback. But what I try to avoid is suboptimization.

As much as I love testing (for a good reason!) I don't think the more the better. Doing testing that concludes a broken product works - if I just close my eyes tight enough - isn't helping my team except to cover their ass by saying the task was done, three days was used. Adding testers to a project where we have too little time for fixing isn't helping us either. And it might just be smarter to invest in an architectural rewrite than another tester working on the swamp that we all know will keep failing. We can all care for the flow with our special skills.

Eventually, I believe software creation requires a group of sharp minds. And a task I particularly enjoy picking up is helping to sharpen the minds. With this inspiration in mind, I'm bringing in people to wake us up. To help us stay awake. And to give us ideas that take us forward. I organize trainings and discussions.

Is that testing? To me yes, as I get the ideas of needs from testing and information gathering needs for my testing tasks. I don't really care for the categorization but on the fact that I can help my team members to create less 'failure demand' for me to test on. Play your strengths - a love of people and connecting communities is one I bring to the table in addition to sharp mind and picky eyes. What's yours?