Daniel Knott, Author of Hands-On Mobile App Testing

Len: Hi I’m Len Epp from Leanpub, and in this episode of the Frontmatter podcast I’ll be interviewing Daniel Knott.

Based in the greater Hamburg area, Daniel is a software test engineer and a popular conference speaker. Currently he’s Head of Software Testing at MaibornWolff, a strategic IT consultancy based in Munich.

You can follow him on Twitter @dnlkntt and check out his website at adventuresinqa.com, as well as his Software Testing YouTube channel at youtube.com/c/DanielKnott.

Daniel is the author of the Leanpub books, Smartwatch App Testing, and Hands-On Mobile App Testing: A Guide For Software Testers And Anyone Involved In The Mobile App Business.

In the book, Daniel covers what makes mobile testing different, the special challenges it presents, and introduces you to advanced mobile testing methods and tools, and much more.

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

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

Daniel: Hi Len, thank you for having me today.

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?

Daniel: Sure, let me start. I grew up in the middle of Germany, basically in the middle of nowhere on a small farm with my parents and my sisters.

It was a great time, because back then I already was a little explorer, trying to dismantle on and demount all kinds of technical issues and topics. That was great and fun. I also grew up with lots of animals, so I was kind of grounded back then.

But then, out of nowhere, I don’t know when, it happened when I was a teenager - I had the first magazine of computers in a store, and I was pretty much hooked with like, “Okay, I want to be in computers and Computer Science. I would like to learn everything about computers.”

I started to build up my own computer. I can’t remember when it was. It was somewhere in the 90s, so that was great fun. I learned many things also by mistake, breaking things, and it was kind of expensive.

And then in university, I had my first contact with software testing. It was in 2006, when I was working as a working student at IBM in Germany, and they had basically no idea what to do with me. So, they put me into software testing back then and said, “Hey, here’s a piece of software. Can you test it?” And I was like, “Yeah, okay. Sounds interesting, what can go wrong?”

It was not really professional testing back then. I was just clicking around hoping to find some bugs, and to file some issues so that my colleagues would be happy with it.

At the same time, I had a great professor at university, and he was into software testing. He gave me some insights into what kind of books I should read, and gave me some ideas on what professional software testing means.

Basically from then I was pretty much hooked about software testing, because I wasn’t a coding guy. There were people in the university who loved to write code - coding, coding, coding was their passion. For me it was like, “No. It’s interesting, but there’s more to explore, and more to uncover.”

So I said to myself, “Okay, well you want to go into software testing. I would to become a software tester in my career.” And, yeah - so I finished university. I think it was in 2009. Then I got my first job in 2010 as a software test engineer in the company. Yeah, I was basically in heaven - finding like-minded people, exchanging on the topic - and yeah, became a professional software tester. It was great.

Len: I’ve got a couple of questions about the earlier part of the story, before we get onto your career.

So, you were building this computer in the 90s. Was that something that your parents introduced you to? You said you found out about it from a magazine, and stuff like that. Was it more independent, and you’re just asking your parents to help you out financing the project, or -?

Daniel: Both. I found it out on my own, basically, when I was just reading the articles and the papers then. But of course I was in school, right? I mean, I had no money, basically. I had some pocket money left, and I was doing some summer internships to get some money. I was saving all my income - that’s for birthday presents and these kind of things - to actually buy computer parts.

But of course my parents supported m,e and they also paid the biggest portion of the first computer. I think it was in 1994, 1995, something like that? They already had seen that, hey, this might be something for the future, and that was great actually.

Then my friends, they also got started with it. We played some games together, and we learned more about how to configure them, how to extend them, and these kinds of things.

Len: Did you have the internet available?

Daniel: The first time the internet was available was 1996, if I remember correctly. So, yeah, some time ago.

Len: The reason I ask is always just, there’s these different eras, when people are introduced to computing. It’s just so fascinating to think about the tools you didn’t have available to sort of figure things out, right? No Stack Overflow, that kind of thing.

Daniel: No, nothing. Nothing.

Len: actually, just one kind of almost selfish question. I grew up in a sort of agricultural area in the middle of Canada. I just wanted to ask you some - this was the kind of place where I remember one time, actually we had - at my high school there was a foreign student for a year from somewhere in Germany, and the family took him from one city to another. This was in a province called Saskatchewan. Of course, they were outside the city within five minutes, and this is a very flat plain. The joke being your dog can’t run away, because you can see him for three days.

After about twenty minutes, having not passed another house, this German student said, “When’s the next city?” they said, “Well, in 200km.” In this place, farms are like - this is a bit of a caricature, but a kind of square mile, and there’s just a picket fence. Or not a picket fence, a post and barbed wire fence - and that’s a farm. It’s mostly wheat and canola and things that that people grow. What did you grow on your farm?

Daniel: It was a little tiny farm my grandpa had. What did we have? We had some cows, we had some pigs, we had horses. It was more something to - to get everything on your own, to be on your own with food and vegetables and these kind of things. It was a rather small farm. Nothing big, nothing fancy. We were not selling anything.

Len: Oh, okay.

Daniel: It was just for our own, yeah.

Len: I got it. That’s just so interesting. Actually you mentioned something too, about being a working student at IBM. What does that mean?

Daniel: I started university in, when was it? 2000. It’s a long time ago. It doesn’t matter.

I was studying Computer Science, and I had the chance to be a working student, to work in parallel to my university studies, at IBM, to earn some money. I had the luck to have some local connections there.

They invited me for an interview. I wasn’t really advanced in Computer Science. I mean, I had all this knowledge of assembling computers and these kind of things. But then they asked me, like, “Sure, we’ll give you a chance. You seem like a nice guy.” I had the time there to actually start with software testing. I did it during my whole time at university, yeah - working in parallel.

Len: And so this introduction to software testing, was - they kind of didn’t know what to do with you, and they sort of -

Daniel: Exactly.

Len: Threw you at something where you couldn’t write code that would break something for the customers, or something like that.

Daniel: Yeah, exactly.

Len: So you were just thrown in to, sort of, clicking around. What was that like? It’s just so curious because software testing is a very interesting job, because, for example, there can often be adversarial - not exactly relationships, but dynamics involved. It could be, for example, that some young person on the first day of their job discovers a flaw just by clicking around, that someone senior might have to answer for. Was that a dynamic that you had to find your way through, in those early days?

Daniel: No, not really, I would say. It was a storage software that we had developed. So, for mainframe systems, I mean, IBM, right? It was a storage management system that we had to test, and they gave me some time to explore the product, to do some exploratory testing.

What’s really common these days - because I had no idea - there were no requirements for me, what I should look for. So I was really signing up on the staging system, I had an account and was just browsing and exploring it. I had no idea about the product at all, right?

