Frustrated on the silo mentality and working solo

With 17 years in testing and intensively learning about pretty much everything on software development is (positively) mixing up my duties at work. I tend to contribute on pretty much everything we do, and try to speak for the idea that others could too.

To take a break from testing, today I contributed summarizing our product roadmap - just to make it visible what we've already talked about that needs doing in a visual format. And I initiated a meeting to collaborate on user interface design. The latter left me thinking, which turns into writing.

A little over a month ago, I was asked to test a new feature in the product. The feature was a search and with the first minute looking at it, it was obvious to me that it was close to "as designed" but nothing close to what the users were likely to need from it. With a history of failing this way a few times before (and also succeeding not to do this a few times), I felt frustrated. I obviously had missed the fact that we started implementing this based on a user interface design that just would not work - again. I could have helped, I could have contributed, but I had not. So again, I was in a position to tell how it would not work.

The message was taken well, but I was still puzzled. I asked around to ask if anyone had been helping the developer with the feature. I learned that our project manager had contributed the user interface sketch in efforts to explain what the feature could be, and that the feature had been reviewed by our user interface specialist. The developer had suggested a couple of relevant improvements, within the limits of the design he had presented. I talked with the user interface specialist, to learn that he had reviewed it as in "yes, that's a user interface sketch" and with all the other work, passed it on without paying much attention.

As the design had already been implemented, I took on more time testing it than the first minute. I learned through testing that not only the design was inappropriate, the implementation was also quite buggy. With the worst possible experience, I logged the bugs and just checked to see the issues are still waiting in the queue with no progress what so ever. Not fun for anyone, I'd claim.

I got back to this experience, as I managed to volunteer myself to participate in a "managerial" meeting with the business users end of last week. Listening and asking questions, I learned that my perception of "this will not work for the users" was indeed the case. Taking the lessons from that discussion, we had another one within the team today on collaborating with the user interface design.

We looked at the existing design, which focuses on showing the database fields to user as separate search criteria. I brought in a post-it note I had sketched on what I thought the users needed while I had tested. We had a discussion, and agreed to leave the user interface designer to work onwards with it with some quick sketching.

A few hours later, we had another design. We reviewed it together and I contributed both ideas of how the design would fail with the users and what I saw as it's strengths. Five minutes later, we had yet another design that looked brilliant. I quickly still went through the use scenarios in my head, testing it, to realize we had dropped a significant requirement. With additional discussion, a few minutes later we realized that the current design could easily be extended incrementally to the missed requirement, and that there would be a lot of value for the users to just do the first part first.

To my surprise, the feature with the second part included, looks exactly like my little sketch from testing. I guess we're now more in synch as a team, but it took a lot of calendar time and effort, leaving me hoping for ways to accelerate learning with better on-time collaboration.

My team has a product-owner -type of a project manager, a user interface design specialist, developers and myself as a testing specialist. I don't particularly like the idea that removing the testing specialist, so much of our results crumble. It's not because a tester is needed, it's because someone like myself is needed. I go through what I thought, what I learned and how I felt. I work through a lot of ideas on how I could help us succeed, how I could contribute, how I could help others learn. I can change what I do, and hope others will pick up stuff they find relevant - and learn to find the end goal relevant.

Occasionally, like today, I feel the amount of "not in my job description, somebody else's work" is overwhelming. And on days like this I wonder what is the experience that transforms the silo mentality to something a little more productive. I want something better, and I'm sure others do too. There's something wrong with the system that causes us to shy away from delivering value together to play with our individual tasks. So, more collaboration, more doing together. I wonder when the initiative is on someone else and not assumed to be "in my job description" - as I have no such thing, by choice.

Tester could help not waste developer and user time

I find it funny that I get upset for calling developers bad testers, but reading James Whittaker's latest post http://blogs.msdn.com/b/jw_on_tech/archive/2014/04/11/stop-testing-like-its-1999.aspx just feels so out of context for me that I don't even care.

