Nicola Lindgren, Author of Starting Your Software Testing Career

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

Based in Malmö, Nicola is a senior quality assessment engineer and manager, as well as an international conference speaker and blogger with a focus on subjects like software testing, leadership, and agile.

You can follow her on Twitter @NicolaLindgren and check out her website at nicolalindgren.com.

Nicola is the author of the Leanpub book Starting Your Software Testing Career.

In the book, Nicola provides readers with a guide to finding their first role as a software tester, and practical suggestions for how you can hit the ground running in your new career after you've been hired.

In this interview, we’re going to talk about Nicola's background and career, professional interests, her book, and at the end we'll talk about her experience writing and self-publishing a book.

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

Nicola: Thank you 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 your way into a career in software testing?

Nicola: Alrighty. I'm from Auckland, New Zealand. I'm a JAFA, "Just Another Fucking Aucklander." In terms of how I got into testing, it wasn't actually the plan. My plan was to become a diplomat. But the year that I had graduated, they laid off like 20% of the staff. For some reason, they weren't hiring. They were laying off 20% of the staff. So then I had to figure out, "Okay, what next?"

There was a test consultancy in New Zealand that had a grad program. So I did it. To be honest, I didn't know about other roles in IT, except for a developer. I think in a job ad or something, they were like, "Are you curious? Are you interested in technology?" Some sort of stuff like that. And I could relate to what they were saying. So here I am almost ten years later. I moved to Sweden for work.

Len: Thanks very much for sharing that. That's interesting, going from a career in potentially diplomacy, to sort of software testing - is a really interesting move. And if you don't mind, how did you find your way to Sweden? Did you get hired before you moved? Or did you move there and then get a job?

Nicola: Yes, yeah.

Len: Okay.

Nicola: Yes. I met my company at a conference. It felt right. Actually the funny thing is, in my previous company, I initially applied for one of their roles in Switzerland, because I speak German. But the managing director of the Swiss branch said, "Since you're not a new citizen, that's not really a viable option for you. How about Sweden?"

So it's weird. Because people are like, "Oh you must love Sweden." And people are like, "Oh we love Sweden so much." It kind of just happened.

I also happened to meet a guy around the same time when I was moving here. So I was very fortunate to get a work permit and have that sort of security - but at the same time, someone to explain aspects of Swedish bureaucracy to me.

Len: Oh that's really interesting. I've moved around a bit, and a lot of the people who we have on the podcast have moved around a bit. And so, you're saying that being from New Zealand, it was actually easier for you to move to Sweden than an EU country?

Nicola: I'm not 100% sure if Switzerland's the EU. I think they might be like the European economic area? I guess different countries have different requirements around work permits. So I don't necessarily think it was because I was a New Zealander. I think it was just pretty tough for a non-EU citizen to get to Switzerland. Or at least that was my impression.

Len: And how was your first winter?

Nicola: To be honest, the cold's not so bad. Because you can always wear more clothes, right? Like more and more layers. It's the short days. I remember I was working from home a little bit for my first project. And at like 3 o'clock it'd be pitch black. Because we're in Stockholm, by the way, for the first year - so the days are shorter there in winter, compared to Malmö. And I remember, I never really like checked the time.

I would start to like pack down my laptop, and think, "Oh the day's over." And then I like checked the clock, and went, "Oh it's only like 3 o'clock. I probably should still work, I haven't done my hours." So that was probably the most shocking thing.

And then just walking on snow. They do put salt in the ground. But I'm not from a city that has snow. So I'd be often late, because I just walk so slow. I'm very clumsy. So that was first-world problems. That was tough for me.

Len: Thanks very much for sharing that. I partly ask because I come from a place called Saskatchewan in Canada, where it's very cold in winter, and the days are quite short. But nothing like up in Stockholm, which is a few degrees latitude even north of that. And yeah, it is interesting. Of course, the sort of natural thing is to think about the cold. But the short days really do get to you. Particularly, I just remember it being like pitch black until like 10 in the morning, or something like that. And that's just really messes with your natural expectations. I mean, I say that as someone who grew up in that environment. It still seems strange sometimes.

