Saturday, September 24, 2016

Conferences against the structural problems

I've been buzzing around all morning organizing all the things that need organizing before I jetset off to New York to do a keynote at the Test Master's Academy conference. That's kind of awesome. But simultaneously, it's not. It's a lot of (unpaid) work. Just like any other conferences where I speak. I have higher expectations for this one than many others, as I've been positioned to be the opening keynote and there are some internet friends I look forward to meeting. 

If you take a look at the conference lineup, you see plenty of men and women, and even people of color. There's people who are believers in exploratory approaches, and people who are keen to see automation rule to world of testing. And it's all amazing, just as it should be. 

But like I said, the speakers put a lot of work into conferences. There's the time for traveling (that isn't paid time even when the conference is). There's the time of organizing all the things that need organizing for being away. And there's the time for the conference. I have a great chance of actually enjoying this conference as I get to go first. Often times, I'm preoccupied with my preparations throughout the conference.

So I wonder, many times, if this all is worth the hassle. It's fun and all that, but is it really giving me as much as it is taking from me? 

Then I enter the twitterverse and see this:

I retweeted it with my note: "There's a systemic problem under this, as the kindest and most encouraging of us see this. It's not up on women but the allies to change this". 

Allies is a word I don't really like, but I lack a better word. I mean men who care that the world changes to be a better way for their daughters, partners and friends in the underprivileged groups. 

The first step is to recognize there is such a thing as privilege, and I appreciate it might be hard. I have tons of it, even if I lack some. I'm a woman of a certain age (love the term and just learned that from Sandy Metz) which gives me courage I did not have when I was younger. I'm very white and from a society that has given me opportunities I wouldn't have had somewhere else. Privilege is a special right, advantage, or immunity granted or available only to a particular person or group. As someone who is underprivileged, it takes you more work to get the same done.

When talking of women, I hate talking of minority because where I come from, women are equal in numbers in conference attendance and work places in the field of software testing. Women are not a minority, but they are underprivileged. Even where I come from, often a majority of speakers in testing conferences are men. 

It's clear other conferences end up with a different result because they balance out by not just encouraging submissions but inviting specific topics and people. And that is justified because of the systemic forces that are against women.
  • Less women are encouraged to speak for their companies in public.
  • To get to be considered the one at your office who gets to go (or even submit), you need often years of work against the corporate cultures in IT favoring men.  To get to a speaking position, you might need to keep all your focus on keeping that position instead of donating time for free for conferences that are businesses. 
  • Women tend to carry a bigger load of the emotional labor (organizing family life) than their partners and thus have less time available to use. 
  • It can be harder to find time to be away from other duties, it can require direct financial investments and include a mental load from judgement on the choices you've made on leaving family behind. 
  • When speaking, you're continuously facing "chosen for gender" allegations. 
  • When speaking, you need to exert extra effort in presenting yourself in acceptable tone
  • You feel you need to be good, not average to justify your existence. 
  • You need to work against the stream, with lack of role models. 
  • You need to accept that your feedback can be more harsh and personal just because of your gender. 
  • It's common to ask (unpaid) diversity work from minority groups over offering to pay them for the work they do. 
  • It can be harder to find the extra money to even loan for the conference on expenses if it comes out of your own pocket even if expensed later. You will know you chose a conference over something for your family and there's a gendered expectation on how the choice must go. 
  • Coming back from a conference, it still feels women report on the harder treatment of the "stupid ideas" they pick up.
When the problems are systemic, it's not up to the underprivileged group to change it. It's up to all of us to change it. Conference organizers have a lot of power in the change if they choose not to be passive victims of the system. 

After a discussion with a friend, I managed to sum this up in just a few sentences. 

What the conference organizers can do:
  • Pay for the work. All the work. Including submission work. When you stop thinking of submissions as your right to free labor, you start finding better ways of investing your conference budget than call for proposals. Good proposal is hard work. My talks tend to take me a week of work before 1st proposal. 
  • Pay on time or early. Yes, I know it is hard because you don't have the money yet. Stop treating speakers of the world as a loan office. The underprivileged are less likely to submit when they know they have to admit to being challenged in this. 
Before numbers like 20 % women submitted are relevant, we need to consider what are the reasons that stop women from submitting and be open to the possibility that their reasons might differ from the reasons provided by men. And if 20 % of a 100 proposals is 20 talks for a conference that needs 10 talks in total, that might not be a bad situation at all. There's an actual potential for an all-female conference. 

Why would you? Because you believe that diversity means learning from people different to you makes the world a better place. Being representative would be important as different backgrounds bring different lessons. I do, do you?

