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. 

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. 

How I interviewed testers

My regular job responsibility is not to do recruitment. Recently, I've had two experiences of recruiting from completely different perspectives. First was one where two companies were considering to recruit me (or I was considering to be employed with them) and of the companies succeeded. The other was an experience to provide professional services to support recruiting. And that is what I wanted to write about.

The case was with a company that had interviewed several people and shortlisted two people that could be appropriate. The two people had gone through the regular interviews with non-testers. I offered to spend 30 minutes with each candidate they thought they would be interested in to pair test and give an assessment of how they approach testing.

My assessment report for the company included an hour of video of screen & us testing together, and a summary of their strong and weak spots as I saw them. We tested the company's application for a pre-selected feature, in a test environment.

I opened the session telling we'd work as a pair with the rule of "I have an idea, you take the keyboard". I had the idea first to introduce them into the application and most of the session I would be the hands, as their ideas mattered.

In 30 minutes, I got to see the testers flow on how they get started with something new. I got to see

• if they would take notes / model things while testing.
• if they see bugs. 
• how they model technologies and focus of testing. 
• if they were dependent on external answers or could provide theories of their own.
• if they at the end of the session has ideas for making the testing deeper or if they were ready to move on to other features. 

The interviewing non-testers had little ability to assess this without the guidance. Personally I think having the non-tester interviews first (which were longer than these sessions) was probably the wrong way to do the narrowing down the candidates.

The "cultural fit" people assess in interviews means we often look for people who look like us, talk like us and appear to fit in. But it leads us to choose people who might not fill in the gaps we have. 

And what if the best of testers in the lot never got to the finish line because they were dropped out by people who don't have the necessary knowledge of what testing by someone who knows how to test looks like? 

If I ever again move, I will suggest testing together in my next interview. With or without bugs, you see the way the person models the application and the system, and if nothing else, the recruiting managers would need to get better at recognizing skilled testers. 

Know Your Ground

There's this feeling when you join a new company that says you want to fit in. You want to please. You want to figure out what they do and how they do it, and not rock the boat too much.

It's not that you're afraid for your work. You're afraid for your ignorance. There's things you just can't know.

But then there comes these moments, where you need to not please but stand your ground. Bring in what you're about. I've had a couple of those moments already.

A senior team member assigned responsibility over the team suggests I could include all my ideas and comments and tasks in writing in Jira tasks. It very soon became obvious that my idea of testing (exploratory testing) and their idea of testing (test cases) are not an exact match. I suggested we experiment with what will end up in Jira. The contortion to the good testing I do to make it appear pre-planned (over continuously learning) and linear (over visual connections) just isn't something I volunteer to do even when asked.

A senior colleague advised on how to improve things and get to where I've taken my previous team: daily releases. I respectfully disagreed on the ideas, and suggested small changes regularly, almost continuously to assess if a direction we believe in would be the right way to go.

I look around, and I see too many people who step down and do what is asked. The ask was clear, why wouldn't the action be?

As a tester, I'm supposed to know how I do good testing. If something asked of me takes me away from that or makes me partially  go away from that, I shouldn't stand down without a good discussion.

I know my ground. I stand my ground. I negotiate and experiment, and move. But the starting point is that I know where I'm coming from and where I'm going. I believe this is a big part of why I love my work as much as I do. I'm not a victim, I'm an active player. 

Other lessons shadowed by Mob Testing

Reflecting what discussions took place in the last two days of Mob Testing on a course, I realized there is a pattern I think I'm seeing when teaching in this format:

Mob Testing overshadows the other testing lesson I'm trying to teach. 

Regardless of what my first exercise on testing is, people talk only on observations about Mobbing. And that is not a surprise: mobbing for majority of people is awesome new experience and they need to share both their love of the experience and concerns on "this wouldn't work at our office". And then there are sometimes some people who hate the format. I've now met one who describes the experience as causing anxiety "my brain melts and I can't think". But all in all, the focus with first exercise is in the mobbing.

During two days of mob format exercises, the discussion changes back away from the mechanism of how we learn to what we are learning about. So it feels that mobbing eats away the other learning for people unfamiliar with the style and I need to adjust my teaching to accommodate that.

Instead of having my first lesson in mob being a central one (like ability to create Selenium scripts or Exploratory Testing with Charters), I need the first one to be something people know already.

It's hard to pay attention to all the learning going on at once. Need to figure out leveling things appropriately. 

Mob Testing meets Automation

Some months ago, I received an email inviting me to do a public test automation course in Jyväskylä, Finland. This course would be my third in series with the same title over several years, last edition being in 2013. Thinking about it a while, I decided to go for it again.

Since 2013 I've learned a lot more on test automation. I've also learned how I rather teach things on courses, creating experiences where the whole group shares the experience. For that, I use Mob Testing (or Mob Programming).

I completely redesigned my 2-day Test Automation Course to be around five experiences in Mob Testing format.

1. Creating a basic Selenium Webdriver test (4 times...)
2. Refactoring a basic Selenium Webdriver test to Page Object Pattern
3. Test-Driven Development with JUnit
4. Test-After and Test-First ApprovalTests 
5. Changing Web Application for making Selenium tests easier 

These are all pretty simple first experiences, but as per feedback, people loved the format and enjoyed the experiences. I was particularly pleased with my improved skills on TDD, reflecting to the time when I did my first course as participant and escaped due to my extreme discomfort for lack of understanding. I loved seeing my "I never coded" testers work as part of the group and pick up what we were doing in this format in ways they wouldn't have without the group (or my) support. 

The redesign left 6 slides from my past course. The delivery left me with ideas of what to clarify / improve, and I definitely will do this again.

The Integration ApprovalTests

With my last day at Granlund, I want to share one of the proud moments we've had here with  my team with our test automation efforts.

Unit testing was never easy for us. With all the people in agile conferences talking about unit testing as if it is the most natural thing any developer could do, I found that either we're worse than everyone else (I doubt it) or the conference speaker circuit isn't representative. Knowing that many (even most) organizations struggle with unit testing helped.

We did try. I helped developers clear up time from schedules. I found us teachers to do workshops with us. And the project manager would follow some of the numbers very proudly, even reporting them as part of his monthly steering group reports (that never really made sense to me).

I asked about qualitative stuff: how did the developers feel creating and using them, was there examples from this week they could mention where a unit tests helped them and while there were some, it wasn't a very good experience. We addressed the feelings is not knowing what is worth testing, not being able to test things where architecture wasn't built with tests in mind and many more. Over a course of two years, we still kept hitting the same wall: perceived lack of value.

Seeing some agile developers test (TDD), rely and love their tests, it was clear that we were missing something. But TDD did not turn out to be something that could be easily introduced regardless of firm belief (on my part) of its value.

So we added first database checks and created a lot of value through data monitoring. I've written about this before. With architectural change to our printouts (the main thing our end users want out of the system we're producing), there was a chance of driving for API that would enable automated testing of some of the more complicated stuff to test manually.

We separated pushing the data into an excel with formatting functionalities into a layer of its own, and all the functionalities related to getting the right data right was separated. While conceptually the unit testing of all this was still too hard, the idea of testing against the API wasn't. And we used ApprovalTests to make it even more easy.

We created the scenario to test into the database manually using the application, and added an ApprovalTest for each scenario to keep track of getting the right contents back.

With ApprovalTest, the contents got automatically saved onto an .approved -file and formed a golden master - alert us if this changes.

We created 20 scenarios and started using them as part of our continuous integration. 

Over the course of a year we've had these, they have failed for us for reasons. They've saved us many times from side effects none could foresee.

We also have some unit tests with ApprovalTests, in particular with combinations approvals. It might take a moment to understand that your test is the code + the file, but when you do, this makes a lot of sense. And most importantly: it made practical sense for us in a situation where we were not ready for all the great and fancy ideas related to TDD.