Nicola: Are Vitamin D pills also a thing where you live? Because it's a thing here. But I never really got into that.

Len: Yeah, no. They weren't - I mean, people's attitude towards the cold - at least where I grew up, at the time I grew up, was very reckless. It was kind of like, people wouldn't even wear toques sometimes. It's just kind of rush out to the car, rush into whatever building you're going to. I think it's a lot different now.

And so, you got some training in software testing. And then you got your first job when you were still in New Zealand. What was your first job like? What did you do? Did you get like a long list of like, "Test this, test that, test this, test that," and sit in a cubicle, or -?

Nicola: My first job was at a consultancy for a government project. And the thing is, when you're a junior - I didn't really have much say as to how things would go. I just listened and did what I was told.

And to be honest, I didn't really have the confidence back then to question things. So it was a matter of writing test cases in a spreadsheet, and then uploading it to the management tool. And then the business analysts or someone from the business would change their mind about a bunch of stuff, and you'd have to update a bunch of shit.

I don't really miss that environment. But I am grateful for the opportunity. I mean, I think a lot of people - when you want to search careers, it can be hard to do. So I'm grateful for that. And I made some good friends on the project, so that's the silver lining in that cloud.

Len: It's sort of funny when you're so familiar with these kinds of things - it's kind of hard to know where to start talking about them from the perspective of someone who's unfamiliar with it. And I've already kind of jumped over that. So maybe just taking a step back, if you could talk a little bit - I know at the beginning of your book, you provide a definition from someone about what software testing is. But if you could just talk a little bit about what software testing is, and maybe why it's actually so important?

Nicola: I don't think that this is necessarily the definition verbatim in my book. Software testing is getting information, and then communicating that information about the software and the test. Was there a part two to the question? I'm sorry, I forgot the part two.

Len: Oh no, that's okay. I put two things in one question. Then the second thing is, why is actually - when one sort of defines it or describes it, it can sound very simple. But it's incredibly important, software testing. I was wondering if you could talk a little bit about why it's so important.

Nicola: The weird thing, and I go over this in the book a bit, is that something - the purpose of software testing is different to different people. And this often depends on the project.

I just shared with you my definition or my understanding. And that's largely based on my experiences. More senior people that I've worked with whose opinions I respect - and another very common definition of software testing is, to find bugs. But if you don't find any bugs, then would you say you have not achieved your goal?

It's weird, because some people may think, "Oh, how can you not find bugs?" But I've worked with some very good developers, right? I remember, people were like, "Ooh, we should test this against the requirements, and then limit it to that." Or some sort of working documentation, for example. But then, did you know that developers can also read? So why would they code bugs into it, when they can obviously read that, this is your "to do." This is what the [?] should be." So it's not really enough.

I like to use an analogy when it comes to software testing. And that it is an interview. With software testing, you're trying to uncover information about the software in the test. And then your hope is to get some sort of detection of reality. Or you hope to. You don't want some sort of like, "Surprise motherfucker," when you go live.

With interviews, I think both the companies and the candidates are trying to do the same thing, they're trying to suss each other out, based on the questions that the interviewer asks, and then the questions that the candidate asks at the end or throughout - when they're trying to picture what it may be like to work there.

Or the candidate is trying to figure out, "Okay, is this company trying to pull one over me?" People aren't always honest at interviews, unfortunately. So you ask great questions, and you listen to the answers - and then based on the answers you then ask another follow-up question. And then as time passes, your mental model or your understanding of what the other side is like, is changing. I quite like analogies, and that's probably one of my favorite ones.

Len: I've got to say, I'm also a big fan of analogies. I've interviewed a few people myself, and I've interviewed a few people in software testing for this podcast. And that's the first time I've heard the interview analogy. I've heard martial arts. I've heard crime scene investigation.

Nicola: Oh interesting.