Friday, September 23, 2016

Fighting the urge for Jira

I've spent a day deepening my personal understanding of end-to-end scenarios and reliability of all the test automation we have around here. I have not come to a conclusion about it yet, but started to slowly frame my role as an exploratory tester as someone who tests reliability of the test automation systems. And coming from my interests on clean code & reuse, I seem to be also taking an active role towards testing the sharing solutions on test automation make sense also or more in the future.

As I was testing end to end with an exploratory approach, I was bound to find some issues. I'm in an easy situation now in the sense that I have an old version that "works" to compare against, kind of like back when I was doing localization testing. If the comparison version was broken in the same way, we just mostly did not need to flag the problems.

All the issues I found ended up in a mindmap while testing. There was a color coding. Problems with the new not confirmed with the old. Problems with the new, confirmed not to be with the old. Problems with the old, vanished from the new. Problems with both.

As  the data was collected and was pretty convinced I knew enough for now, I stopped for a moment. Normally, this would be the moment when I, at latest, go to Jira and log some bugs. I had to fight the urge to do that.

I fight the urge, because I want to keep trying the fix-and-forget approach. Instead of taking these to Jira and moving on, I want to:
  • Find the test automation that isn't catching  these (and pair up to make these caught)
  • Find the developer who is contributing to these, to understand their work priorities on when my feedback on these (and others) would be most timely for not just randomly jumping around the product, but completing a feature / theme at a time
  • If these are known issues, figure out a way to get and keep the main more release-ready
I believe I don't need to prove my worth in the number of issues in Jira. I find that in a new organization, the fear of someone coming to check my work based on Jira cases lurks in the background. And I fight the urge to go for Jira, which would be the easy route. 

Thursday, September 22, 2016

Same same but different

I've been receiving tons of congratulations with my change of jobs. Some mention that my new work sounds awesome, some note that it looks like I went back to doing exactly what I left 8 years ago.

This is how I described my job out of a whim in LinkedIn:
A hands-on tester with enough seniority to figure out what is right for whatever goal assigned. Working on making the Corporate Security Client awesome through empirical evidence and smart testing approaches. 
With two weeks in the company and some hands-time with both production versions and upcoming versions of the product, I recognize many (most) things are the same. This lead me to ask myself the question: why is it that I see this as a way forward in my career? I clearly do.

On my previous round of F-Secure, I was in a test manager position - or at least, that is how I thought of it. There was a bunch of other testers I was helping to be more awesome at testing, and rarely when I felt there was time from all the meetings, I tested. Often mostly localizations and UI, perhaps because I was particularly adept for those tasks in relation to many others.

Test Management wasn't completely new to me, but it was new enough to hog a major part of my days. I relied more on information I could get from other people, than on information the software would give me.

This has changed. I lost a money-worthy argument with a significant vendor in a job after F-Secure because I had done what my manager told me: "you are too expensive / valuable to test hands-on, just guide the others". And I would have had better empirical evidence if I would have instead spent 2 days of the week locked up away from useless meetings, hands-on testing. I would have known things that I ended up speculating on. I could have shown what works and what doesn't better.

I notice that at F-Secure, I'm still fighting the old habit from coming back. I don't need to be part of all the discussions. I don't need to talk to every product manager and owner. I need to be selective, and I need to be able to trust people to tell me things - or that the software when tested tells me things they forgot to tell me. And I can do that now, with a few more years of experience under my belt.

There's another thing that is clearly very different. Now we have significant amounts of automation. And programmers who unit test! I'm delighted to have collaboration with my team's test automation specialist on end points we want to use when testing things, approaches to make our existing automation more versatile and smart, and things to add from what I learn through exploration.

Where the company is now and where I am now, all of this makes it different. And I believe being a better empirical technologist is a better step forward on my career than becoming a manager. Seniority gives me similar things than managers get from their role. But the practicality and impact through practicality - that's the thing I strive for.

Tuesday, September 20, 2016

Reasonable Expectations -exercise

So, you land into a project unknown. You collect a bit of info, organize the claims by sources you've heard them for, pay attention to differences between sources and decide who you're going to primarily believe, for now. And then you dig into testing.

A lot of what you're experiencing does not match any of the claims. And there's a bunch of claims you're making now that no one else did.

You realize there might be a usual problem going on, with "no-one's land". With enough small teams around, there's things where you just see things end to end that none who focus on their bits have. So what do you do?