So I was asking lots of questions. At some point, some of the seniors, they got a bit disappointed by all the questions that I was asking. But exactly that is the right thing as a software tester to do, right? To ask questions. Even though sometimes, you feel not welcome.

But that’s part of the game, right? To ask the difficult questions and to get the thinking starting on the development side, right? So they think about, “Why did we do it? Is it the right way we have done it?” And so forth and so forth.

But I was in a lucky position, because the people there were really nice and kind, and open-minded. They also supported me in, “Okay, this is a test tool that we were using to -“ I can’t remember the test tool back then. There was a testing tool, a test management system where we were filing bugs. We had some test automation in place already for the tools. So I had a look into the code as well. We also did a lot of pair programming together, PR testing. So there were a lot of right things that I have done, of course. They taught me, but they didn’t tell me, “That’s how it should be,” right? Everything was a bit mixed up.

Len: That’s so interesting actually, that you mentioned there that you hadn’t been taught, and you just kind of - it sounds like being given the freedom to explore, you kind of found your way to doing the right things naturally.

But one thing that I think you’ve talked about somewhere in a blog post or in a talk, is that you studied Computer Science. Software testing is not really taught, generally speaking, in Computer Science. Or at the very least wasn’t back then.

Daniel: No.

Len: That reminds me of a great metaphor that someone I interviewed for the podcast once, who had a hand in developing Computer Science curricula in the United States. He said that version control becoming kind of popular in the last, I don’t know, let’s say 15 years, or something that, was a sign of how young Computer Science was. It was like surgeons learning to wash their hands. You can imagine when that happened, there would be all kinds of people like, “Pff! I’m a real surgeon. I don’t need to wash my hands.”

I’ve interviewed quite a few people who are into software testing for the podcast, and it’s often struck me that there’s - we’re not at the washing stage yet actually. I’m saying “we” in the sort of cheesy way. But if we’re not at the stage where we’re actually giving people a software testing class in Computer Science courses, maybe we’re actually not at the washing hands stage yet.

Daniel: Yeah. That’s a great metaphor. I mean, it was similar in my case. I think there was only one. In one semester at university, we had a Software Engineering class, it was called. It was a bigger project that we had to do as students, to develop this piece of software. There were one or two lectures that covered software testing back then. But that’s it, right? It was the testing pyramid - writing unit testing, integration testing - and so forth and so forth.

But that’s it, right? What the developers learned about software testing in university, I think that’s critical, right? I mean, looking at the industry these days, and also on the complexity of systems that we develop and that we are using on a daily basis - it’s not just a website or an app that we are using. It’s so many, many systems that are running in the background, and that needs to be configured. Developers have the quality mindset already in place, because otherwise they would completely screw up in the end. So that’s definitely a problem I see.

I just talked this week to a university professor, and also asked them, “Hey, what kind of things are you doing for software testing?” It was the same answer. It was like, “Yeah, it’s just the basics.” He told me that they just do not hav enough time. They have to cope in so many things in six semesters or in three, four years - to teach students the fundamental of Computer Science, programming and architectural things. But I would wish to have some more testing there, yeah.

Len: Yeah, I mean, it’s easy for us to sort of just breezily say, “Why don’t you teach more of this?” The obvious answer is, “Well, then we’ll have to teach less of something else.”

Daniel: Exactly.

Len: So at the very least there’s going to be two other guys complaining about their thing that they care about, that we’re not teaching.

Daniel: Yeah, exactly.

Len: But at the same time, to take it seriously - of course there are trade offs. I’ve often wondered if it was just this kind of cultural dynamic, right? I mean cultural in the sort of corporate culture sense. Where there’s people who make stuff, and then you hand it off to people and are like, “See if we made any mistakes,” a kind of attitude towards testing - I think, I forget who it was - but I interviewed someone a long time ago where they didn’t know anything about Computer Science, and they got hired as a software tester. What that meant was, you’ve got a cubicle in a row of cubicles, and you have literally a bunch of pages with checkboxes. They got you to open up a piece of software, and the first one was like, “Click here, click here, click here, click here, click here - record what happened. Click here, click here, click here, click here, click here - record what happened.”

Of course if that’s what you think software testing is, if you’re an ambitious person or you’re a creative person, or what you have you, that’s not something you’re going to want to do, and that’s something that’s going to basically - and we have to take into account the fact that cultures have status in them, right? There’s status according to certain kinds of things and certain others. But the metaphor you used of your first experience of it, as exploring something, particularly in a big company with big established things that they’re doing that are very complex, that idea of exploring and getting to know something that’s already been built, is just a very different way of getting into how complex and interesting software testing can be.

Daniel: Absolutely, correct.

Len: One interesting thing that happened in your career, is that you ended up getting into content creation, right? I think your first way into that was starting your blog.

Daniel: Exactly.

Len: I was wondering if you could talk a little bit about how that happened? There’s probably a few people listening who are like, “I’d to be a content creator.” What was your inspiration to get the confidence to start, and how did you find the time to do that?

Daniel: I just also checked it before on my LinkedIn profile, when I actually started my blog. Because I wasn’t able to remember exactly. It was in October 2011, or November, 2011 - something like that. So more than 10 years now.

It basically happened because I was giving my first talk on a conference. Back then, my company - we had a sponsoring booth at the conference, Agile Testing Days - it’s a pretty common software testing conference in the world, it’s also based in Germany.

Back then we had to - how’s it called? A sponsored speaking slot at the conference, usually the side track, where nobody would to talk, and nobody would to go - because it’s usually a sales pitch from companies.

But I was actually really lucky that my boss back then, she asked me, “Hey Daniel, you just switched over to mobile testing. Don’t you think this might be a really nice topic to talk about at the conference, because it’s so new?” I switched to mobile testing at the end of 2010, and there was literally nothing out there, from a tuning perspective, everything was not really mature enough. I was like, “Okay, what should I talk about?” I was pretty nervous, and, okay - it’s like, “Yeah, let’s do it.” It was a twenty minutes talk.

I was the only mobile testing talk back then on the conference. It was just a small room, and it was crazy crowded. They opened up the doors. People were sitting outside on the hallway. They actually put some speakers outside that people could listen to my talk. I was like, “Oh my God, what’s going to happen here?” Because I was talking about challenges in mobile testing, what I have seen in the past few months when I was working as a mobile tester. I spent two more days at the conference, but I was literally just giving interviews to people, talking to people that would to know more about the topic.

I even got the first request to write a book about it. It’s like, “Okay, wait - that’s too fast.” I’m just in the industry of mobile testing, it was half year or something, I need to learn more about it.

Then I came back home from the conference. I was pretty much hooked, and full of adrenaline somehow. But also in a shock state, I would say. It was like, “What’s going on here? This might be a hot topic for people” back then. So I thought, “Okay, what can I do?” I also got invited to many other conferences to give the same talk again. At the same time, I had the feeling that, “I just need to learn more about it.” But what I have seen and I have felt on the conference, was, “I need to share it with others.”

So that’s why I said, “Okay, let’s create a blog.” I had no idea, I had no ambition, anytime soon, to be an author. I just wanted to use the blog to share my knowledge.

Also, the main purpose for creating it back then, was also to reflect on the things that I have learned, the things that I have made in my daily business as a mobile tester back then. I was trying out so many tools that were on the market back then. I wrote about them. I was like, “Okay, this is not working out because of X, Y, Z. How to integrate into CI/CD.”

All these kind of things, I was just writing down after work, when I was at home. Because I had the feeling that, “It’s useful for others that would to come into that field.”

I was shocked. I got so much great feedback on the blog. It kept me busy, the next few years. I really loved it, because people loved it, like, “Hey, keep on going. That’s so interesting. We learned so many things from it.” So that was my step into content creation.

Again, I would say, it was a coincidence. Because my former boss back then said, “Hey, you have some cool topics that you’re working on right now, so why not give a talk?” It was a little tiny stone that pushed. It’s still rolling.

Len: Speaking of it still rolling, let’s skip ahead to now. What do you do in your current role at MaibornWolff?

Daniel: Yeah, unfortunately I’m not really hands-on mobile testing anymore. I’m Head of Software Testing at MaibornWolff. It’s a key management position. We are testing software for all kinds of clients within Germany at the moment. We’re focusing at the moment on the German-speaking market. The department that I’m heading with another colleague, is - we are 36 people now, with all kinds of backgrounds in software testing. We have technical people. Really test automation engineers, software engineering tests.

We also have really great people that are great in test strategies, test management. Managing big projects, big clients - in terms of testing, in terms of quality ,and handling the people - helping them to grow, help them to learn new things, explore new topics. Then also to help our clients, consult our clients - and to actually advocate for more quality in the products they build.

Len: So I can imagine, so one version of it might be, “We’ve got a product, and we need someone to test it.” But another version might be, “We’ve got a product, and we want to learn how to do testing ourselves.”

Is that part of it as well? So helping to work with them, to come up with the right testing strategy for their -?

Daniel: Exactly, yeah.

Len: I imagine, it’s obviously got to be very different from product to product, or industry to industry, right? For example, in banking or aviation, testing might have very different kind of levels of requirements.

Daniel: Absolutely.

Len: I know you’ve talked about it on your youtube channel, but that leads me to the question of testing certifications. I was wondering if you could just take a few minutes to talk about that? Because I know it, that can be a controversial kind of issue in the software testing world, for all kinds of important reasons.

Daniel: Yes.

Len: People might be a little bit surprised to hear that there could be controversies in software testing world, but there are.

Daniel: Exactly.

Len: So, I was wondering if you could talk a little bit about that, and maybe your position on it as well?

Daniel: Yeah, definitely. I mean, certification, or testing certifications are - I don’t know which words I used in my YouTube video? But it’s a hot topic. It’s like - you can easily start a fight when talking to a person on that topic. Because there are some bad testing certificates on the market, I would say. But on the other side, there’s also some good ones on the market. There are some on the market where you really have to study, for getting to certificate - right? You learn for some weeks on topics someone - you exchange with people on the topic. You learn for the exams, also written exams.

Sometimes there are exams that you just have to learn - either on your own, on a book or on the syllabus - or you go into a class. Then, at the end, you have to do a multiple choice test. You have to really follow the words that are in the exam.

This is like, really - there’s too many boundaries when we talk about software testing. Because software testing is so complex.

So, that’s the controversial part. Some people think that it’s not really knowledge that you gain, it’s just passing an exam. It’s opening up your brain - putting everything in to the exam, and then close it, and never use the knowledge again. This is the bad reputation on software testing certificates.

I have to say - they are useful. Because you might get a first job, right? Especially if you’re, let’s say, a junior software test engineer, and you want to get your first testing job. The certificate might help you to get a job, right? Because you’re already - you tell the company that you have learned something about testing, and that you passed something, right? But still, you have to grow on the fundamentals that you have learned in the certificates. That’s important.

Or, if you’re a freelance software tester, for example, and you want to get to the next project, that’s also helpful, because, as you mentioned, some industries, they completely rely on these kind of certificates. Being in banking, for example - they really want to have people that are certified. Because it might be part of their own certification process, or their own audit system, that they have in place. They have to assure that all the people that work for them have at least this and that certificate, right? So for them, it’s a safety net. That’s why it’s also important maybe to have it - yeah.

On the other side, I also know a really great software community - they have no single certificate, but they are really awesome and great. So that’s the thing, right?

It’s always - you have to find a balance. Do you really need it for your job? Or do you just want to have it, and to have it somewhere in your CV that you have this kind of testing certificate?

What do I have? I have two or three of them. But I don’t need them in my current role, right? I have them, and that’s almost ten, twelve years ago,that I got them.

Len: Thanks very much for that really great nuanced answer. I think it’s important, often when we look at these things, to understand that there’s people looking at this from all kinds of different perspectives, and different interests.

If you’re, say, not in a technical role, but you’re in a kind of managerial role, and something goes wrong, people ask you, “Well, who did you have working on that?” You can say, “Well, I followed the guidelines, and I only hired people who have these certifications, at least.”

There actually can be very good reasons to have mechanisms that in place, especially if people are at a certain level, in very hierarchical organizations. At a certain level, there’s zero domain expertise.

Daniel: Yeah, exactly.

Len: The person who’s responsible at a certain level of abstraction - so, these kinds of things can be very important, and play an important role.

But of course, that means you need to be aware of why it exists, for procedural and bureaucratic reasons.

It doesn’t really mean anything in itself. But you still have to do it sometimes.

Daniel: Yeah, exactly. Or if you have recuriters, for example, or an HR department. If they filter for applicants and they don’t have the checklist or certificates - yeah. So that might be also the first step to pass that barrier.

Len: That’s interesting, that actually reminds me of something you said there, which is - sometimes when you take the not-so-good certifications, you learn the arbitrary words they alighted upon in their exam creationm, and then you just learn to spot the pattern of words in the multiple choice options given to you. But at another level, communication actually is a really, really important skill when it comes to words.

Daniel: Oh yeah.

Len: Even being able to recognize those word patterns, actually is an important skill, right? Because when you - I imagine when you are working on a new code base, you have to learn the internal language that developed around that code base that the programmers have. But then you have to learn the business side of things, the words that they have too, right? In order to report to them what the problems are, and what caused them. So you have to learn these different languages.

