Monday, September 29, 2014

Confession from a bully for a tester

About three years ago, something happened that shook my life and shattered my self-image for a while, something that I've talked about only to very few people. Thanks to recent events and the realizations they have led me, I finally feel that the burden has lifted so that I can write about this. And forgive myself, others have forgiven me long before.

About three years ago, I was told I had bullied my colleagues. I got to learn this through an email to the whole organization by a personnel representative, who I think was one of the people that I had bullied. But there were also others that never identified themselves. They never came to talk to me. Not before or after the public accusation. I felt shattered. I ended up meeting a psychologist regularly, trying to understand what had happened or how I could cope with the situation. I was struggling for my mental health. 

I looked up texts about what is bullying. That it would usually be about an individual being bullied, someone bullying and others accepting quietly. But the accusation was that I had bullied several people. With all that I read, I ended up with the conclusion that this was a move in the nasty politics played in that particular organization.

I knew what I had done: I had played a part in removing the personnel representative from a multi-million project's project manager position by showing that he could not keep up with the work. That was not personal, really. It was about the success of that project under appropriate leadership and while I had played a part, the part was more about showing pieces that were missing. With this in the background, I was convinced that instead of me being a bully, I was being bullied.

I was different from everyone else - recognized for deeper skills in software development that most colleagues in that customer organization. Unlike my colleagues, I had worked with multi-contractor settings before and there were different things to learn for me than for the rest of the crowd. As I knew more to  begin with, people could use my help on various things and I felt bogged with work, there was just too many things I was needed for. So I started selecting my battles. I could not be available for everyone, and to be frank, I wasn't really interested in working with the ones furthest away in skills as I would get frustrated. I don't recall being mean to anyone. I would choose to not volunteer to help on some things, as I was busy with other stuff. I would check with my boss if I would need to be in some meetings I was invited to. And I would avoid getting into hallway discussions that would divert me from the selected goals. Prioritization, that's all - at least how I saw it until last weekend.

Last Saturday I realized that being a bully isn't about intentionally being a bully, it's about how your well-meaning actions are perceived by those being bullied. It's not only about what I do, it's also about what I choose not to do. And with that realization, I would like to apologize to people I've bullied. Bullying in my case comes from a sense of being better (I work hard on my skills) and how that manifests in my presence. I have authority and power, and I can be intimidating. I also see myself as a people person, always have, which was the reason for shaking mental health in re-seeking my identity after the incident.

Last Saturday was a turning point for what happened. On Friday evening, I tweeted about being a tester by identity not by role - which was a thought from working with agile team on whole-team ownership on testing. James Bach wanted to understand what I mean by I role - a challenge to debate / clarify as he often does and I failed to answer promptly. With the style of questioning, I also turned to ask for a friendlier way of challenging as I felt afraid with him expressing he was upset and expecting more of me. I had to take a pause for groceries and was ready to respond to the challenge with an article I was writing. All was well, I thought and went to sleep.

On Saturday morning, I saw an interesting tweet about #stop29119 James Bach had tweeted, and pressed the retweet button to share it - business as usual. I couldn't. I tried again and couldn't. So I tweeted my surprise out:
I looked around to learn James had blocked me in twitter. All of a sudden I had turned from a good person worth following to someone worth blocking. Since I blurted my surprise out with a few more tweets, I got a fair number of contacts, both public and private, with explanations of why he might do such a thing, even suggesting I could try seeing it as a compliment. For most of Saturday, I was just offended until I realized that this type of behavior was very close to the bullying incident I had been accused of: a general pattern of behavior from one person towards many people.

So with this incident that I still don't understand, I now understand this about bullying. It's about how the other person feels about your actions, not the hurtful intent in your actions. And it's about continuing those actions towards many people, regardless of the fact that many people express being hurt by those actions. Sometimes they express that in words, sometimes by shying away from actions with you. Like with James, I feel liberated with the idea that he would no longer see my tweets. While others question (and questioning is welcome), the feeling of intimidation and urgency is rare with anyone else. It's about how I feel - not equal, but underpowered; not seeking understanding, but to be proven wrong. It most likely isn't the intention.