Len: And things like that. And an interview, that is really fascinating. Because it's the - it's so two-way. Which is really compelling, right? Because I think - you mentioned, for some companies, software testing is finding bugs, right? And this is the idea that - for people who aren't familiar with the way these things of things work - it's like, if you've got a product - let's say it's an app or something like that, that's supposed to do something, that people are supposed to sign up for and download to their phone, or something like that.

You sometimes have companies that are just straightforwardly bottom-line focused, I might say. And so they have some computer people who do the computer stuff. And then they've made their product, and then they just want someone to test it, to make sure nothing breaks. And that's one form of software testing, is just make sure it works. And if you're dealing with say a very simple app, that actually might even be all you kind of really need to do, to some extent.

But when you start getting into way more sophisticated products or services and things like that, there's much more of a kind of - there's no idea of anything really being finished. The idea of it being a back and forth between the tester and the product, or the tester and the developers, much like an interview, is really interesting. I really like that you brought up, "People aren't always honest."

Nicola: Unfortunately.

Len: Unfortunately. But I mean, in the context - I'm talking too much. But in the context of software testing, and in so many other things that we do - we know we might've used a shortcut over here in what we did. And we might not necessarily be all that forthcoming.

Nicola: And I think whether or not - you said how you might not always be that forthcoming. I mean, that would also depend - if you're talking from the perspective of a developer - that also depends on the relationship between the tester and the developer, and then how safe people feel to admit their mistakes.

If you feel safe to be like, "Oh I fucked up," then, chances are, people are going to be forthcoming. But if you've seen other people get blamed and called out in public - I have worked in environments earlier on in my career, where people were shouting - not at me, thankfully. I could imagine why people wouldn't be so forthcoming and such, in such a context.

Len: Often people think that, when you're dealing with technical stuff, people themselves kind of become technical. But they usually remain people. And their emotions can get involved. Their pride can get involved. Their fear for their job or their frustrated ambitions can get involved. And sometimes people really do blame other people for their mistakes.

Nicola: Unfortunately I've seen that happen as well myself.

Len: From what I gather, the role of the software tester - as you've already mentioned - can differ from project to project, or company to company. And sometimes you can actually find yourself in a situation where you're the only tester on the project - or maybe even at the company, if it's small. I was wondering if you could talk a little bit about what to do if you find yourself in that situation? Where, let's say - it's like ten developers, and just you as the tester.

Nicola: Firstly, if this is someone's first role or one of their first roles - if they're a junior - I would highly recommend them to get involved in the testing community. Go to meetups, conferences - if they can get budget approval.

The reason for this is that they're not being exposed to other ideas; their understanding of how testing is done could be limited to that project. If someone is further along in their career, I would still urge them to do that. Then at that point - if they've been on other projects at the company, they would presumably already have an understanding of how testing can also be done.

I think it's good to network to bounce ideas - to get some sort of inspiration. You can also - I have been on projects where the developers would like help me test or bounce ideas. So the disadvantage of not having other testers to speak to - in terms of what they think, of this approach. Developers, I find are often also happy to listen and then to make suggestions. So you may ask, "Oh, is there anything I should focus on? Do you have any concerns?" It's not that you will only focus on what they said. But you then make sure to not forget the areas that they have suggested you focus on.

Len: And as a software tester, is it typical for the tester to actually see the code, or to ask a very basic question?

Nicola: Yes.

Len: Or do you often just see the kind of like user interface that someone's going to be interacting with, and just kind of break it?

Nicola: Everything.

Len: Sorry for such a crude question, but -

Nicola: I honestly - I have no idea in terms of what's suitable. Like percentage, of if it's over 50%. I have worked with testers who get quite into the code. So they'll look at the pull request, and see what the changes were, what parts were changed. I've also worked with testers who only look at the UI, and don't even look at like the Chrome dev tool.