I remember clearly a time, when I wrote clear and well-investigated bug reports about these, and then the ping-pong game starts. It often continues until there is either a developer with a system perspective or until I play personal relations on getting someone who wouldn't want to look at it to look at it to help pinpoint it further. I feel exhausted just thinking about this.

Today I run into something of this sort. And instead of writing a  bug report, I made a list of reasonable expectations I was planning to talk about. Reasonable expectations are my claims on what I find would be reasonable to expect and I let the developers tell me I'm wrong - or find out that I'm right and then discuss the bugs I did not want to log against the end-user perspective claims that are not true after all,  based on evidence. For now, until we've changed our software or our perceptions.

I realized  this isn't something new for me. I've had great success with this before, with a difficult project manager of the past. The mechanism is just something I've never before labeled. I play a lot with the dynamics of communication while I deliver the messages as a tester. The dynamic of making me the one who is proven wrong on the reasonable claims turns around the feeling of how we'd talk about the exact same thing through a bug report.

The Nameplay around Testers

I'm a tester by identity and have made a lot of my choices on what skills to focus on developing next based on what would be useful for testing. Testing is the quest for empirical evidence over speculation of plans, and the endless strive for better through learning with the application (or specification) as my external memory.

I care somewhat what I'm called, enough not to prefer to be called a developer. I'm a tester (and an occasional programmer) and being a tester is my way of finding community of like-minded peers who want to dig in as deep into testing as I do.

Today as I was testing in the corner of our team room, I was again reminded what it is that makes me different. I was laughing as the product misbehaved under my scrutiny, I felt immense joy in figuring out what needed to be fixed and getting someone to fix it so that I can forget about it. And I continued to the next puzzle the product presented me. I love my job!

But here they choose to not call me a tester. They call me a Quality Engineer. Like the title makes a difference, I'm still a tester and I'm still directed with the idea of empirical evidence. As a tester, I'm still not only "system testing", I'm testing. The variety of mechanisms is open to me. The only thing that limits me is my focus of filling gaps and my skills. And skills chance with deliberate practice.

As a tester, I test ideas. I test while the feature is being built. I test after it is "done" - and not nearly done enough too many times. I test it after we release it into production, finding gaps in what I can do (environment realism) and what I know to do (use cases). I'm never done, but every day I can dig in a little deeper or wider.

I also run again head first into the discussion of being more "DevOps" where everyone is a developer. I've had this discussion so many times that I could pay attention to the meta, the arguments I use time and time again:
  • "Tester" is relevant to me as it helps me find my community of likeminded deep testing thinkers, the specialists
  • No one is just a tester, specialty does not block you from doing other things if you have time
  • Becoming good at something requires focus, and while half the industry is with less than five years of experience, skills like mine (tester skills) don't get built unless you get a fertile ground to build them
  • Wanting to call me a tester is like wanting to call me a man. How about having everyone being craftswomen for a change. I'm still a woman and I'm still a tester, even if you think the other term magically includes the other. Let's just call everyone women and everyone testers. That is equally true. 
  • Playing with words is boring. How about we mobbed on some testing instead? Pick an activity, any activity and I show you what a tester like me does.
 People in general are just to keen to find their boxes and stick in them. It's not the label that defines the box, it's the attitude and skills of the people.

Saturday, September 17, 2016

Like I Never Was Away

My first week at a new job is behind me, and it has been one of the weirdest experiences of my life - in a good way.  I joined the company I used to work for 8 years ago, and with one week there, I'm starting to feel like I never was away.

I've changed a lot in the 8 years:

  • I still prefer exploratory approach to testing over automating, but I'm now a tester and a programmer. I no longer live by imaginary limits of a role even though I strongly identify as a tester. 
  • I've lived with systems bigger and more complicated than what we're developing. Things appear smaller than they used to. 
  • I've learned that empirical evidence trumps speculation. That it is a better choice for my time to test hands-on than sit in a meeting where people tell their theories of the thing none used. 
  • I've grown appreciation for (a lot of times idiotic) test automation as a means of fast feedback and a base we can build more on. 
  • I value my freedom of choice even more than before. I love not getting tasks but visions to guide my work. I love not having a specific description of responsibilities other than being the most awesome professional I can  be. 
There's things where the company has changed and not changed. The elements of the products people talk about are much the same. Surely they've changes some three letter acronyms and come up with lots of new ones, but the domain concepts remain. There's a lot of same people, even if in different positions. It's fascinating to see which ones have advanced to management, which ones to deep technical roles and which ones appear to continue as I remember them back then. A big change is that there no longer is a big bureaucracy to get access to the code base.