I wasn't a bully because I wanted to be a bully. I did not know another way then on how to cope with the workload I had and the skill imbalance and other people felt, justifiably, bullied. No one, including the psychologist I was seeing, helped me then. I hope people close to me will help me see if I do that again and help me find better ways of responding, because the feelings I went through on Saturday being blocked by the community leader I respect a lot are feelings that I hope people would never again have to go through because of my actions. I can't promise I'm better, but I can promise I will actively work on it. Because software development is a team sports, and feeling matter. People matter.

On agile, blocks of stone and building cathedrals

This morning, our team's flowdoc channel had a picture of a user interface with a question directed to the project manager, asking if this was ok. The trigger for the picture and question was an issue I had reported saying the previous version of that particular user interface was not ok, outlining why.

I was delighted on the cultural change that the question was done over the channel so that I could see it. Two weeks ago, I would expect to be involved either by accident (overhearing if I spend enough time not concentrating on whatever I'm doing - which I did actually reserve time for) or by testing the resolved issue. With the new picture, I could immediately see that while the changes resolve the specific issue I had raised, it created another issue about consistency. I had mentioned the need for consistency when reporting the issue as a side note. We discussed and fixed the consistency issue by changing the other user interface so that the new idea we were fixing would fit the overall feel of the product.

With the little success of teamwork, I was left thinking about successes and lack of thereof. In this case, I would like to think that I cannot be the only person in my team to think about the overall product experience. But very often what still seems to go on is that while I feel I work with a purpose in mind, we often see symptoms of being very task-oriented and not thinking outside the first perceived box. Ari summed my feeling of the attitude nicely: 
If we want agile to work, we need to somehow change these kinds of attitudes. We could change it by introducing someone like me, who actively suggests other perspectives - that could be any role, it's more of a personality thing. But the puzzle is how to coach people into really thinking about the overall product and user experience. Can't change the others, but can try to change the system that makes them behave in certain way.

With agile, we rely on active and skilled people in the teams that together do things well. But it might be really easy to end up with emergent roles where mine in this case would be one that reminds on thinking over the limits of the task at hand. And the team can easily be trained to rely on me instead of thinking for themselves.

There will always be people who just work here and don't feel they serve a purpose. I'm the kind of person that would think of building a cathedral even if I was creating blocks of stone. I think I'm that by personality. Am I expecting too much from systemic conditions if I hope that we'd encourage everyone see their work as part of a bigger perspective? 

Friday, September 26, 2014

Tester as a quality coach: enabler that leads with example

I could not make it to Test Assembly 2014 yesterday but luckily there's twitter and all the ideas people share. And as usual, one thing in particular stuck with me: it's very clear the tester role is under heavy discussion whenever Agile gets mentioned in the theme.

There were mentions of programmers being the only ones who provide value, and that message seems to come out strong again today with Reaktor Dev Day ongoing. While it is ridiculous to see "agile" organizations with as many managers as developers+testers (hands-on people), the discussions of elevating developers above the rest of us working hard on a common goal still seems unfair. Writing the code is important. But the most expensive mistake is to write the wrong code and working on that doesn't need writing of the code - we can share the work amongst a group without being in silos with mutual respect.

There seems to be two directions offered to people with my aspirations in agile. I could spend time learning to program better and furthermore, I could learn to like it. There's a lot of job ads out there for a test developer but finding one that can actually deliver the results isn't that easy. Or I could see myself as a quality coach.
The checklist presented seems useful reminder of helpful and enabling attitudes for a tester working in close collaboration with the team.

In my team, I work hard not to be the gatekeeper even though I'm the only testing specialist. Developers take their own testing seriously. But still the amount and style of bugs sometimes leaves me wondering if they really even touched the product after the change.

When we've coached developers to really take full responsibility of the user experience and taught them the skills to deliver on that promise, we might not need testers separately. There's more than running the software though. There's the questioning mindset as well that doesn't just apply on the software but also on the business decisions, user needs and designs we have on satisfying those.

It's a bright spot in the automation centric agile world to see someone talk about the other route: being an enabler that leads with example.

**That bug on the picture: one extra dot in the code. I keep being amazed how small things appear big and the other way around. 

Gender never was an issue to me until...

I've been thinking about this blog post and whether I should write and publish it for several months now. This is strange for me, as I usually follow the mood and write about things that I think of at that point.

Over a year ago, I remember tweeting a reply to someone on my experience of having never been mis(treated) for my gender in tech. I studied Computer Science at Helsinki University of Technology and don't recall anything but positive discrimination - everyone was very helpful to me, most likely because of my gender. I felt included, one of the bunch. I spent long nights discussing the world without being uncomfortable and the Finnish sauna culture with mixed saunas (naked, yes) were a non-issue.

Career-wise, I've spent my time testing, managing testing and managing in general. Again, gender was a non-issue. Reading the recent articles on how women are treated differently in collaboration reviews (being given feedback on personality traits) suggests I might have just been also partly blissfully ignorant but I feel I was again not treated differently from my male colleagues. The positive discrimination post-school isn't as strong and I have felt included.

This year in February I had my collaboration review with my manager, and I set a goal for myself to work more on programming. With that new year's resolution, I've started to learn why women might feel uncomfortable in tech and facing things that I have never had to see before.

When I identify as tester, I'm one of the team members with different skills (and personality). All testers get regularly mistreated, that's why over the years it's been such a big deal to be involved in a community of testers to share the experiences. People mostly just don't get testing. It's not a gender issue. It does not matter that I'm a woman to get to hear from a developer "I'm more valuable because I code" or "You are organizational cancer, the more you test the more there is to test". Both are quotes from the last 2,5 years. Any tester would get that from those developers. And majority of the developers are great, brilliant, most wonderful people I've ever had a chance of working with. I can easily cope with the negative and have learned the appropriate responses over the years - focus on the positive and create value together. That's what testers do.

When I started programming, the great, brilliant and most wonderful people are still as wonderful and helpful. They had no attitude problems with testers and their attitude remained positive with the change. But from ones that had problems before, I got to hear different negative remarks: "Women only add comments to the code", "I've seen women who code, but none of them are ever good at that".

For a person who was really comfortable with all the negative stuff as a tester, I was surprised how uncomfortable I am with the gender-based negative stuff I get as a programmer. I feel safe as tester, but very much unsafe whenever I'm a programmer. It could be that this is because I'm a junior programmer and senior tester, but I suspect that the first encounters of gender-based discrimination has been somewhat of a shock to me. Luckily, I really don't want to be a programmer - I just want to explore myself in doing programming for fun to better understand some aspects of software development I find intriguing. I'm not ready to fight for my place just for being a woman.

Saturday, September 20, 2014

Why would I do regression testing?

There was an evening event and late in the evening we were talking about testing. As usual in the agile circles, test automation creeped in to take the stage. This time though it was formulated perfectly for me to learn something essential.

A developer colleague took a sympathetic approach and told me he would feel bad for if he didn't create automation and in particular he feels he needs to work on automation so that I can focus on testing the new stuff and not repeating the same tests.

I immediately replied from my heart and experience. I have worked on my product for over two years, logged some thousands of issues but so far I have not repeated a single test. Even with the fact that the level of automation in my team isn't created by these aforable, sympathetic agilist developers who care for my well-being.

I realized that reply includes a core of how I deal with testing work. I'm active player in varying my approach. I might press the same buttons but I have different ideas racing through my mind. I don't use the same browser, I don't use the same user, the same data, the same story, the same combination. And I find problems the test automation will never find.

Don't get me wrong, I love having test automation around. I don't expect it to do any testing for me. Instead, I expect it to make my testing work less interrupted with plethora of simple problems automation can catch. Whenever I find a problem, it stops the testing I was doing. But more than automation, I love having active thinking developers around that think and use automation as their safety net, but don't go into relying only on automation. Thinking is the core of it all and sometimes some of that thinking gets packaged into automation.

Regression testing isn't what I do - at all. I'm not sure to what extent we should even talk about doing regression testing. I test, and regression is one of the risks I'm considering to motivate what I do. But there's no specific repeating same tests approach that I would call regression testing.

I've been teaching that tests have 'best before' dates with short expiration dates due to the changes that might cause the need of going back. It's really test results that expire, and the results are not the tests but the information about the system. I seek for same information again, but while at it, I also seek for new info based on the learning that other tests (and discussions, readings etc.) have given me. That's what a tester needs to set their mind to achieve.

Thursday, September 11, 2014

Create with software, don't code - value of non-coders for code

My main aspirations this autumn are testing and agile software development in general (as always), improving my own coding attitudes and skills (can always try to work on stuff) and teaching kids to create with computers.

With the last one, I looked at a really nice presentation video from Linda Liukas last night:

The video is pretty concise to look at, and on it Linda shares with clear enthusiasm her story of why she ended up being into code and inspires people to create similar experiences for all children for a better future - including both genders.

I look at Linda speaking with joy about code and I see similarities. I see similarities in the idea that when you talk about you work, you talk with love, affection and excitement. You pass the feeling on to whomever is listening to you, hoping that it might catch. And listening and experiencing that with Linda, I felt very blessed remembering feedback I've received over the years on my own presentations and trainings, that it oozes that I absolutely love what I get to do for work.

People who wholeheartedly love what they work on might have a chance of catching some of that passion and enthusiasm into the younger generation. At least my kids and their friends know that their mom has the best job ever, and it just keeps getting better with all the collaboration stuff we're working on in the teams under the "agile" flagship.

On the other hand, it saddens me that while there's so much in common, there's also a difference. From the stuff I'm excited about, I wouldn't teach kids coding.  I prefer not to code, and while there's people who prefer not to socialize, think critically, and think systems and value, I can easily work to bring my special skills to creation of code without writing a line of code. I would teach kids code. I would teach them testing and learning about systems someone else created, on levels that many current developers don't do in practice. I would teach them collaboration and valuing the different skills of others. I would teach them drawing and visual aspects as relevant part of what we're creating. And that it's just normal for someone to have an idea, others to run with the idea and all of us to improve the idea and make it practical with all the different skills we're bringing to the table.

Code is a tool that the future generations should learn not be afraid of. But as always, emphasizing the tool instead of the creation process just will not do. Linda was talking about "I made this" feeling. It's a feeling I recognize as tester - I was there to help for this other one to be actually able to use it. It's a feeling I recognize as designer - I was there to help get that important thing done with just two clicks. It's a feeling I recognize as a team manager - I was there to help people excel and reach their potential so that it actually works all together.

Let's teach kids creating with computers (as opposed to consuming). But coding? That too. But let them find roles in groups that are not labeled as strongly as ours are, but ones that bring out their special interests - in collaboration with the others with different skills and emphasis. 

Tuesday, September 2, 2014

Special words for programming concepts for tester

Every now and then I stop to wonder about the world of testing I live in. A recurring theme that stops me seems to be that of automation.

Working with selenium, I'm getting a hang of page objects. Page objects seem like a nice way of saying to create classes of concepts that neatly pack things up together, so that you wouldn't have elements from a page dispersed around your actual tests. A great idea that helps maintaining, and really obvious to developers except for giving the concept a new name.

There are two test automation specific terms that leave me pondering: data-driven testing and keyword-driven testing. I seem to actually have some problems with those words. For me, both of these terms are fancy ways of renaming existing programming ideas to test specific concepts, and as such, create an extra divide between the testers and developers. The way these concepts are presented to testers new to automation gives the impression that these two extremely old programming ideas are somehow the center of test automation without getting really into the world that belongs to a developer.

To me, data-driven testing is just a way of saying that you should use variables. It's a concept I've been practicing with my 5&6-year olds, and they seem to start getting a grasp of it. Why should we in testing say data-driven for any other reason than introducing the idea of variables. And why would we need a separate concept for that? And keyword-driven testing is just a way of saying that we should modularize code for reuse, right?

I think these two words in particular have their roots in the idea that tester's can't code. Well, many can't. But treating them worse than I treat my 5&6-year-olds in regards to their intelligence and capability seems wrong. People can take the challenge. People appreciate being supported. And people appreciate when they learn the stuff that started off as difficult.

I don't dislike automation work because coding is difficult. Some coding is difficult, but test automation isn't the hardest of programming challenges there is out there. I dislike it because it's more boring than the other options I can use my time for. And I appreciate my time on manipulating my team's developers to do the automation stuff over implementing it myself - for the benefit of the team in general. I dislike it because it steals potential great minds and turns them into machines if given without appropriate support of a balanced perspective of what it can and cannot do. I dislike it because it turns into a silver bullet that downplays the role of thinking tester by giving us keywords you can call to create scripts without knowing how to code, and excuses of not learning the next step that we're perfectly capable for. 

Is it just me? Most likely. :)