But it does prompt me to write a post, that I was thinking of before reading it, on something I learned at work today.

I had been invited today to meet up with a team of business users that use a particular area of the product we're building. My invite there was the first with that particular group, and the meeting was long due, postponed for various reasons.

The meeting opened up with the business users apologizing for their lack of time for us - for the meeting, for using the product, for providing feedback if they ever found time to use it. They were swamped with other work, and this product while useful, wouldn't be their only way of getting the job done.

We discussed the needs for upcoming development work, and I asked many questions to understand their needs better. Others from the development team seemed focused on listing features, negotiating their order and coming up with a design the business users appear to accept. Digging to their actual needs, we completely changed the ideas for that area. As the discussion happened late for one part, reimplementation would happen. But on two other parts, we feel more comfortable on the likelihood of making the feature helpful for its purpose.

Then we talked about getting the product into use to get feedback. As I briefly summarized what we had covered on our testing in the team, I heard the sighs of relief that the interruptions to their already busy schedules might be less than their used to - without a tester around.

It could be that our developers are not quite as updated as ones James Whittaker seems to talk about. At least our users are smaller in numbers, and very much bothered when they get to be used as testers, regardless of the ease of reproducing and pace of fixing. Bugs make them use time on something and that time would be of more value used elsewhere. Context matters.

The testers of today might have different set of skills - even without coding - than the testers of 1999. I find myself to be a catalyst that help us start some of the difficult conversations that we finish together with a better understanding. And have noticed many others identifying themselves as testers to bring in a similar approach. Back in 1999, I would not have expected all testers to be active explorers. Nowadays, the button clicking robots who fall asleep arriving to work still exist somewhere, but deserve to go extinct. James Whittaker did not seem to talk of that crowd, though. But I get the feeling he thinks of the types that insist on all bugs being equal and not learning what information is valuable. Perhaps that's why I felt disconnected reading the post - there's another species of testers I don't even relate to?

Continuous releases are a way forward even without automation

Tomorrow is a scheduled release day for one of my products. The scheduled release day approaching creates interesting behaviors: a product management team member requested for no testing today, or the release might be postponed. It feels easier not to know of problems.

Coincidentally, tomorrow is also a release day for the other one of my products. It wasn't scheduled, but as we work with completing a feature at a time, it just got completed so tomorrow it will go out.

The same day as release day left me thinking about the two different approaches, and how much of a difference there can be with one relatively simple change. The first team uses Scrum and sprints with a scheduled release, the second team uses Kanban and releases whenever features are ready, with emphasis on making the features smaller to flow through more fluently. Neither one of the teams has test automation to a relevant degree.

The first team completes development on main, and does fixing after the sprint in a branch, while already working on the next release. The test-fix tail is scheduled to be about two weeks and yet always runs out of time postponing fixing. There's a lot of changes all around, and no change to test those within the schedule. Every day close to two weeks we just hope the testing does not find anything on time, to make the release - still realizing that testing was not done.

The second team completes development on a branch, and tests and fix with focus on time through the process. When development (and testing and fixing) are complete, the feature is merged to main and a bit of final testing is done. We measure the times in different stages and realize test automation would make us faster, and schedule a piece of automation as the feature to complete every now and then. The second team was like the first team just less than a month ago. It's amazing how big a difference that makes.

I love the fact that I can test with the second team continuously. The approach allows us to create a steady flow of features, whereas the sprint-type of model drove us into starting things that we barely completed - leaving most of the testing and fixing for later.

I see two other things that could have helped us:

1. Learning to build small things of value -- this is still on the list, but is making much slower progress than I would hope to see
2. Automating testing to a degree where the testing tail will be much much smaller -- which seems still hard to arrange enough time for, with all the legacy (testless) implementation

We tried both before going for "continuous (manual) deployment". Now to remove some of the manual work, one item at a time. 

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?