Personally, I think it's an advantage, being able to read code and understand what it does. So I would urge people to start looking at that, and ask for access. And some projects, when I didn't initially get access, when I finally gained the confidence - I would ask, "Can I have a look at the repo? It'd be nice to see the pull request for these changes, so I can have a better understanding of what you actually did to make this happen."

Len: Speaking of getting involved in the community, as you recommended for people who are getting into testing, and they're looking to get into their first role - or they're already in their first role. You've founded a couple of meetups yourself, I think? One in New Zealand, and one in Sweden. In your experience, when someone arrives for the first time at their first meetup, what's the question people - is there a question that people typically sort of ask first, that often comes up?

Nicola: It's quite common to ask about roles. A lot of people would go to the meetups with the intention of networking and landing a role. And then - I mean, people can be quite shy. Especially when you are going to meetup, and you're not going with your colleagues. Some, they may just like small talk - and I would try to introduce people to each other. Because I understand it could be intimidating approaching someone. But if - someone who's an organizer who - I don't know how you describe it? I will say it's part of the role, to make people feel comfortable and get the most out of it.

Sometimes people would ask to give talks. So they'd say, "I've got this topic in mind. Are you looking to have a meetup in the next few months? And I could talk about security testing or mobile test automation." And then, you have the conversation about that.

Len: Do talks at meetups often take the form of case studies, where people tell a story about a really tricky bug that they discovered, or -?

Nicola: Often, I would say, people tend to go for stories. There are probably meetups where they do focus on case studies. But the one that I co-founded in Auckland, as well as the one I founded in Stockholm - the format - there's a kind of specific term. It's like this thing where you share experience, you report. So for twenty minutes, you talk about what you've learned, or how you approach a certain problem at work. And then you have something called "open season", where people would facilitate a discussion. So people would ask the speaker questions, and then people would ask each other questions.

It's the facilitator’s role to make sure people don't dominate. So, you hold up color cards as to whether or not you would like to add to the current thread of discussion, or whether or not you'd like to start a new topic. Or if you feel like you're going round in circles, there's a different-colored card that you hold up. And if enough people do that, you're like, "Let's just move on."

I think a really good thing about that, is that it encourages people who don't think that they're experts, to share their ideas or knowledge. Because they are not like, "Ooh, I know so much." They're just saying, "This what I learned. This is how I've done this," right? Things like that [...], oh, what do you think of -? Have you ever thought about this tool?"

I just want to say that people like hearing stories. I really enjoy hearing how other people do things. Whether or not I would have the opportunity to apply what they talked about, is another question. But it's really cool hearing how people approach or tackle different problems.

Len: Thanks very much for sharing that. It's so interesting. The challenge of software testing is so - it's so unique, I guess I would say? Just thinking of specific stories. I've done some ad - nothing more really than sort of ad hoc testing for Leanpub. But I find it an interesting challenge. For example, one time when I was doing some internationalization, I had this problem with Norway. And it was because the country code, "NO," actually was a command in Rails, "NO."

Nicola: Oh.

Len: It took a while to figure out. It's just so weird. It's like, "Everything's right in the code, but nothing's working - what's going on?" And then there was something I had to figure out about basically the language or the setup, to figure out what was going on. And the categories of what strings of characters mean, can become a part of what you're looking into.

Do you have one or two stories that come to mind, for really interesting bugs that you've found?

Nicola: I don't know about - embarrassing is probably the best word; my first project - oh, there's actually two stories.

On my first project, I didn't really know about Chrome dev tools. But even - I mean you can't use Chrome desk tools with Internet Explorer anyway. So we would create profiles. You'd fill out the form, choose like the type of profile you're creating, and you click "Submit," and a confirmation screen would appear. And the weird thing is, sometimes the profiles would be created, and sometimes not.

Back then, I didn't know how to look at the request history, look behind the scenes to make sure that the UI's telling the truth. This is why I think we should be able to look behind the scenes. I trusted the UI. I thought that the UI is truthful.