Monday, September 1, 2014

Acceptance testers as IT professionals - are there really that few ladies in IT?

I'm puzzled. There was an article posted today in a Finnish non-IT magazine pointing out that IT-industry needs more women ( But I keep wondering if there are really that few women in IT, really?

I know the stats show less than every fourth person "professional in IT" is a woman. But who are these "professionals" - who's in and who is not?

There's one study that defines a professional as a member of the data processing association (1). There's another study that doesn't really define what their sample is (2) but looks into ideas of IT as career before choosing what you study and after that. The after selection part seems to imply a proper schooling in IT.

I studies computer science at Helsinki University of Technology and Tampere University of Technology, and got to experience what it's like to be really in the minority. I'm not questioning that. I remember in particular the annoyance I caused at Tampere, refusing to be in the room to be counted as a new female student, as I knew there was a bet on our number as I knew the routines having spent time in Helsinki circles before that. There's few women in IT specific education programs, I take those numbers as facts.

What bothers me though is the experience from the industry and the message we seem to be sending out emphasizing how few women there are. What if there are more women in IT, but we just exclude them when we count?

Inspired by this idea, I asked around at the office today on how many people we have in IT roles and how many of those are female. I got a confirmation: out of the team of 15 developers, I'm the only woman. And some were not sure if I should be counted even if I can program because I'm a tester. Our product management team has many women, in significantly higher portions than in development. They were not included. Let alone many of the other roles that participate in development - they are all excluded.