Daniel: Yeah. I mean that’s one of the keys software testers should have, right? Is this communication and inter-personality skills. To be able to talk with developers in a different language than talking with the product manager, or with the designer, or with external stakeholder - or with the customers, for example.

I think it’s a really challenging part of the software tester. It’s really, really important to have these communication skills.

Len: I think I spoke to someone once who sort of, somewhat tongue in cheek, was like, “When you’re speaking to the people responsible for the business side, you always speak in terms of revenue, and “This will save you this much money,” or, “This will make you this much money.” Then, when you’re talking maybe to the programmers, it’ll be like, “This will save you this much time.”

Daniel: Yeah, absolutely.

Len: Just to ask a cheesy question - I imagine being in software testing yourself, you probably get versions of this from time to time at the pub, or when you’re introduced to a new in-law, or something like that, which is - every once in a while, you hear about these giant initiatives that just completely fail. Healthcare.gov - that’s becoming a bit of a dated reference, but that was a big deal in the United States a while ago - with huge political implications for it.

We’ve got [one long-running thing in Canada right now]*(https://www.globalgovernmentforum.com/union-chief-demands-inquiry-into-canadas-phoenix-pay-scandal-aec-launches-disinformation-register-policy-delivery-news-in-brief), about something that sounds simple, which was a payment system for federal government employees. It’s just a giant steaming pile of poo, and it has been for a long time, with incredible amounts of money spent on it, and it still doesn’t work. Even to the point of people not getting paid. So - if someone asked you, “Oh hey, you’re in software testing. How is it that people can spend literally a billion dollars on a software system, and then it just doesn’t work. How can that happen?”

Daniel: Right, it’s actually a tough question. I mean, it’s not that easy, right?

When software testers usually come in place - or in many cases, sometimes it’s too late, especially in these projects, really big governmental projects. It takes years for them to design something, and to write their books and their requirements. That’s not the way that it should be, right? They should involve software testers, developers, designers as early as possible - in an agile way.

To be in the discovery phase, in an early process. To gather the insights and ask also the customers, “what is the problem that we should solve?” This is not going to happen on these big projects. Software testers just come to late to that stage, where they should work and they should find the topics.

That’s what I say is usually the biggest problem. Also that the bigger projects get - you have to make a public offer, a public request for the project. So many, many companies, they can come together to work with it, and to complete the product.

Then sometimes it’s provider A, provider C and D and E - and they don’t know each other, but they have to work together. So they are not having the same development standards. They don’t work in the same language. They may be working in different time zones. All those implications, this ends up in such a huge mess.

In the end, it comes down to people and to communication. Also, of course, to misplanning of the project. I mean, it’s just too big. You cannot foresee all the different edge cases that might occur on such a big thing.

But of course you have to start at some point. Bring people together as early as possible, I would say. They will do something great.

But usually also with politics and all these things, it might be the wrong people who get assigned to the topic as well. Also, from a higher management position.

We have the same situations in Germany. You have all kinds of projects that completely failed on such a big level in the same way. Developing software for years, building product for years that nobody will use, or in the end, it will be rejected by the EU, for example, because it doesn’t comply to the laws and stuff.

Len: We could probably talk for a long time about regulation as well -

Daniel: Yeah, yes.

Len: How crucial, and sometimes arbitrary regulation and changes in regulation can be, and how those can impact the way you have to design and implement things.

Just one last question I have about this, before we go on to talk about your book. But the idea of people coming together, to work together - who might come from different perspectives, and have different skill sets - they might also have different perceptions of their own and each others’ skill sets as well.

You’ve developed this tool, called the testing wheel to help manage that. I was wondering if you could talk a little bit about what inspired that idea, and how that works?

Daniel: I basically copied the testing wheel from the product wheel, which was created by Petra Wille. She’s a German product expert, also in the Greater Hamburg region.

I read her book, called Strong Product People. There, she wrote about how basically to develop people under a certain scale of things, the idea of, “Okay, this is a really nice and easy framework that you can use, in order to talk about different topics with your direct reports,” for example. Or with your own manager.

So I derived the testing wheel. I think it has eight categories with agile working, test automation or testing in general, communication skills, growth plans, and so forth.

What I do with the testing wheel is, I explain each category to my current reports. I tell them, “Okay, these are the categories that we have in the company.” Then they should rank themselves. How do they see themselves on the testing wheel, for example, in the technical testing part? Do they think they are really on the outer end? So, “Everything’s perfect, I know everything.” Or do they see themselves at the very center of the wheel? So, if they need to get more help and more guidance. They do it on their own, for themselves, and I do it for them, how I see them. Then we put the testing wheel together.

Then we see, okay, they are “technical testing skills.” One colleague says, “Okay, he knows everything.” I say, “Okay, he’s in the middle of the range,” right? There’s a gap, so we should talk about it. Why he thinks, or she thinks she is perfect, and I think there’s room for improvement.

I don’t use it to judge people, and to rank them in some hierarchy or next salary increase or something. I use it as a personal growth framework, to actually help the people and show them, “Look, that’s what you think, and that’s what I think.”

It’s easily also extended with others in the team, for example. Someone to fill in the testing wheel or the wheel itself, for him or her, to just get some feedback.

That’s the main purpose for me to bring the people together. To talk about their perception of their work, and how they see themselves, and where do they see room for improvement? That’s really it. It’s there’s so many great discussions going and stuff. And, yeah, that’s cool.

Len: That struck me as a really great idea. There is a bit of a bracing element to it as well. As friendly as it can be in the end, evaluating yourself and others, is an important exercise to go through for teamwork. To step back, and go like, “We’re all doing jobs here, and it is important for us to be objective about ourselves and each other from time to time. Even if we might not always like what we hear.”

Daniel: Of course, no.

Len: So, moving onto the next part of the interview, where we talk about your book. We’ll talk aboutHands-On Mobile App Testing, about how it’s actually, in a sense, a second edition. I’m really interested in talking about that story.

But I want to say, this is a really, really good book for anyone interested in this subject. It’s grounded in history, which I found fascinating. You have this section near the beginning where you talk about the history of basically mobile telephony, which starts in the 70s, at least along one timeline. There’s always ways of teasing it earlier with any technology.

I was wondering if you could talk a little bit about that? How did we get from the first sort of, I guess, huge, they weren’t even bricks, they would’ve been blocks or something that, that might’ve been in trucks, or something that, to where we are with 5G today?

Daniel: I mean, it’s almost 60 years ago. I imagine back then, I think the first one, they were mounted, as you said, to trucks. They were only able to pick up the phone, and just talk one direction. It was not bi-directional, so it was only one-way communicating, through it. That was amazing.

Then of course, there were companies, I can’t remember all of the companies that were back then, involved in the development of the networks and the establishment of the first 1G network. Basically, where you were able to have the first phone call in both directions. But still, it was mounted to big trucks, and to big stations. It wasn’t really mobile back then.

I think the biggest milestone that happened was 2G. Or later on the GPRS technology, when we move into the 80s, where we had the very first phones that were, I don’t know how tall they were, really big ones. The battery was not really lasting for an hour something. When people were using them, it was maybe in upper management? Or, I don’t know, companies where a busy manager is using the phones back then. We all know the Hollywood movies where you can see, I think it was Motorola? I’m not good at history. I think it was the Motorola phone back then, what you have seen on television.

Then of course, the industry was evolving. The market was there. People have seen the benefits of using mobile phones.

Then it evolved from the 2G networks over to 3G, where you have really a fast internet. Then, I think also the big accelerator back then, was, it was basically the first iPhone in 2007. Before that, what did we have? We had Nokias, we had Samsung, Ericsson. All the Blackberry devices, with physical keyboards, small screens, really bad resolution. You were not able to extend the device with apps. You had some browser capabilities, I would say. You were able to get some information from some websites.

At the same time, the internet was just growing. It was a parallel growth basically. Then, in 2007, when Apple introduced the first iPhone, I think that was the revolution. I still remember the interview - it was Steve [Ballmer] from Microsoft saying how this will never be a success. Where he was laughing, and like, this was also part of - when I talked at a conference to a guy, talking about mobile testing, where he totally underestimated mobile testing. Like, “Oh, it’s often just a small thing.”

Then one or two years later, he also gave a big talk about mobile testing. So what I have written in the book is, “Never underestimate a technology,” right? It might look really small and tiny, but it can be the next big thing.

Of course there might be some failures in between. We had this already. But mobile is here to stay, I would say.

Then, of course, after Apple introduced the iPhone, then we had the first Android phone coming up. Then, we know where we are at the moment. We have the different mobile networks that had to be developed, because of the data speeds, and the use cases that we have. Now we have 5G, we can stream music, videos, have video conference calls everywhere, wherever we want to have the conversation.

Len: Thanks very much for sharing that great very high-level history. One thing you captured there was how, back in the day, having a mobile phone meant you were an important person. This is something that I think, we’ve dated ourselves already, but kids these days might not know that in the olden times, that meant - it wasn’t even a status symbol, it was a sign that you were doing something important and time-sensitive, that required this special technology.

Then, of course, miniaturization became a feature. When phones became more commonplace, then the smaller the phone, the more important a person you were somehow. There was a great Saturday Night Live sketch with Will Ferrell, I think where, he was playing a important fashion designer or something. He had this little phone, it was the size of a fingernail or something that. But it is interesting, because the revolution that the iPhone represented, right, where the whole face of it, I think that for the first one, the whole face was already a screen. It was touch - no, there would’ve been a button at the bottom.

Daniel: The button, yeah.

Len: But most of the face was a screen. Then, actually, you wanted phones to be bigger. You didn’t want them to be as small as you could possibly make them.

But basically, what a lot of people would’ve missed, is that, well, this is not just a phone anymore, A. nd B, there’s a lot more to it than it just being a desktop computer in your pocket.

Just to hone in on that last part, because you write about this very well, that mobile phones are - it’s not just a computer that can talk to other computers, or something like that. There are all these sensors and ways of interacting with them, that are very different from any other computing device that you’re going to use.

Which brings all these fascinating challenges. Because all the testing we’ve been talking about so far, is with the keyboard in front of the screen, basically. But now you’ve got something that’s got a sensor on the inside, let’s say with a watch that’s looking at your heartrate. Then that might be associated with data coming in from a magnet that’s in the phone, that’s sensing what direction you’re facing. Then that might have a, What is it? Something in it, a gyroscope that can tell whether you’re going up and down, and how much you’re going up and down. And then that might be communicating with a satellite to tell you what mountain you’re snowboarding down, in a snowboarding app. Like, how do you test that? Well, you have to go snowboarding.

Daniel: Absolutely, definitely, yeah. That’s also a big part of the book, telling the readers that they have to test the app where the customers will use it in the end.

Depending on the app use case, you have to go outside on a mountain, for example, if you would to test the features for a snowboarder. Testing it in a cozy office in a strong Wi-Fi network with, I don’t know? 22 degrees in the office. It’s a nice, cozy environment, but you mentioned being outside on a mountain, wearing big clothes and everything. You have goggles on. You cannot really see what’s going to happen on the screen. You have maybe cold fingers, or you have special gloves for touching on the screen. This all adds to the result of the product in the end. This is something that you have to see in real life, that you have to test in real life, and also the real environment.

I was speaking of data networks, maybe on top of the mountain, all good, you have 5G network. But going down into valley, you might have no internet at all. What’s going to happen with the app in that situation? Is data being sent, and so forth and so forth. These are so many scenarios that you have to find out when working in mobile testing and for your app, to write them down, and to make them transparent also within the team. So that everybody knows, “Okay, that’s what we’re to building for.” The products, the company or the customers. Then you can build something good.

Len: What are some of the high-level strategies that you talk about in the book? I guess you could take a few minutes to talk about those that are unique to mobile testing?

Daniel: I have one chapter talking about basically the challenges of mobile testing. One of the biggest challenges that you have is of course the different devices. Device fragmentation is a big topic still. It was a huge topic on Android back then, and it’s still a huge topic on Android, where you have 20-30,000 of different hardware/software configurations available on the market.

Back then the iOS developers were always laughing, “Ha ha, we have only one device with one operating system version, and everything works.” But also device fragmentation is now a topic on iOS.

I think it’s a good thing that we have device fragmentation on iOS because, Apple is really giving support for all their devices in terms of software updates, in terms of security. That’s good for the developers and for testers, it adds more complexity to it, because you have to support all the devices. Slower phones, slower hardware, and so forth. That’s one of the biggest challenges that you have to tackle in your testing strategy for mobile apps.

I read so many blog posts about it that you should gather information about your customers. Know who is using your app in the end. If you know that, you can see what devices are they using. If you know that they have only on Android, let’s say two, three manufacturers, focus on those manufacturers and OS versions that they use. Same on iOS, to narrow down the complexity of the devices, because nobody can test on thousands of different devices on each cycle of an app release. It’s also way too expensive to handle all those things. So that’s one thing that I usually tell them.

Then also, talking about mobile test strategy, is then what we just had as the example before. Make everyone clear what we are building for. What’s their purpose, what problem will the app solve. Is it a sports activity app? Is it a business app? Is it an app for for shopping, and these kinds of things? Then note down some scenarios that can impact the app later on in the wild, in real customers’ hands. Then, to derive from that knowledge, derive things that you would to do in your daily life as a software or a mobile tester.

Testing for the different sensors, for example, might be one thing. Or testing for third party app integrations, for example.

I once had a really nice bug that we had a calendar export in the product that I was testing back then. We were just exporting the data to the phone, and we said, “Oh, okay. There’s a calendar on Android, there’s a calendar on iOS, it’s working out.” But then I was thinking like, “Hey, we have an app store. We can install other apps.”

I would check what’s the top-rated calendar app, not from Android or not coming from iOS. I downloaded them, I used them, it was a completely nightmare. Nothing was working. No data synchronization was going to happen and these things. So that’s important, with the testing strategies. Then of course, to test in the different sensors. If you use, one finger, two finger, rotating, pinch to zoom, landscape, portrait. It’s a really nice thing to test on all apps that you have. Because you can find easily lots of bugs, on that side.

On the other side, what you also should keep in mind is that mobile users, they have really high expectations to their own devices. To get a phone for thousands of dollars, it’s a lot of money. At the same time, the mobile device is a really personal device for them. They have their banking on it, they book their holidays, they have their pictures from the family. They have their movies on there. They have everything in this little tiny thing. They have really high expectations also to the software that is running on this system.

So that’s why you have to keep in mind that users tend to delete an app pretty fast and go to a competitor. That’s why you have to be also keen on the whole thing of usability testing, performance testing and security. That’s also usually a topic that is - companies, they don’t want to pay for it, let’s say. They just want to get the features out, and then they hope and pray that nobody will hack the system, no data breach is going to happen. But this is bad. This is bad. This is also something that you should put into your testing strategy. There’s so many things to think about.

Len: That’s really great. It’s interesting, trying to just grasp all the complexity of you were saying - device fragmentation, and then different devices talking to each other across different operating systems and stuff lik ethat, and in different apps. But that idea, or reality, of high user expectation, just really loads on the weight. Because people, as you said, they have all these things on there. But like, partly, I think it’s because we can have them in our hands, and we can wave them aroundm and we tap on them.

No one can see, but I’m doing it with my phone in front of the screen right now. We relate to - people still use the word, “virtual.” But when they talk about doing things on screens sometimes, it’s a tool. When you pick up a hammer, and you’re hammering a nail, you don’t want to think about the hammer. You don’t want to think about it at all, “I’m hammering.” You’re not even thinking that you are hammering when you’re using it. Imagine if you hit the nail and there was a slight delay between the hitting the nail and it actually being hit, if you know what I mean. You’d be like, “Ah, well, now I can’t hammer with it anymore.” You’d throw the hammer away.

This is what happens when people, they’ll go to download an app and it’s like, “Oh, the app didn’t work. Well then, delete.” This might have been your dream startup, “It’s going to change the world, I’m going to be the next Steve Jobs,” and no, everybody forgot about it a minute later.

One thing that I think you recommend is, this might seem trivial if you’ve never built anything, but the first thing you should do after you launch an app is download it yourself.

Daniel: Of course. Absolutely. It’s also in the book. It’s called “update testing.” It’s something that you definitely should do before and at release. Simulate the update process of the app before submitting it to the app stores. Because also I had a situation - that’s why I put it in the book, because it happened to me personally.

Sometimes when you build releases, it’s a rush, “We need to get it out. Let’s do it, let’s do it.”

I was talking to the developer, “Hey, can you do the update testing for me? Because I don’t have enough time, because I have to do another things.” He said, “Yes, yes. I’ve done it, I will do it, I will do it.” Then we submitted. I completely trusted him saying, “Okay, let’s go for it.”

Then we pushed the button and it takes some time until the apps are available. Android, it takes some hours, on Apple it takes a bit longer.

Then I went home, and right in the middle of commuting back home, he called me like, “Daniel, we have an issue. The app is crashing right away after we downloaded it from the app store.” It’s like, “Oh my God, what’s going to happen? Did you do the update tests?” Silence. So he completely forgot about it.

Len: Oh, no.

Daniel: We had a database migration topic back then, so we had to, The mobile database that was on the phone, there was a corrupted field. And, updating from the old to the latest version crashed the app. There was no chance of repairing it, the app was broken. Imagine the user has a broken app, and he might never come back. So that’s why it’s important to think of all these scenarios.

I usually use the metaphor of, remember the magazines back then, when they had these CDs on it? You have a big piece of software on a CD and it’s shipped to the customers. It’s the same with apps. If you have everything in the app, and you cannot control something from a backend or from an API perspective, for example, the app is out there on a device of a user, and if the user is lazy in updating the app, he or she will not get the latest update of their phone. If auto-update is disabled, for example, you might have lost a customer. That’s why it’s important to think about this case.

Len: When it comes to methods and strategies for dealing with all this complexity, there is one thing called “crowd testing,” and I was wondering if you could talk a little bit about what that is?

Daniel: It’s also part six of the book, chapter six. I’m talking about alternative mobile testing techniques. Crowd testing is definitely something that you can integrate into your daily life and into software development.

Crowd testing, as the name already suggests, is you give the piece of software, being it a mobile app or a web application or any software - you give it to a crowd, to a broader audience of people. There are providers out there, crowd testing providers. They offer a crowd to you, so you can basically get a crowd for some euros or dollars. With that, you can tell the crowd provider, “Okay, I need specific personas, for example. I need a different age group, different interests on that testing group.”

Then you give the product to that group, and they test that product for you. They might be customers, they might be crowd testers. Then they give fresh feedback outside from your perspective. You can also call them “beta testers” or “early customer testing,” and these things.

Then you get feedback through the crowd provider. So these testers can be housewives, mechanics, teachers, students, all kinds of people can sign up on those platforms, and they test your product based on your requirements. Then you get some feedback. That’s basically what crowd testing is all about.

Len: Just before we move onto the last part of the interview, where we talk about your work as a writer, I wanted to ask you about the - I guess, it’s been around for a while in various forms. But the next frontier in this, all this testing complexity, is the Internet of Things. I know you’ve talked about it recently in a video on your YouTube channel. But just very briefly, what are some of the interesting challenges unique to the Internet of Things that people who are test strategy crafters are going to have to face, going forward?

Daniel: IoT is another level of complexity, I would say. Because there’s so many things that can be an IoT device. It could be a small button that you could put somewhere, and this is able to communicate already with your mobile device, for example. So it’s all kinds of different sensors and technologies, also built in, for example, in fridges, washing machines, and these things. Everything can be an “Internet of” thing. It can be connected to the internet, and can send data in all kinds of fashion. It doesn’t need to have a screen, for example. It might be just a microprocessor or microcomputing system that is collecting data from, let’s say, environmental data.

It’s something that farmers use quite heavily to gather some feedback on the temperature, on the humidity on the fields, for example, and to send those data to a server, and then to give some guidance. This adds a lot of complexity, especially because you have to test again everything together.

So the isolated testing at in IoT is not the biggest challenge. Because you test on, let’s say, on the IoT device, you can test the communication, you can test the backend, everything separately. But then in the end, you have to test, end-to-end, everything together. That’s a huge challenge, actually. Because this is really hard to automate, especially if you think about technical hardware that is sitting somewhere.

As I said, take this farming example. In the middle of nowhere. So, you have to build up the infrastructure in a lab situation. Or you have to talk to a farmer, or to get some beta testers, and these kinds of things, to gather real insights. Because such an IoT device has come - it is also affected by the environmental surroundings, rain and sun, going back to the farming example. This adds all to the complexity of IoT testing.

So that’s the big challenge. I would say, it’s even more technical than mobile testing. Plus you have to really go into the code, check the logs, write some scripts, even more than mobile testing, to gather insights.

Len: Just moving on to the last part of the interview, where we talk about your experience writing. So your book, Hands-On Mobile App Testing, is actually a second edition, the one that’s available on Leanpub right now.

Daniel: Exactly.

Len: We’ll talk about the print version on Amazon as well. I was wondering if you could talk a little bit about the first edition? How that came about, and who, the publishing company you worked with on that project?

Daniel: I think when I started the book, the idea came when I was home alone, I think it was 2014? I was home alone, my wife was not there each night. I was sitting reading my blog, seeing all the good feedback, and saying, “Oh, ok. Why not start a book?” That was basically the start, and I was like, “Okay, why not? Let’s see if I can make it.” I just outlined the chapters, what I would to do, I would add in the book and so forth and so forth. I did some research, what books are on the market and all these things. Then I just started with writing.

Fun fact, I don’t know if you know it, but the first edition I also published with Leanpub in the very beginning.

Len: Oh, I didn’t know that, no.

Daniel: Yeah. I published with Leanpub, so I also wrote with with Markdown. I wrote it with Markdown completely. Because I wanted to focus on the text and the content, and not with all the boilerplate of Word or other tools, that you can use in formatting text. So I was writing it. I was using Leanpub back then, because I had no experience with publishing. I had no experience with how to sell, how to market a book. Leanpub back then, it was perfect for me. Because it was easy. It was easy for me to sign up, it was easy to set up, I could really focus on writing.

So I published on Leanpub, and I was pretty happy with the first outcome. I think the book was published in, when was it? At the end of 2014, I almost wrote for one year, on the book. I think it was completely one year in my spare time, on vacation, every day.

Then I got contact, via my testing network, to a publisher. They were like, “Hey, do you want to have a real book?” Because back then I was like, “An ebook is really nice, it’s cool.” But I had the feeling like, “Okay, I want to have something in my hands, a real book.” These print-on-demand services, I don’t know if they were already established back then? Then the publishing company, they approached me like, “Hey. We would to publish your book.” So, “Sounds great.” Then I had to take it down from Leanpub, of course. I gave them all the rights, so they were printing it, they were selling it.

Now last year, I contacted them saying, “Hey, look. There are some parts outdated in the book. The link sources are not valid anymore, most of them, because the tools are not there on the market anymore, or the URLs have changed and the chapters have to be reworked, and so forth.”

They were not really interested in the topic, I don’t know why. They didn’t give me any insights why. Maybe it was not selling enough for them. Because otherwise they would have asked for the second edition.

Then I said, “Okay, then can I get the rights back?” Because I put so many hours into the book and so much love to it, and I had helped so many people. I don’t want to let the project die. It took them ages, I think it was seven or eight months until they told me, “Hey, you can get your rights back.”

The first natural thing was, “Okay, I’ll go with Leanpub again.” So I set up everything again. I had my account, but I also wrote the other book, Smartwatch App Testing, and set everything up, and it was still this same smooth experience as back then. It was really, really great. I took time to rework the chapters and everything. Then, I think last week, I hit “Publish” on the book, just see to how the users would see it, my readers.

Len: That’s a really great story. I did not know that the first edition of the first edition was published on Leanpub.

Just for anyone listening, to have someone publish a book on Leanpub and then have to take it down because they got bought by a publisher, that’s great. To us, that’s a hugely successful outcome, and that’s awesome. We have a feature called “Unpublishing a book” that’s there partly for that reason.

I’m very curious about it - so this is something that people in the self-publishing world write about a lot, which is, in the publishing world generally, rights and stuff that. So, when the publisher got the rights to your book, you signed a contract with them, and there were agreements about royalties and stuff like that. But years later, you actually got it back just by asking, is what you’re saying.

Daniel: Yes, exactly.

Len: It took a while, but you just asked, and they gave them back.

Daniel: Exactly. I asked them like, “Hey, how about a second edition?” Because, again, I got feedback from many readers like, “Hey, look, it’s outdated.” Also some Amazon reviews, they were really bad, saying, “The link’s not working anymore. This is wrong and this is outdated. It was there for more than seven years. Yes, of course it’s outdated. What else, in technology?

Then I contacted them, I was like, “Hey, let’s talk. What do you think? Let’s do a second edition.” They were like, “We don’t know, let’s see.” Then at some point I asked them, “Okay, then give me my rights back,” and they agreed. It’s great, actually.

Len: That is really great and it’s interesting, too. Because sometimes the book publishing world can be very unforgiving.

But there’s other interactions you can have with people in the book publishing world, where it’s the long term, and it’s relationships that matter as well. If you’re a publisher, and you care about your reputation, and stuff like that, if authors who are passionate about what they do - and like, a book is in some ways, a unique product, where it’s often very one-person directed, and it takes over their life, as you say your vacations, your weekends, telling your family, “Why isn’t Mommy coming out to the park today?” “Well, she’s got to work on her book.”

So, if a book isn’t making money for a publisher anymore, and if it’s even just getting complaints and stuff that, and the author’s like, “Hey, can I have it back? I want to do more with it?” It actually is something that can happen, where they will just give it to you, just you described.

But I would say, don’t count on it.

Daniel: No.

Len: If you’re thinking of signing a contract with a publisher, this is not legal advice, or anything that, but you should have a worst case scenario mindset when it comes to the language that you agree to.

You can actually have clauses like, “If and when blah blah, the rights revert to me.”

Daniel: Exactly. The good thing is that I always had a really good relationship with the publisher. It was always great, the support was great in the beginning, and then once it got published, everything was really cool. So, why not? They were also fine with it, I guess? So that’s the thing. I have a reference in the book that it was previously published with the other publisher, and that’s the legal part, and I’m fine with it. They are also fine.

Len: You’ve got a print version up on Amazon. How did you do that?

Daniel: I checked for the print on demand services. Because I think that, again, many readers, they would to have a physical copy of something. Especially on a technical book, that they would like, I’m the same person, I have to say. I have many ebooks. But having a physical copy of something at home at my desk, where I can mark something, put post-its on it and can come back later, I’m more that person.

I think that that was the reason why I would love to have also a print-on-demand service available. I heard so far good things on the Amazon print-on-demand service. I talked to some people, and I signed up. I uploaded the documents. I had to rework a bit of the designs, the formatting was a bit different. I ordered an author copy, I got it. It was okay-ish. I had to adjust it again a bit. Now it’s also on sale on Amazon. So let’s see how it goes. It’s just out, I think since yesterday or so? It’s available.

Len: That’s great. Actually, this is one of the reasons we save this talk for the last part of the interview, because we really get into the weeds. But this issue of outdated links in books is a long-running one. You’ve got a solution that you’ve devised to this issue in your book, that I actually have never seen before. I was wondering - it might not be unique to you, but this is the first time I’ve seen it. I was wondering if you could talk a little bit about your approach there?

Daniel: Okay. sure. I was thinking about that for quite some time. Like, “Okay, how can I solve the outdated link topic again for the second edition?” I thought of using my blog in between, to have basically a proxy in between the link pages, the links that I have in my book. So all the links in my book, they have the chapter type, the chapter, a number, plus a number, an increasing number. This links to a specific book page, a specific page on my blog. On my blog. I have the link that should have been in the book. So the links inside the book will always point to my blog.

On my blog, I will make sure that the links that fit to that text, or to that story, will always be up-to-date. I make sure that these things are always valid. So no matter if you bought the book in, let’s say two, three years, the links in the book are valid. On my blog, they will change, but will give you the same information.

Len: And maybe, just on the off chance that’s not clear, I’ll put it in my words. But it’s a very interesting thing, which is, basically, every link in the book would appear with something like CH-02.

Len: The next one would be - well, no. It would be CH2-03 or CH2-04 and that would be, it’s chapter two, and it’s the third link. It’s chapter two and it’s the fourth link.

Daniel: Exactly.

Len: Every time you click a link in the book, you go to the same page on Daniel’s blog. But then you look up, oh, CH-03. Then there’s a link there, and that’s the thing that you’re keeping, you’re maintaining and keeping live all the time. so you match the code in the book to the code on the page. That’s the link. That’s a super interesting way of keeping it live.

One of the reasons I say that, is because, it would work for a print book as well, which is probably one of the reasons you did it.

Daniel: Exactly.

Len: You can put the link, the web address in the print book to that one single page. It’s like, “You will find here maintained, updated links for all the links in this book.” It’s a really interesting way of solving that problem.

The last question I always to ask on the podcast, if a guest is a Leanpub author, is if there was one terribly broken, awful thing that frustrated you to no end and had you shouting at the screen when you were using Leanpub, or if there was one magical feature we could build for you, can you think of anything that you would ask us to do?

Daniel: Difficult thing? That’s a good question. One thing that I found confusing in the last days, was the menu structure. When you are an author, you have your bookshelf, and then you have the settings, you have the community tab, and then sometimes for me, it was just the very first time. It was a bit confusing where to find all the subsections of coupons, royalties, settings for progress bar, and these things. This was a long list of things. It was not a big deal, I had to look it up. I have to really read through it, it was not clear in the very beginning for me. So that was something I would wish for.

The real cool thing would be, having a print-on-demand service included, would be really awesome, to not go somewhere else. But I think this is a really big challenge to tackle with printing, cutting, sending out books. So this would be the really perfect thing.

Len: Thanks very much for sharing both of those. When it comes to menus and navigation, we’re better than we used to be, and there’s always room for improvement.

But one of our shortcuts for that - we don’t really surface this, but we talk about the “author app.” Which is basically, if you’re an author and you’re working on books, creating books, stuff like that, we have the author app side of things. In there, when you create a book or a course or a bundle, there’s an overview page for it, where we set everything out in sections. But it’s thirty links.

Each page has its own title. For example, one was “About.” But we then later called it “About the Book,” realizing we need to be a bit more explicit.

Len: But, even that - we have one page called “Generation Settings.” Ot’s like, “Well that gives me some clue about what thing is going to be in there, but it doesn’t actually tell me what’s going to be in there.”

So our various ways around it is to try to name the pages properly, try to have the right amount of pages, so that all your book settings are in one page, because that can be really hard to find.

Len: The other way, the main tool I guess we have for that, is our Help Center. Which is like, “Where can I set this or thatm what percent complete is my book or, the progress of the book?”

We try to use keywords as well. Then we have screenshots, “Here’s the page. Go to your book Overview page, and then click on “About the Book” and then you’ll find the blah blah blah.”

But that’s just an ongoing challenge, and we really appreciate feedback about that. Because most of the time, people just live with it. That’s not true just with Leanpub, but with anything, people just live with it. Actually hearing back from people is really good of them.

When it comes to the magical “make a print copy of my book available.” We’ve had that request before. It’s possible that someday, some third party print-on-demand service is going to approach us, and just go, “Hey, why don’t we make a partnership? We’ll work with you.” So it’s possible that someday something that will happen. But as you know, dealing with physical objects - if you want a refund on Leanpub, it’s like, oh we just change some settings in your account with regard to accessing the book. We send you the money automatically. Whereas refunding a physical book purchase is a completely different thing, and if there’s a bug in the creation of an ebook, it’s like, “Well, tell us and we’ll fix it.” Then you click “publish” button again on Leanpub.

But if you’ve sent out 100 copies of a print book, and they’ve all got a bug in them, that’s probably 95 returns that you’re going to have to handle.

Len: But anyway, we always really appreciate hearing that, and we know it’s important. Our solution is our Print-Ready PDF export option, which we have. So basically, from the same manuscript you used to produce your ebook, you can produce a print book. You just configure some settings, and then we give you the digital files that you need to upload to any print-on-demand service you want to use.

Daniel: That’s perfect.

Len: Well, Daniel, thank you very much for taking the time 0ut of your evening to talk to me, and talk to us. And thank you very much for being a Leanpub author.

Daniel: Thank you. Thanks for having me.

Len: Thanks.

And as always, thanks to all of you for listening to this episode of the Frontmatter podcast. If you 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.