I remember, I was filling test cases. But you're not necessarily - in that environment, you weren't necessarily writing every single detail of every single field that you filled in. So I remember thinking, like, "What, did I just imagine creating that profile?" But then that sort of thing hit home: intend to do something and not do it.

But it turns out, there was actually an issue. The settings story would be - I was doing the inventory count feature. So I was the only tester in the team. I got my approach reviewed about what I was trying to cover. But we couldn't cope with the number of products. So I think I tested up to like 100 or something like that. But then retailers would have thousands upon thousands of SKUs. So it would just crash, and this was just before stocktake season. So we had to stay up late.

So the good thing, I just want to say - about making mistakes - is that you remember those lessons. Like I don't remember - I mean, I do remember a few - but, like - you're not really going to remember all the things you did well on different projects, right? It's just like a similar day, but when you've fucked up, oy - you're going to make sure that that sort of mistake, or something similar that triggers the like ideas, those sorts of things don't happen again.

Len: This is a very specific question about your career, but have you done video game testing? I think I saw a reference to that somewhere?

Nicola: Yeah.

Len: Maybe on your LinkedIn profile?

Nicola: Yes. I was on a project for like three, four months. I actually don't know if I'm allowed to say which project.

So, there was a QA already on the project, and I was there to support and help mentor them and have them bounce ideas off me. And then set up test information. This was a game built in Unity. I hadn't worked with video games before, and I didn't quite realize that they were a bitch to test.

Because you can't really detect - like normally you couldn't really detect elements on screens [?]. So you can't like tap on buses [?] or whatever. Which I normally - at least for UI testing, I would normally be able to do it in other contexts. But there is a test framework or a tool called an "ALT Synergy Tester." So when I discovered that, I just had to set it up, and cover the regression [?] that way.

Len: It's really interesting, I remember speaking to someone once. "Oh, it much be so exciting doing video game testing." And he's like, "Man, my latest one was a racing game. And my job was just to turn the wheel to the right and scrape up against the wall for like three hours straight, to see if it broke it." Nicola: Right.

Len: But I guess one of the reasons I like to think about video game testing, is that you can see these kind of - really visual examples of it. Like with - I don't know if you know about speedruns and stuff like that in video games, so -?

Nicola: Is that, those are the people who just try to finish a whole game from start to end, and they're just trying to go super-fast?

Len: Yeah. Try and do it super-fast. But I mean, there's the playing it by the rules - but it doesn't take too long before people try and figure out how to break the game to get things done faster. And so if you go to - there's - I forget what the actual URL is, or the web address is. Speedrun is this website, and if you look up speedrun for Zelda: Breath Of The Wild, for example, people who were doing it sort of thought about, "How must the physics be working about when I pull out my shield and try and surf on it on the hill?" And they've figured out that like if you try and like - I don't know? It's something like, if you try to like shoot your arrow while you're trying to surf on the shield - at just the right moment, you can jump way up into the sky. Because it tricks the game mechanic into thinking that it needs to move you this far, or something like that - instead of down the hill, it's up into the sky. Something like that. The latest version, a guy got a hold of a branch, and can fly with it.

And - again, the reason I bring that up is because - if you think people are spending all day long trying to break video games, just think about payment systems and banks, and stuff like that.

Nicola: I mean, they're trying to exploit it - yeah.

Len: Yeah. And it won't be visual in the same way, like using a joystick or something like that. But people are always trying to break things like that. Have you ever worked on projects like that, like with banks or insurance systems - or anything like that?

Nicola: I've worked with payments. The customer of the clients were banks. They handled EFTPOS. Is that a term that you're familiar with? I'm not sure if it's a New Zealand thing or not?

Len: What's the term?

Nicola: EFTPOS.

Len: How do you spell that?

Nicola: E-F-T-P-O-S.

Len: No I'm not familiar.

Nicola: Card transactions.

Len: Okay.

Nicola: Or credit card transactions. So they handle like 75% of these type of transactions. And New Zealand is pretty digital. So they were doing an upgrade, because the current system was no longer going to be supported. And they would work - I found out this is normal, they have very old systems. Or at least they did back in like 2013. So it's like - you have this blue screen, and you just like - only use your keyboard and type shit to test it. I barely can remember. And then we were told the importance of that. Because when it comes to money - if people can find ways to exploit it, they will try. They definitely will try.

Len: Yeah, I'm just looking it up here. I'll put a link to the EFTPOS payment processing system in the transcript for this interview. But I guess it is something that I should've heard about before.

*It is interesting, just how serious it can be, that when you're testing, you're trying to figure out what the bad guys are going to try and do yourself. You're not just looking for bugs, but looking for ways to exploit.

Nicola: Yeah.

Len: Just moving on to the book, Starting Your Software Testing Career, what was the inspiration for this book? What moment did you find yourself thinking, "Oh I'm going to write a book?"

Nicola: Last November, so November 2020 - I think I come across some developers' books, where they say how to become a developer. There's a few of those, right? There's actually a decent number of those. And I was like, "Oh, none exist for testing."

So I started writing the book on Google Docs on my phone. Because I thought to myself, I wasn't like committed to writing a book. I was thinking to myself, "This might be a series of blog posts?"

I wanted to have this one-stop-shop for people who are starting their career, and how to go about finding a role, how you can do testing, good things to keep in mind, different contexts.

I remember also making sure that - I wanted to interview other people. Because I know for a fact, I don't know everything about what I wanted to talk about. There were certain areas that I thought would be beneficial for the reader.

For example, I got a story on someone being a sponsor. I have been sponsored, but I don't think I have sponsored someone. Also recruiting. I have some experience reviewing CVs and interviewing candidates. But I know people who have a lot more experience in it than me. So I'd approach them and ask, "What do you think?" I also interviewed developers and product analysts and business analysts, so they can get that perspective. So it's more a research project than anything.

When I had that outline written, and I was like, "Okay this is going to be a book." I thought, "Okay, let's do it on Leanpub." I didn't announce it straightaway. Because I still wasn't sure that it would go live. I mean, I could've just written the book in Leanpub and then copy and pasted it and made up a blog post. But I thought - I think it'd be nice to just have one, hopefully useful, resource for people either starting up their careers, or early on. It is beneficial for people for people who are a bit more senior, so intermediate.

But that's not really my target audience. When I was writing the book, my thoughts were, "What will benefit people new in testing?" And then it's just like a side effect if it happens to benefit others. It's easier to get my book focused - or at least for me, than to try and make everyone happy.

Len: Yes, it's really interesting. That's a very good point, that there are tons of books out there for like, "Get started in your career as a developer", software developer or software engineer or programmer, and stuff like that. But, yeah - for software testing, there just isn't the same volume of guides out there. And of course, for a lot of people, when you've sort of made it to some extent in a career, and you're a few years in or a decade in or something like that -

I mean, one of the things I think, well, everybody thinks about is, "Man, I really wish I'd known A, B, and C when I was starting out." And so when people take the time away from their work, to actually communicate that to people, it can be life-changing for people, right? To actually know that from the beginning.

Is there like one or two things that you can think about, that really come to the top of your mind, when you think about, "Oh I really wish I'd known this when I was -" Maybe not your first job, but, "When I was in my first year," or something like that?

Nicola: I think knowing your self-worth. I think a mentor is good for that. They have broader perspectives of what the testing industry is like. If you're in your first project, you're in your first year - you might not realize what you have to offer. So I think having someone who can - I mean, at least for me - when I had a mentor from about nine months after I started or a year. Maybe two? It was really nice having someone to - like when I became unhappy in my role, and I was like, "Well, what's the point in applying for the role? Who else would have me?" So it was nice to have a mentor in that regard.

I'm trying to think of something else. Oh, I think knowing how - it's a controversial opinion for a lot of testers. But learning how to write test automation? I'd put it on a pedestal.

So I started learning it at about three - after three years, or two years. And I remember, like - oh my God, it's so hard. And I'm not saying it's easy. But I really hyped it up to be more than it is. The reason I think it would've been useful to learn earlier on, is that - if you know how to do it, and you understand the benefits of test automation?, then you know when to apply it, right?

If you don't know anything about test automation?, then you'll never have the option. So it's not necessarily a case of - just because you can, you should. But more - oh, okay - you're on a new project, should I - would this project benefit from test automation? And then - more importantly - these days, it seems to be a very popular skill, or in-demand skill.

The problem with manual - I want to say "manual testing," but some people don't like that term. The problem with that - is that there is massive misconception of that, anyone can do it. And technically anyone can do it. Can they do it well? Well that's [an open question] [?]. But if you're looking for a role and you can't look at the code, you are doing something that people believe can be done by anyone in the team, or like anyone off the street. Why would they hire you? It's like, "What do you have to offer?" Some people can get roles with only manual testing experience. But when I look - when I'm on LinkedIn and I have a wee mosey, I notice that that's becoming more and more in demand. So it's like - for job security, I do feel that it's good to learn.

In my book, I talk a bit about what to learn. Because it's like, "Ooh, I should learn test automation, right? But there's a bunch of free work, there's a bunch of languages. So I suggest three different frameworks, to get you started. So you don't have paralysis. Because I've come across people who are like, "I want to get into IT. I want to test -" And they're just like talk, talk, talk, talk, right? They don't do anything. So the idea of like simplifying the decision, or at least narrowing down the options - that's what I wish I got into sooner. Or at least took off the pedestal.

Len: And when it comes to walking the walk, instead of just talking the talk - when you're looking to switch into a career, into software testing - in addition to going to meetups and stuff like that - does that include things like taking courses, so you can put that on your LinkedIn profile or your CV and stuff like that?

Nicola: Yeah.

Len: And show that you've taken the initiative. Like, you've never had a job in software testing and done test automation, but you've taken this course.

Nicola: Yes. One of the people I interviewed - Gabbi Trotter, she's a recruiter. And she said how appealing it is. Because someone's actually done something about it. And they showed that they're passionate about finding their careers.

Another thing would be a horizontal shift. I interviewed someone who, they - I wouldn't say "hired people." But people joined their test team through a horizontal shift. So they were in the support team. And I've actually been on a few like that. Because the thing is, if you're already in a company that has software testers - if you're at the company, let's just assume that they trust you, right? So then it's a matter of learning the skills. And it's like, better the "devil you know" thing. So I would say to people - if that's an option, I think that'd probably be one of your best courses of action, if possible.

Len: Thanks for bringing up the interviews actually. That gives me a good segue into the last part of the interview, where we talk about the like process of writing and self-publishing and stuff like that.

One thing you did that was really interesting, was you did, I think, nearly twenty interviews with people for your book. Which is a lot of work. But managing interviews and stuff is actually like a whole skillset unto itself -

Nicola: Yeah.

Len: When you're doing a research project. How did you do that? Did you schedule all -? I mean, let's just say it was twenty - did you schedule them all in advance? Did you record them and then do full transcripts, things like that?

Nicola: They were, most of them were written interviews -

Len: Okay.

Nicola: That I would email them the questions. And say, if you want clarification on something. Sometimes people would go on a little bit too much, and I only wanted say one hundred words or something. So I would edit it, so it was more concise, and check that, "Do you feel that how I've rephrased this still represents what you wanted to communicate?"

I'm a little bit analog. So I'd have a notebook where I was writing down - like for this chapter, it to be this person. See if I can interview that person for another chapter.

Yeah, it was a massive project. But as I said earlier on in our conversation - I know for a fact that I can't offer valuable intel on everything that I wanted to cover. So I had to make -

Ooh actually, sorry - one thing also was crowdsource testing. That's another way that people can get started. But I have no experience. I know some companies that do it. But I have no experience. So I interviewed a few people who've done that. And it wasn't necessarily a case - it's not just like, "land your first role." But one that's a bit, it gives you experience. It's a way to upskill. And, again - you've taken the initiative to do something about your desire to upskill, not just like talk and talk.

Len: And for people interested in crowdsource testing, I recommend - get the book. You'll find out a lot about it, and it's a really interesting idea.

This is sort of a very specific writer-ly question. But how did you know when you were done?

Nicola: I'm not actually done yet. I still have two chapters I want to write.

Len: Oh, okay.

Nicola: But in terms of done enough to release it, or charge money for it - I wanted an MVP. Something that was complete on its own.

And I asked for feedback from the reviewers. I had to find a cover, this is what's going to come up next. And I got some good feedback on that. I'm thinking about setting a date. So I have the outlines of the next two chapters, and expanded the bullet points - but at the moment, I'm still waiting for - I don't know how to describe it. That's why I like efficient communication. I'm waiting for things to settle in my mind. So I'm coming back to that like every second day, and then expanding it and coming back to it. But yeah, that's the plan. Two more chapters, and then done.

Len: That's really interesting. One thing that people often do when they release a minimum viable product book, and then they plan to add chapters, is they'll actually start out at a lower price, and then raise the price as time goes on and they add content. Is that something you're planning on doing?

Nicola: I am planning to raise the price with new chapters. I actually have done that. I had a pre-sell on Gumroad. That was one price. And then I started raising it. Because I want to thank the people who've had faith in me. Especially for the people who bought the pre-sale book. But I want to thank the people who had faith in me, by charging a lower price.

Len: Thank you very much for putting it that way. The way I put it sounded quite mercenary. But actually the way people think about it, is like, "I'm going to raise the price on people as I add more content." But actually the way everybody does this thinks about it, is actually exactly the way you put it. Which is, "Thank you so much for buying my book early on." It's why you actually put a lower price than you think the book will have eventually, when it's complete. It's like you're actually lowering the price, it's not that you're raising it, is probably a better way of understanding it. And rewarding people and thanking them for coming on board on your project, even before it's finished yet - and when there's still work to be done.

My last question that I always ask people, if they're an author on Leanpub, if they're a guest on the podcast, is - if there was one feature as an author that we could build for you, or if there was one terribly annoying bug or problem that we could fix for you - is there anything you can think of that you would ask us to do?

Nicola: Probably on mobile. I discovered that you can't write on mobile. So I'm copy/pasting from Word docs. The reason for that is, I'm currently on parental leave, and I've been writing the book at night after my children have fallen asleep. And often my two month old is in my arms, so I have to do it on the phone. So I guess that would be - I would've appreciated that. Word docs is a bit of a workaround.

Len: Oh that's really interesting. Because we do have the "write in your browser" thing, but I'm gathering that's probably not remotely optimal for anything, unless you maybe have a huge tablet or something like that?

Nicola: Yeah. Because I tried in Safari, and I guess it's a bit weird to be - I think I've written - not just on my mobile and copy/pasted from Google docs. I'd be hunched over my son on my laptop, typing away. And, yes it's the - I guess it's not the normal way to go about it. But at the end of the day, I wanted to use the time that I had - and I didn't really want to try and do it when my children are awake. So it's all about the hunch posture.

Len: Thanks very much for sharing that. Those kinds of details are really important for us to learn about how people are doing their job - it's actually really hard to get people to share that level of detail of what they're going through, and how they're trying to do things. Writing on mobile actually is quite popular for certain kinds of fiction. Like for example, Wattpad. I don't know if you've heard of them, but they're really popular. Where it's like - people just like tap out a chapter on their phone when they're on the bus - or something like that, for their serial fiction novel about vampire werewolves, or whatever it is.

And that's actually, like - writing on mobile actually is something that's quite popular in some circles, and something that we should definitely try and accommodate better.

Well, Nicola, thank you very much for taking the time to be on the podcast, and for using Leanpub as a platform for your book. We really appreciate it.

Nicola: Thank you for having me.

Len: Thanks.

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.