I also looked back at time I was working at an insurance company, leading acceptance testing. I had teams with tens of people, significantly contributing to the success of software development as testers. There were other teams, even larger, working as business specialists defining how the systems would work. These teams were female dominated, to the extent that I can recall one man out of the tens of ladies. When I was there, I often asked the acceptance testers if they identified as testers. They would tell me no, they identify with the business stuff - concepts of domain. If someone asked them if they are "IT professionals", they would say no. But they are. They got their salaries from IT work. It was better to not emphasize that, because "IT professionals" get paid more. My ideas of what salaries I can get as an IT professional were ridiculously high in my colleagues eyes.

I work with software testing. Our of the people that I see in trainings and seminars, women are not a minority. Sometimes it feels quite the opposite, men are a minority. There's significant differences between industry sectors though. But I fear that many of testers, in particular acceptance testers, are excluded from the counts. In 2012, asking the members of Finnish Association of Software Testing (FAST) how many of them are members of the data processing association, sample in (1), half of them were. And FAST is a subgroup of Sytyke, which is a subgroup of the data processing association.

To know the real numbers, we would have to define what level of contribution counts you in as "working in IT". If 20 % of your working days go into IT but the other work you do feeds into that, should you be counted? Everyone uses software (IT) so what actions towards creation of software get you to be counted? Do you personally need to identify before you count?

Perhaps that's the problem. As a tester, I get to be actively excluded from small scale counts on a team level. I identify with IT, so I get counted. But the ones who contribute but don't identify should be counted too.

Excluding people who contribute isn't going to make this a more lucrative profession for the future ladies. Learning programming is another thing, but could we start by realizing that there could be more ladies in IT than we've given credit for due to how we count the numbers?

The numbers could be right, they could be wrong. But the point is that we should actively get the people who contribute recognized within the field as relevant contributors. It's not a women thing, but it's a roles thing. The acceptance testers deserve to be included, even if that drives us towards users as "IT professionals". 

Or perhaps we believe in the lesser value of those contributions, with the ideas of test automation and agile in our ideas of realistic future with less failure demand? 

The refences, articles in Finnish: