Lena Wiberg, Author of Would Heu-Risk it? Tools, traps and weapons for Software Testing

Len: Hi I'm Len Epp from Leanpub, and in this episode of the Frontmatter podcast I'll be interviewing Lena Wiberg.

Based in Stockholm, Lena is a software testing expert and public speaker who helps build teams and organizations. She's currently engineering manager at Mentimeter, which makes interactive presentation software.

You can follow her on Twitter @LenaPejgan and check out her website at pejgan.se, and read her blog at testing.pejgan.se.

Lena is the author of the Leanpub book Would Heu-Risk it? Tools, traps and weapons for Software Testing.

In this interview, we’re going to talk about Lena's background and career, professional interests, her book, and at the end we'll talk about her experience using Leanpub to self-publish his book.

So, thank you Lena for being on the Leanpub Frontmatter Podcast.

Lena: Thank you so much for having me.

Len: I always like to start these interviews by asking people for their origin story. So, I was wondering if you could talk a little bit about where you grew up, and how you found yourself initially at the beginning of your career as a software developer?

Lena: Wow, we could talk about that all evening. My parents actually had this weird thing, or my dad had this weird thing - where he just kept moving. I grew up in the southern part of Sweden in what's almost Denmark, and then I've lived in Stockholm and in - well, almost half the way up in Sweden, depending on where he wanted to try living for a while.

So how did I end up in testing? Well, my dad had a home PC pretty early, so I grew up with a computer. Not in the way that most of my male friends did with like programming, I did more of - weird things like spreadsheets, and write essays and things.

I kind of slipped into softer Computer Science education. I got my first job as a programmer, and it just went from there.

I found testing about ten years later, which is sort of the wrong way around, if you ask the career coaches - but testing was a more, it was a different challenge. It was more of an intellectual challenge, and less of a logic puzzle. So that suits me.

Len: That's really interesting. I'd like to ask you a little bit more about that. But so you studied Computer Science, and I believe - statistics?

Lena: Yes. They meant for us to do some sort of economics as our minor, and I did everything I could to get out of that. Which, weirdly enough - ended up being statistics, which in hindsight is even worse. But yeah, it's been useful for something, I guess?

Len: This is a question that I ask in various forms to most of the guests who are on the podcast, because so many people who've written Leanpub books are in programming and software and stuff. But if you were actually starting out with the intention of having a career - let's say, in testing, now - would you do a full Computer Science degree, or would you choose another path?

Lena: I picked kind of the middle ground, because I didn't do the - in Sweden, there are engineering educations, and then there are kind of the softer computer skills programs, so I took that part. And there's also more like a fast track now, with bootcamps and niche testing, or specialized technical - it's called something like "higher vocational college," or something like that, I think? It's very weird.

I would probably have gone for the more pure engineering education, if I had done it today. But I was a bit too tired of school when I had to choose - and picked what seemed like the smoother ride, with more of the human parts, and less of the math.

Len: I was wondering if you could talk a little bit about what your first programming job was like? I think you're - the year of your first professional job was the same as mine, which was 1999, I think?

Lena: Yes.

Len: And things were a lot different back then. My job only existed basically because of internet search. I was doing research on global mergers and acquisitions. What was it like being a developer in 1999?

Lena: Well, first of all - that's the last year you could easily find a job as a programmer in Sweden. The class after mine, they struggled to find their first jobs. So a lot of the people who graduated a year after me, they ended up in different jobs. They are not in computing anymore.

I had the luck of being that last class, where we still could find jobs. I got a job at a company building software for the Swedish Church. So incredibly niche. They built the software for planning graveyards, for booking churches, for inventory. But they had one customer, and that was the Swedish Church. So my first big project was actually building their new salary system. So Again, back to the economics that I wanted to avoid - but it's been following me my entire career.

Len: That's reminded me, a former guest on the podcast was - one of his jobs was for the Church of Jesus Christ of Latter-day Saints, or the Mormons - and it was particularly about the way they decide who to send where on their two year missions that they do when they're young. So doing work for churches, you're not the first person on the podcast to have done it.

But when you say - actually, this is just kind of curious - when you say the Swedish Church, I'm assuming that's a Protestant denomination?

Lena: Yes.

Len: Okay, okay. I guess we'll have to look it up, anyone listening who's not aware.

Lena: There are probably other like Christian churches, but the Swedish Church is the big - it's the one that has almost been connected to the state, but not really.

Len: Okay, that's really fascinating. And so, you did that for, you did programming for about ten years, and then you realized that there was a different kind of challenge that you wanted, and that - I think a lot of people listening will understand what you mean by the sort of logic challenge of programming. But can you characterize the challenge that is particular to software testing?

Lena: So after ten years, I found that programming was a lot - solving the same problem over and over again. The challenge was not in the code anymore. I mean, I could probably have found it in learning another language, or shifting companies. But it felt like I was doing the same thing over and over and again. And I, as a relatively young woman still in IT - I struggled as do many women, with kind of getting traction. So I tried to ask to move into architecture or tech leadership, and I was just shut down.

And then - I have no idea why, but testing was something that we suddenly started focusing on a lot. So I said, "Well, I think testing could also be interesting." I was focusing more on the test leadership, so more like, "How can we be better? How can we do strategies that are more smarter?" I wasn't that interested at the time in the like - sitting, testing a web application. It was more about the planning and then the bigger picture.

So they sent us on a basic testing training - very traditional, very old school, very ISTQB. And I just loved it. Because I could see it was more about figuring out how to find cracks. Less about the building, and more about finding kind of weak spots. Finding where the pattern doesn't really match, and that's always been something that I'm good at. So I thought, "This could be a fun - something to try, a new career." And then I realized that it was really, really fun to kind of figure out where the hidden risks could be.

Len: It's interesting. Your book is partly about risk, and then there's - software testing is such a - at least to me, it's such a fascinating subject. Because there's so much involved, particularly what you might call politics, right? Because if you've divided up the work into, say, the people who say what the software is should do, and then the people who have to deliver that - and then the people who have to find the problems with it. If you're in the first two groups, you might have an antagonistic relationship to the third group, the testers - who might, who are sort of -

One way of thinking of testing is that it is an antagonistic activity, right? Like you're kind of going in and trying to break things. You're trying to find weaknesses and flaws, or what other people might think of as mistakes. How have you seen, in your career - things evolve, when it comes to understanding that relationship - say between the people who are programming, and the people who are testing the programs that they build? Or have you seen a change?

Lena: So, I never understood that testing was seen as something less than programming. Because when I started there in 1999, we did everything. We did requirements work, we did design, we did the front end and the back end, the database, and we tested, and we did the trainings for the users - and we produced the CD discs to actually send out for installation. So to me, it had always been a part of my job, and the company I was at valued testing a lot.

So I never understood, until years later, that it was seen as me actually kind of stepping down the career ladder, to move into testing. I also think I was lucky that I had - they already trusted me, and they already knew that I knew what I was talking about. So I didn't get a lot of the pushback that a lot of other testers did. That was a big kind of culture clash for me - when I started talking to testers outside of my company, where they were seeing their salaries were lower, and they had to fight to get their issues fixed. I was very, very confused, because I never had that.

So I think - listening to other people, they have probably seen a shift to the better. But for me, I moved away from companies where I was known and trusted, and had all of that kind of trust capital - into new companies. So for me, it was almost the other way around.

And then - I mean, there are a lot of companies that claim to be agile, that aren't really. That try to push testing into - because it's always seen as a cost, instead of - I mean, for me, it's an obvious money saver, to spend a lot on testing - and especially testing early.

But in a lot of companies I've been in, kind of my mid-tier testing career - it was seen as a cost, and something that they wanted to push back. So I actually - I left one company, because I figured out that the upper management actually wanted to transform all of my testers into programmers. And I was like, "But that's not what they are good at, it's not what they want to do. Why do you want to do this?" So for me, the shift has probably been opposite of the shift other testers have seen.

Len: Thanks very much for sharing that. I think you captured a lot of the complexity there - partly that there could be trends in one's personal career, that don't necessarily match the industry in general.

But also, it's interesting - I think people who aren't from within software industry, might think of it as just a kind of dry exercise, when in fact it's - like everything else, it's made of people. And the reason software testing exists is because - and I think we'll get a chance to talk about this in a little bit - but you don't want that plane falling out of the sky. Or back in the old days, when you shipped programs on CDs - if there was a problem, there was an unfixable problem in there.

You have to have people testing stuff, to make sure it works. But then somehow, you end up with a weird presumption of hierarchy, like the one who's testing it is just kind of - what's the old cliché about testing video games? Where you're on a race track and you just hold the wheel to the right and scrape into the wall until something goes wrong.

And it's like - no, it's way more complicated than that. You have to understand what the software is meant to do, you have to understand how it's been built, you have to understand what it's for. And you're not just going in there to break things, you're going in there with a sophisticated understanding of what the whole group is trying to achieve.

But within the group, you're separated in teams - maybe you don't even talk to each other? Maybe there's just someone who's a manager, who's got someone they have to speak up to about like, "Are we going to be able to deliver this software on time?"

And then - just inevitably - you end up with someone being treated like they're hostile to the whole project, because they report an actual problem.

You spoke earlier about like getting money - you have to get budgeting, time and money, and programmer time to fix problems, and having to - I guess, what's it like to know there's a problem with something, and meet resistance from the people whose job is to deliver it, who are themselves going to be faced with the calamity of their own rush in the end? What How do you deal with that?

Lena: I think in my early testing days, it was extremely frustrating. I tried to fight for everything. And that, I think, is something that a lot of junior testers do. Because we get a bit obsessed, a bit control-freaky. And we're like - we see these things, we need to fix it.

I hate traveling, because I see all the things that can go wrong. And when people ask like, "But what's the worst thing that can happen?" I say, "Well, I'm a tester. I can tell you exactly what's the worst thing that can happen. And the second to worst, and I have a list. It goes down, and do you want probabilities? How detailed do you want it to be?"

In my first years, I spent way too much time on fighting battles that weren't always the most important. And I got really, really sad when I couldn't, as I felt - win my battles. I learned along the way, as you said - it's so much about relationships. It's so much about building trust and using that trust. Figuring out who the person you need to convince is. What's their drive, what motivates them?

Because as soon as you know that, it's extremely easy to get your point across. Because you can aim your message into that tiny gap. So if you have a project manager that's really, really worried about security - it's very easy to use that against them, manipulate them - which makes me sound horrible. But knowing the people you work with, knowing your stakeholders - makes it so much easier.

The last years before I moved into more pure management, I rarely had any problems - that kind of problem, because I knew how to make them listen. But also - more importantly - I knew how to actually accept that I couldn't fix everything, and I could try, at least, to let go of the things that I could see, "Well, maybe if it happens, it will be extremely bad, but the likelihood of it happening is almost zero. Then, fine - perhaps we can ignore that." I know there a lot of testers out there struggling with being seen as kind of the enemy.

Len: And do you think, ultimately, that it's the best way - to have this kind of distinction between a developer or an engineer and a tester? Or should everyone have to do some testing as just a routine part of their work?

Lena: It's a tricky question that I really don't know how to answer, without being impolite to someone.

Len: Okay.

Lena: I think there is a lot of testing that is better done by the developers. There is a lot of testing that is better done by the actual users. There is a lot of testing that's better done while you're still at the drawing board, asking questions early.

But I think you need someone who has that as their main focus. It doesn't have to be in the entire process, it doesn't have to be all the time. But if you're constantly switching between delivery and building something, and trying to find what's wrong with your solution - I don't think you get all of the pictures that you need.

But I mean, I've worked with developers who are better testers than most testers I've worked with. And I've worked with testers who are better developers than most developers I've worked with. It's just that they found a particular part of developing software most, more important than the other.

Len: It's really fascinating too, the question of - in security, they talk about red team versus blue team, right? So if you've built a system that you need to be secure - you actually want to have the most aggressive, smartest people on your team, trying to break in.

But at a certain point - you're only building that thing in the first place, in order to go in the world and do something. And so you have to have some threshold that you cross, where you say, "Okay. Well, good enough. We know from our testing - or our team games, and stuff like that, where things can go wrong potentially. But we just have to go out there."

Is that something that is decided on a case by case basis, or is it -? I'm asking this because I don't know, is it -? Or is, within a big company - would there be like formal specifications for, "Enough of the lights are green that we can go out now?"

Lena: I mean, there are still companies out there who do extremely detailed test cases and reports and s-curves, to see when bugs are starting to drop off and all of those things. The span in the industry is from - the way we did it in the sixtiess, to basically doing nothing - except watching it while it's in production. I mean, of course they do something, but not like formal testing in a way. And there's everything in between there.

I've worked a lot in like old traditional companies in Sweden, like insurance and banks and such. And they have a lot of requirements for being able to trace back. If something fails, we need to be able to show that we actually - what did we check, what didn't we check, why did this fall through the gap? So they do a lot of the - what people see as boring testing - following scripts, checking off lists. Doing like reports with minor or major critical bugs, and statistics and dashboards.

And then there are other teams where they - basically it's more of a hunch. "Do we feel safe enough to release them? Yes, let's release." I think I trust the gut feeling more than the reports, but I also understand why we need the reports in certain industries.

Len: I think in one of the talks that I listened to in preparing for this interview, you talk about, "You can trust your gut." But that's only after you've had many years of experience that then you've like - it's not exactly right to call it an instinct at that point, right? It's a very developed sensibility about things.

Lena: Yes, definitely. I mean, gut feeling is just you using everything you've learned and like déjà vu, you've seen it before - so you know that's it probably going to happen, or not happen again.

Len: In one of your talks that you give called Delivering fast and slow and "On the ethics of quality", I believe, you talk specifically about [the Boeing problem](https://en.wikipedia.org/wiki/Boeing_737_MAX_groundings that we've all heard about.

Lena: Yes.

Len: I think you go into some detail about it, I actually didn't know the story. So, I was wondering if you could actually maybe just tell our listeners the story about what happened at Boeing? I'm sure everyone's familiar with the planes falling from the sky and what specifically the issue - or the issues were. So then we can talk a little bit about that in the context of the talk about testing and ethics.

Lena: A lot of what I talk about in just that talk is also collected from different reports and blogs and interpretations other people have made. So I mean, I wasn't involved in analyzing the problem. I'm not an expert on the subject. But I think it's a very, very interesting catastrophe. Because it was so many things that went wrong, which is usually what I talk about in that talk - it's usually not one big bad decision, it's a number of bad decisions.

In the case of Boeing, it was - well, it started with money, of course. A competitor said that they had a plan to produce a new airplane with less cost, less fuel, less climate influence - all of those things. So Boeing decided that they had to do it, them too. And what's the easiest way to do it? Well, you take something you have that you know works, and you adapt it. So they did that, they took their most popular airplane model and they looked at it and said, "How can we make sure -? How can we reduce the fuel cost of this plane?"

And in doing so, they did - I mean, looking at now, it's so stupid. They built bigger engines, because bigger engines are more effective. Bigger engines are heavier - so it affected the balance of the plane, so they moved them. When they moved them, the nose of the plane tended to dip, so they - instead of redesigning the aircraft, they built software to adjust that tip of the nose, which is like in hindsight, "Why? Who came up with this?"

That was basically the first problem, that they tried to take the cheap route to doing this. Instead of designing a new airplane, because that would take too long. They took what they had, and just slapped some plastic padding on it.

And then in addition to that, there was a lot of money involved. So they pushed for faster processing time. There were a lot of issues that were hidden under the rug. They decided that - no, they didn't decide. There's an association that decides if an airplane can fly, I don't remember the name. American Association for Aircraft or something? They decided that the pilots didn't need any new training because they already had hundreds and hundreds of hours in the old model.

But the new airplane behaved completely different while in flight. So basically all of those problems led to the plane - there were two sensors that were supposed to measure the angle of the tip. And they, of course, were faulty - so they signaled that the plane was dipping, adjusted it. The pilots weren't ready for the autopilot suddenly just yanking the plane up. And then in the end, they crashed multiple planes.

Len: Thank you very much for sharing that. It's - as you say, yeah - in one of your talks - that catastrophes like that don't happen just because of one big decision, even though it's one big catastrophe in the end. There's lots of little decisions made along the way - including letting things go, right? We spoke about how like sometimes you just have to do - let things go out the door, but sometimes you know that it's wrong.

I think you talk in some of your other talks about having - you have to know, when you're in software development or in testing or in any - basically anything - you have to have a bottom line. Or you should have a bottom line, and think about where that is.

And in determining where your bottom line is, what you think about is the stakeholders. Whose interests are you really supposed to be serving? How do you go about thinking about that when you're working on things? Do you think about the customers first, do you think about the people the customers might be affecting? Do you think about how things can go wrong?

Lena: I've had the extreme pleasure of working with insurance software for most of my life, and the good part about that is that the limit of error is very, very low. So it's okay to be very picky.

When I switched to other types of businesses where were more in media or e-commerce, they're suddenly - all of my old - because with insurance, the customer is supposed to have the right decision, they should have their money fast, and they should have the right amount. I also worked at companies that had the idea that if - they didn't reclaim money if we did it wrong, they only reclaimed money if they could prove that the client had lied or something. Which I mean - it was very, very nice because it was a kind approach to insurance.

So for me, it's always been easy. Because I've mostly worked with software where we could see that the end result for someone could be very, very bad. We worked with customers that had very little income, they were depending on the money they got from us. So it was easy to see that if we did something wrong, it could end with someone not being able to feed their kids.

So for me, the moral has been - I have a very strong moral core, which is not always a good thing, depending on where you work.

I would never have been able to work in a company like Boeing or Volkswagen or any other, where you have to decide to put the money first in situations. But I guess - for me, it's always been - again, the gut feeling. "If something goes wrong, will I be able to live with having made that decision?" Which is of course extremely easy if you're a white, middle-class woman in Sweden. Because the - I would probably not starve if I lose my job. And I'm in software, I'm in building IT - I can find another job. It's not as easy if you're just starting out, or in a country where the welfare isn't as good as here, so -

Len: Yeah, in one of your talks, you set up a sort of a team of people who are all in different roles, and one of them is someone who - it's their first job. They just got it, and it's - I really like the way you told that story, right? That like it's not - when people accept shortcuts, or they let something go - it's not necessarily a straightforward thing about greed. It can be about the personal circumstance that they're in.

I mean, you always have a choice - but not really sometimes, right? You might have obligations to other people. You might have a family, things like that - people depending on you. Or you might just be one paycheck from not having an apartment anymore.

When you're facing that, questions become a lot less straightforward than they might seem, and when you see the end result of all kinds of little decisions where people let things go - in order to really address the hard issue, you actually do need to be empathetic about things like this.

Just before we move on to talk about your book, I wanted to talk to you a little bit about the experience I read about in your blog, I think - about - you got a new job in February 2020.

Lena: Yes.

Len: We can all probably go back in our timelines to what happened a few weeks after that. And so you had a few weeks in your new job, or a few days in your new job, before going remote. I know you've written about this in a chapter [in another Leanpub book](https://leanpub.com/softwarepeopleworkfromhome, but I was wondering if you'd be willing to talk a little bit about what your experience was like going remote?

Lena: Sure. I think it was my third or fourth week where we decided, "Just send everyone home." And the first decision was, "Let's just go home for two weeks and see what happens."

I was a manager for a pretty big, complex team of developers where we - I was spending so much time getting to know everyone, getting to know the company, the application - what parts am I responsible for? And then suddenly having to just send everyone home and move into some sort of crisis mode - where we focused - every minute of the working day, we spent on thinking of scenarios that could happen.

So what happens if 50% of our developers get sick? What happens if the school closes? What happens if everyone gets sick? What? All of the the worst scenarios to probable scenarios, and how will this affect us and the business?

I was exhausted after two weeks. Because I was in full panic mode for two weeks. I'd never worked so much. I wasn't in front of a computer screen so much, but I kept thinking of - who has kids? Where do they live? Do they have a family that they can lean on? Is anyone alone? Is anyone having mental problems before? I had a few people on 50% sick leave, how will this affect them?

And then also - as a tester, one of the things a lot of us talk about is, being the social glue in the company. So we - specially the really, really good testers I talk to - they have a skill of hearing something in a conversation, and connecting that to something they heard at the coffee machine, and then being able to bring these two people into a room with a third person. Because they realized that that team is doing something that will get affected by the things that these two people just said.

And that just disappeared. Because all of the social mingling, all of the coffee chats, all of the hearing someone talk about something while you pass - all of that just disappeared. A lot of the things that I focus on as a manager, body language and, just how does the person feel in the room? I have a lot of these weird - there's probably like pheromones or smell or something that you - just as with the gut, but it feels a bit like magic. You can almost taste if someone is stressed, even if they aren't saying it. And all of that is gone on the other side of the screen.

It was an interesting couple of months before I realized that I might be extremely stressed, but my team members were great. They loved it. They loved working from home. They were using the extra time to exercise, they ate better. They did everything right.

And at the same time, I was eating McDonald's while in front of my screen, not sleeping. Eating sleeping pills to even get a couple of hours. So, slowly, I accepted that they were as fine as they could be, so I just had to learn to live with it.

Len: And are you going to the office now?

Lena: We have opened our office. We have a very, very big office - and a lot of people choose to not be there. In theory, you could work four or five days a week from the office, if you like - because there are so many people who don't feel comfortable doing that. I have been a two days a week at the office, three days at home situation. I also have the luxury of working for an employer that actually helps me a lot with like, "Take a cab, if you need to take a cab to the office. Don't go with the commuter train. Or do you need something home to set it up? Or do you need a parking space? How can we make this so you feel safe coming to the office?"

Len: Thanks very much for sharing that. It's really great to hear everybody's story - the good parts and the bad parts. It's really nice when people share it. Because sometimes we keep these things to ourselves, our challenges to ourselves - and then we think we're alone, and no one else has gone through the same thing.

At Leanpub, we were a remote team when the pandemic started, but one thing that was new for us was onboarding people who we'd never met. I've now worked with a number of people that I've never met in person. I don't even know if I'd recognize them or - like you would after a minute, right? But we managed - It took some time, and it took some trial and error - but we did end up with a pretty robust onboarding system that seems to work.

And yes, providing people with the right equipment actually is really important. Providing them with the sense of like, "We're going to take care of what needs to be taken care of," is also really important. And yeah, I think - I mean, everyone all around the world has been facing these challenges, and seeing the ups and downs.

The last pandemic-related question I wanted to ask you is - we've been having a pretty serious talk so far - but is about gaming. I know you're into gaming a bit.

When I was first preparing for this interview a couple of weeks ago, I actually laughed out loud when I was flicking quickly through your Twitter feed. Because you have this one tweet about a list of accomplishments. And it was like, "I did this, I did that, I did that, and I avoided the boss fight in Skyward Sword by not starting to game."

The reason I laughed out loud was - because I was, at that moment - in my gaming world, there was this boss I had to fight in Skyward Sword and I was like, "Goddammit, I'm just going to go collect bugs." But actually, playing videogames has helped me deal with being home so much, and stuff like that. Have there been any particular games, videogames or board games or otherwise - that you and maybe you and your family have particularly enjoyed during all this time together?

Lena: I mean, we are a family of four gamers. So I don't think that's changed that much. I must say Skyward Sword is probably not my favorite. I like parts of it, but the bosses are horrible.

I went back and played through the second Ni no Kuni game and the Dragon Quest something - can't remember which one. But two Japanese RPG games. So they're cute - there's a catastrophe going on, you have to save the world. It's very fitting.

Len: Yeah, those old Dragon Quest games are some of my favorite. I always like - it's funny because like you enjoy getting to the end, but the beginning is always - to me - the best part, because you know you have this whole adventure ahead of you. Hopefully not full of the same monster with eight arms just drawn differently, and you have to hack them all off some arbitrary number of times before you finally hit the gem in the middle. Sorry for anyone who's listening who doesn't know what we're talking about but it's -

Lena: I know exactly which boss that is, yes.

Len: Yeah. And so, moving on to the next part of the interview, where we talk about your book.

So you've got this great book called Would Heu-Risk it?, which is a play on heuristics - "Tools, traps and weapons for software testing." I was wondering if you could talk a little bit -? It's a unique book, it's a really fun book - and I was wondering if you could talk a little bit about how the book works, and what your inspiration was for putting it together?

Lena: Sure. It started with Lisa Crispin - one of my big testing idols, one of the people who shaped me as a tester with her books. We are members of the same Slack group, and she offered to do workshops with new voices. I asked her if she wanted to do one with me, so we agreed to do a workshop together and we - the only thing we had decided was that it was to do with something with risk. Because that's something we both do a lot of talks and workshops on.

And also, I really wanted to figure out what the hell this heuristic thing was that everyone was talking about. Because it's something I hear people talk about all the time, but I just couldn't understand what it was. I had been reading a lot of great blog posts about it, so I was like, "Well, I want to do something with heuristics. I want to do something with risk. What can we do with that?"

And we had - there's a deck of cards called TestSphere which is, of course, a big inspiration. It's the same type of deck, but I also wanted to bring the gaming aspect into it. And one of the other women in our Slack group, Trish Khoo - had some designs of old - I don't know what they're called. It's like card decks with role playing games. When you have like a figure, they have an attack score and a defense score, and maybe a little text. I was like, "What if we do something with this?"

So it started with the workshop that ended up as a card deck that was available for sale. And then once that was done, I thought, "Maybe I can do a book about this?" So I decided to write a blog post about each of the cards. And then I transferred those into a book.

Len: And the way the game works, if I recall correctly is that - you've got these awesomely drawn, really fun cards, which have a cartoon image with animals, which is always great. And then a riddle. I think the way you're supposed to play the game - I mean, you could play it with yourselves or with other people. But you look at a card, you see the image and you read the riddle. Then you try and think about how that would apply to testing. Is that how it works?

Lena: Yes.

Len: Okay.

Lena: There's a title that's a hint. The picture is connected to the title. And then there's a rhyme that tries to vaguely explain what this could be about.

It's meant to be open to interpretation, so it's more like a tarot card reading than a formula. You might get something that tells you, "What if everyone is not like you?" And then you think about a project you're working on or a problem you're thinking of and, "Okay. Could there be a problem with me being biased to people who aren't like me?" - for example.

There's one about - my mind, it's about all of the different problems that come with culture and localization. We tend to think that we know that something works in a particular way, like addresses or social security numbers - or names, or anything. And when you start looking at the different parts of the world, almost all of those truths are wrong. So that's one of my favorite cards. Because you can always spend years on testing just, "Would this work in a different country? Or did we build the software wrong?"

Len: I think my favorite card image is the glutton, which is this big purple dragon feasting. I think my take away from that one - and it's great - because you get to see the title of the card, the image and then the sort of riddle or little poem. And then in the book, you have these posts where you talk about what's going on there. But the glutton, you can see that as the image of the person who just wants testing to never end. "Just give me more and more and more. Let me go deeper and deeper and deeper."

My favorite one, though, is "Fool's Assumptions." It's partly because it's about language and the - I'm going to read the - Just to give people a sense of the flavor. So the image is a picture of a bird with a jester hat on, dancing and very cheerful - at least as I see it. And the riddle goes, "Friendly questions save the day. Make foolish assumptions go away. Who knows if they meant what it means for you? Keep asking why, what - and of course, who."

That line, "Who knows if they meant what it means for you?" gets to the heart of - I mean, not just in testing or software - but like just a fundamental problem of human cooperation, which is that people can use the same formulation in language to mean very different things. And it can be hard to see through that.

In particular, when you're working with people on teams for a long time - words take on their own meaning. You associate it with, let's say, a particular part of the code or something like that, right? You have a little nickname for it. But then, I don't know why this particular problem like is an obsession for me - but you can see it happening, where the meaning of a term is getting fuzzy. And people start using it in different ways, and the real - the reason it's such a hard problem to solve, is that if you point out what's happening, people are going to say, "Oh stop being so pedantic." And it's like, "No, we're going off a cliff here." Anyway, that was my favorite one.

Another really great one is "Alethophobia." Which is about being - I mean, maybe I made that association unconsciously - but it's about being afraid to tell the truth.

Lena: Yes, it's the fear of truth.

Len: Which can again, yeah - as you were saying, you can approach the fear of truth from many different directions. And what that means is, is the person who's responsible for delivering the project on time afraid of the truth? Is the person who's - as we'd spoken about - with maybe crossing their own line and letting it go, afraid of the truth? Is being afraid of the truth necessarily a bad thing? Things like that.

Just another one that I really like is "Drowning In The Deep." Depth and shallows play a role in a lot of these. This one is an image of a diver in an old-timey diving suit, with a hose connecting him to the surface - but with tentacles reaching up at him from basically a giant squid, while he's looking at a cute little squid right in front of him. And that one goes, "I'm glad you dared to take that leap. Hunt the treasures hidden deep. But beware - just don't get caught and end up drowning, learning naught." Which is another great lesson which is - where did I hear this recently? You either win or learn.

Lena: Yeah.

Len: And keeping that thing in mind can be really important. We're not going to go through them all, but just to give people a taste of - it's a really great book, it's really fun. And it's really great too - because it gives you both the sort of, like I said - the fun of these riddles and images and stuff like that, but then actually a serious discussion of what they're all about.

Just moving on to the last part of the interview, I was wondering if I could ask you why you chose Leanpub as the platform for writing and publishing your book?

Lena: As you mentioned early in the interview - a lot of Computer Science, programming, testing books - tend to be ebooks. I came across Leanpub maybe like seven years ago when I - maybe five years? I can't remember. But a few of my female testing friends had written books. One is Testing in DevOps by Katrina Clokie, Exploratory Testing by Maaret Pyhäjärvi, of course. So I knew about Leanpub, and I had an account because I had bought books there.

It started with me just trying it out and figuring out along the way how to do it easily. I've also been collaborating in a couple of testing books. Around the World in Software Testing I think it's called - I can't remember the title exactly. [It's Around the World with 80 Software Testers - Eds.] I'd have to look it up. But two testing books, which are collections of stories from around the world.

So I had done Leanpub through them, but they used the GitHub approach - while I did everything online.

It probably gave me a bit of headache, and it made me sad at times. But it also was very easy to visually see how it was going to look, and in the end, it was just a very easy to get started - very hard to get stuck on details, a lot to learn about the markup language. And of course, you always want that one formatting option that you don't supply. But I think the end result ended up very good.

Len: Thank you very much for sharing that. Actually, I should mention the other book was Software People … Work From Home, which is also really good.

Lena: Yes.

Len: But yeah, when it comes to problems - you used our browser writing mode. And yeah, I mean - the last question I always ask is, "If there was one feature we could build for you, or one thing we could fix for you that you really hated and caused you consternation, what would you ask us to do?"

I guess we'll have to bracket here, how we deal with account upgrades. Because we had an unfortunate hiccup with that, which is something that we are actually working on improving.

But other than how we handle account upgrades, what's the thing that - if there's more than one, please share - but what's the thing that like caused you the most shouting at the computer or banging on the table moments?

Lena: I think you're not going to like the answer, because I've read a number of articles that you - it's a deliberate choice. But I dislike that I couldn't format my - Jesus, what's the name? The contents, the list of the chapters.

Len: Oh, the table of contents.

Lena: Yes. It annoyed me a lot until I let it go.

Len: Actually, what specifically were you trying to do, that you couldn't do?

Lena: I wanted to have more formatting options, because it ended up very large or very empty. There was like no middle ground, and that could probably have been fixed by doing the chapters and the sub-parts in a different way, but it - I ended up with either a table of contents that was ten pages long, or it just didn't look exactly the way I wanted it to.

Len: Thank you very much for sharing that. So would the ability to like - because the way our table of contents works - is it basically looks at where you've got chapter headings and subheadings and then sub-subheadings, and things like that - and generates it automatically. But were you more looking in -? Would you have liked to have been able to like type out things specifically for each entry in your table of contents, or have more control over the font size and things like that?

Lena: I think being able to have a different font size for the table of contents, so I could squeeze that - that could have that smaller, while keeping the rest of the book bigger. That would probably have been good.

Len: Okay, okay.

Lena: But the end result ended up good, it just - took me a lot of time to get it where I wanted it to.

Len: I'm actually going to add that as a story in our discussion queue, as soon as we're done with this interview. Because we do actually have global font size settings for different things, but we actually don't have them for the table of contents, and we actually - we have like line spacing and spacing in between paragraph settings that you can do, and stuff like that. But we've just never applied that same mechanism to the table of contents before, and it totally makes sense that one would want to do that.

Particularly, I mean - one of the reasons I guess I'm particularly sort of sensitive - is that like, it's the the first thing you see. And I can understand wanting to have better control over that first thing that people see, and also - if you make a sample book, people see the table of contents, or it might even be on your book landing page - and so you want to show people what's in the book, to help encourage them to see that that's the right book for them, and they want to buy it. So that's really important.

Well, Lena, thank you very much for being on the podcast. We really appreciate it. I'm sure everyone really enjoyed - even though we got very serious, I'm sure people probably really enjoyed the discussion. And thank you very much for using Leanpub to publish your book.

Lena: Thank you so much again for having me, and thank you for producing the awesome software that makes it easy to publish books.

Len: Thank you.

And as always, thanks to all of you for listening to this episode of the Frontmatter podcast. If you like what you heard, please rate and review it wherever you found it, and if you'd like to be a Leanpub author, please visit our website at leanpub.com.