For purposes of testing, there's one big change: there's more test automation than before and in a very healthy way.  I find in a week that I don't agree with a lot of the stuff on how automation is and my fingers itch for shared learning in mob format and some major refactoring. Also, I'm sensing a bit o my biggest automation fear around: the lack of great testing as focus on programming eats up too much of the intellectual bandwidth while learning. 

So with a week in, I feel like I never left. And I know what I want to pick up next. 

I want to spend time with the closest developers I have in my team and stop the programmer-tester boundary of unit vs. system tests. I'm betting we're mobbing on his unit tests in a few weeks because I already introduced ideas of what and how I want verified where his response was to realize some of that could be unit tests. 

I want to spend time exploring the biggest risk components with some tester colleagues who might settle for less than I would. And while learning what and how I would test, I want to use my closest automation tester colleague to turn some of my ideas into automation that helps us run things over time. 

I want to learn and share with everyone, starting with my tester (quality engineer) colleagues. We'll first do mob testing on some python test automation, as the automation study circle is an existing structure. To complement with my true interests, we've already agreed with one colleague we're starting an exploratory testing study circle. 

We'll see how this goes.  Let the fun times begin - there's lots of amazing people around. 

Wednesday, September 14, 2016

How I was interviewed as a tester

I've been a tester, test manager and again tester for a while. I think I know what I'm doing and I know I have a lot more to learn. I've been a restless soul telling all my employees so far that I will move after two years. Granlund expected me to last a year when I said two. And I stayed four and absolutely loved it.

As four years passed, I started thinking if I however should move. I've looked into two jobs, been offered the two jobs and ended up accepting one of them. The first I passed with a mantra "Quality of Life" - I had a lot of that with Granlund. No stress daily releases, great team and a supporting manager. 5 minute route to work. I concluded I would be a fool to give all of that up. And yet, I did.

For the job I passed, I was very close on accepting it. I went through the whole process of recruiting: meeting the recruiting manager, full day of evaluations with a psychologist, and even spend a full day training the extended team to figure out if I would like to work with them. The last thing was my suggestion, and we had a very nice and wonderful day of testing the company product in a mob format, finding bugs they were previously unaware of.

The reason I did not accept the job in the end was that I felt like the whole process was about finding reasons why I wouldn't be the right person or good enough. The recruiting manager knew of me from a shared past, and the questions I remember him asking were about my bad (past) habits of impatience. The psychologist was assessing how I would complement the team, but also pointed out that my "clock cycle" is fast and people may have hard time staying in my pace. The team training was about me seeing the team and the product, but when it came to the company framing the day, it was about "work sample from me". As if they were the only one making a decision when recruiting!

With the job I passed, I spent a lot of time thinking about what they could have done better. They could have compensated me for the time they pushed me around in recruiting process. Or they could have at least acknowledged that more (unpaid) phases to recruiting might protect them from bad hires, but also from really good ones. They could have made me feel they want me, not only that they could use me if I convince them on their points. They were not the only one needing convincing. And with senior software people, the employers might need to consider their approaches.

The job I accepted was opposite. They invited me for an interview very much the same way as the other, though networks. The first interview focused on figuring out how they can  build a job I would accept. They built the job for me, with a description that did not exist at that point.

I interviewed with the manager for the newly opened position, but our focus was on discussing ideas of what to do in the job. It felt more like an idea sharing session, and my focus was on assessing if I could learn to love this manager as much as I did my current one.

The HR interview seemed like an introduction to how awesome place the company is and how nice benefits they have. Sure, there were some questions on how I approach things and how I manage with the English language.

Then I interviewed with the team. It was a chat about stuff, with focus on "we just wanted to know you test and don't only manage". But I got to see that I would get along with them, just as much as the other way around before I needed to make my decision.

So I took the job. I started this Monday. I feel like I've come home again. I have amazing team, and interesting technical (and people) problems. I know I'm a piece to the puzzle that helps. On day 1, I got introduced to what we're doing. On day 2, I got the test environments up and running. And on day 3, I tested and found bugs; I shared ideas of how I'd want to test things we've created and got acceptance on testability changes; I got careful positive marks that we'd mob on different types of automation soon to bring together unit tests, system tests and exploratory testing because they just won't say no to things that make sense.

I'm feeling extremely grateful that there are companies who approach recruiting like they want to hire, instead of trying to figure out reasons why they wouldn't. The latter sounds a bit like testing: Look for opposing evidence. When there's none, we guess it's time to release.

I need to feel I'm wanted and needed. So for now, I'm just going to savor this. The energy of being wanted and welcome takes me a long way in doing the things I can help with.