Quality Sense Podcast: Nicola Lindgren – Implicit requirements

Welcome to another episode of the Quality Sense podcast! Today we will share an interview Federico had with Nicola Lindgren. She’s an experienced Senior Test Engineer, QA Lead, and Manager for ustwo. She’s worked on projects in many different industries such as trade, education, and e-Commerce. She founded the Stockholm Software Testing Talks meet-up and co-founded the WeTest Auckland testing meet-up. She has also recently published her second book “How Can I Test This” which she will tell us about. We’ll talk about Implicit Requirements, where we should look for them, how to make them explicit, and much more.

Episode Highlights

• How Nicola ended up in Software Testing.
• What’s her definition of Implicit Requirements
• Where should we look for them? And how do we make them explicit?

Relevant Links:

Nicola’s Blog
Follow Nicola on Twitter
Follow Nicola on Linkedin
Find Nicola’s books here:
How Can I Test This?
Starting Your Software Testing Career

Listen Here

Episode Transcript

Federico:

Hello, Nicola. How are you doing today? Thank you for being here and accepting the invitation, first of all. I am so glad to have you here in the show.

Nicola:

Thanks for having me and I’m doing all good.

Federico:

So Nicola, what about introducing yourself, telling us your story, how you ended up working in software testing. What are you doing today?

Nicola:

A bit about myself or where I am right now. I’m assuming you’re a QA manager at ustwo. In terms of how I started my testing career, I actually did not mean to fall into testing. I wanted to become a diplomat. So I actually went to university and majored in economics and German and also studied Spanish and a bit of finance. So the hope was to be hired by the Ministry of Foreign Affairs and Trade in New Zealand. In the year I graduated, however, they laid off 20% of their staff. So they had a hiring freeze, understandably.I remember seeing a job ad for a grad program for a test consultancy, Asurity and they were asking for people who were curious, interested in technology, had strong communication skills, something like that. I figured, why not apply?

So one unique part of this was you had to write a handwritten cover letter, which I actually did. I don’t write much things by hand these days but I did back then. They trained me up. I was alongside a bunch of people who actually wanted a career in IT or actually who had planned to have a career in IT. I didn’t, until I applied for that role. And the rest is history. I just went with the flow, so to speak. I started test consulting, moved to a startup back to test consulting, and then now I’m at a product studio. I learned a lot on the way, started blogging, speaking at conferences, wrote the book and here I am speaking to you today.

Federico:

Amazing. And now I understand maybe part of the background or the context to be writing a book to help others also break into technology or into testing, right?

Nicola:

Yeah.

Federico:

Is that-

Nicola:

My hope-

Federico:

Yeah, go ahead. Sorry.

Nicola:

My hope with starting in your software testing career was to make a lot of my knowledge and other people’s knowledge explicit. So instead of having to fumble your way or try to just figure things out, I wanted to share my experience and also interview others as to what they wish they knew or how to interview so things that would be very useful for someone, whether or not they’re earlier on in their career or later having that information actually written down. I actually learned a lot in writing that book, for example, Crowdsource Testing. I had a chapter on how to start software testing career in terms of the path you can take. I did a grad program. I didn’t actually talk about myself in that regard in the book, but often people would do like a horizontal shift, so from customer support, they would skill up, they would do vocational training. So go do some one year or whatever degree.

I also came across Crowdsourced Testing, which I had only really heard about. And I really enjoyed learning from people how it actually helped them. When I came across it, I only thought of it as a way to like earn a bit of extra money or I didn’t actually think of it as a way to up skill, truth be told. But then a few people I interviewed told me how they were able to learn new things as a result of Crowdsourced Testing, or even better how to get experience in something without getting normal experience. So often if you want to break into say, you want to start testing mobile apps, right? An employer will generally ask or look for people who have experienced testing mobile apps, but then someone I interviewed, I believe it was Heather. She was able to get experience in something by signing up to test. I think it was mobile apps or signing up to test something through crowdsource testing and then using that on her CV to show she has experience. I hope that ramble made sense.

Federico:

Yeah, so using different platforms, I came across with the same idea when trying to help people without experience to build their resume, to show that they not only to put a new line in their resume, but also to have their real experience and feel more comfortable or confident by doing more testing for instance, maybe in some cases it’s easier to get an opportunity in those platforms done for a Company that in many cases, even though we are on a shortage of test engineers or whatever role in the tech industry, we still look for years of experience or things like this. Right.

Nicola:

There’s a shortage of… I don’t want to say skilled, I mean, a shortage of experienced people. Maybe soon as you get your first role that I’m pretty sure any roles after that are a lot easier, but that first one’s harder. Even my husband, who’s a developer, he struggled to get his first role, but now he’s doing okay in that regard if he wanted to move. You’re in the US, right?

Federico:

Yes, in California.

Nicola:

Also, they had this in New Zealand and I’ve seen this in Sweden. There are these ads saying, “There’s such high demand for developers and testers,” which is technically true, but they don’t really add this little by line saying, “By the way, your first job is going to be really hard to get.” This does really sell, but they do use that little tidbit of information to get people into their courses or educational programs.

Federico:

We got a little bit sidetracked, but I get really engaged with this topic because again, I find it very interesting because it’s not only solving the technical problems, but also it is how we can impact on helping to improve the quality of life of more people. I believe that offering good job opportunities in our field is a way. Going back to the previous question or what I wanted to learn a little bit more about your books, because I know you have already published one and by the day this episode is published your new book will be also available.

Nicola:

Yes. So “How can I test this?” I have four co-authors and they are writing a chapter each based on areas that they are strong in and I don’t have as much experience in or any. For example, Mike is writing a chapter on microservices an environment in which I’ve worked in but not specifically tested. I’ve tested in such an environment, but never in a way where I’m like, this is microservices. How can I treat it differently, so to speak. I’ve got Simman and Sean who wrote chapters around mobile apps and Phil who wrote a chapter at a subscription or unsubscribing notifications. It’s been quite a learning experience having co-authors, I want to keep everyone happy and that’s not hard. I’m not going to say it’s hard, you don’t have to think about that when you’re the only author for a book, because you don’t have to like try and read between the lines and admittedly a bit of an over thinker, but also it’s interesting trying to make knowledge explicit.

The book is about examples, instead of having a bunch of theory where a little bit of example each chapter centers around an example. Then you’re told how you would test this, what test ideas you would use, what tools you would use and why these are of course for demonstrated purposes. If you had a similar feature or app, you would have to, it wouldn’t be an exhaustive list because we’re not aware of your context if you were to test that thing on your project. I think it’s a good way of learning how you can approach problems. In writing the book, we’ve learned a lot from each other, because realistically, if you’ve got someone who’s got five years, experience someone with eight, someone with 10, someone with more than 15, someone with 10, that’s a lot of experience and that’s people who are going through reviewing giving feedback to each other. That’s a lot of information to hopefully grasp.

Federico:

You not only are gathering a lot of information and making it available for all of us, you also got that team interacting with each other and learning from each other in the process.

Nicola:

When it came to having co-authors I didn’t really think about the aspect of learning from each other, which sounds silly now that I say it, I just thought, “We’ve got our specialist areas that we’re interested in. Let’s just write our chapters and then have some reviewers give us feedback, address the feedback and let’s publish.”The thing is, if you’ve got rewriting in Google docs, if you’ve got a shared document, you cannot read other people’s chapters. You’re not going to go straight to your chapter and ignore everyone else. You’re going to have a we nosy at their chapters. And then you’re like, “I should have thought of that.” Oh then you mix some edits. “I really like how she did like that.” I’m not the only one who’s doing that. I’ve seen a few of the others doing that. So that’s been pretty cool and I really like learning. So I it’s nice having access to these people who I’ve never directly worked with on the same project, but being able to pick their brain that’s something I’ve been very grateful for.

Federico:

Amazing. I really like what you’re doing. Also I’m looking forward to have one copy of your recently published books. Nicola, we wanted to talk today about something you gave a talk about the topic, Implicit Requirements. So maybe for starters, what’s your definition of Implicit Requirements?

Nicola:

In my opinion, an Implicit Requirement is a requirement that has not been stated either in written form or verbal form. It requires reading between the lines.

Federico:

Do you have any example?

Nicola:

I hate using a log in as an example. I’m trying to think of a more creative example. I’m going to use a log in example because at least everyone is familiar with how login feature works. An implicit requirement for a log in feature could depend on the project as to what you have written down or what you’ve stated. It could be that characters on desktop as you enter it into a password field are in showing as asterisks or dots. Implicit requirement could be that the submit button or this is in general or for a form is disabled until all of the mandatory fields have valid input. So these are things that you may expect from the system or from the feature from the app, but no one has actually bothered to say or write down.

Federico:

Maybe because this is the standard way, that we are that used to see the applications we use every day behaving like is that we know that it’s part of what we are expecting or what.

Nicola:

It could be based on experience. In my talk, I talk a bit about what influences or factors there are. Your past projects, your experiences of how you think system should be, but this so certain, I’d say good practices. I’ve read a bit about design and consistency across a site would be an example of a very common implicit requirement. Things that are similar should behave in a consistent way. Email address and the validation, I would expect it to be validated in the same way for all email addresses across the site or for a phone number I would expect the max character and the allowed inputs or allowed characters to be the same.

It’d be weird if you had one field and one screen or one phone number field, and one screen that had a max of 10 characters and then another screen, it was a max of 12 and then a one screen you could enter hyphens and the other one you could not, that’d be really weird. But then whoever was writing the requirements may not bother us stating that they may just assume that the developers coding that know that this is how we do phone numbers at this company.

Federico:

Got it. Are there other places where we should look for implicit requirements. You mentioned experience, consistency, maybe that’s related to some other requirements that are related. So if I’m developing a specific requirement, which is related to this other requirement, maybe there are some things that also apply because they are related, but is there any other place where we could try to find or learn or make explicit the implicit requirements

Nicola:

I often would turn to heuristics? When I think about testing against implicit requirements, it blends in with testing without requirements and in which case, heuristics, which are general rules of thumb. Those are a good thing to turn to. I have often used Michael Bolton’s few hiccups. There’s a consistency within product one, which is a common design principle. I have used Shavani Gaba’s embrace for API testing. It’s good to have some heuristics at hand, to help you find these implicit requirements. I do find them to be very helpful.

Federico:

What about the so called nonfunctional requirements? My first position as a tester was in performance testing, and I remember that every time I asked a customer or someone in the team, “What’s the expected time? What’s the SLA for this particular feature?” Nobody was able to provide an answer because most of the times it’s not clear, it’s not explicit, right?

Nicola:

No. I personally don’t really have any experience with formal performance testing. I’ve done it in the sense that I’ve checked other performances, but I would never put it on my LinkedIn profile as a skill. With performance, it depends a lot on like context, how good your internet is, the site you’re using, the degree of patience someone has could vary based on what they’re trying to do. If you’re trying to fill in a form and it’s got three pages, then your level of patient to get from page one to two would be probably shorter than when you’re trying to submit that form. It would be tricky to say to someone how fast is fast enough? People may just pick an arbitrary number. In answering your previous question about examples of implicit requirements, I really should have said nonfunctional requirements, because people tend to expect that, but they don’t bother saying they think mainly about the functionality aside from performance there’s accessibility. I believe in US there’s a law around that.

Federico:

For accessibility. That’s true.

Nicola:

The security, those would be like the main ones I would think of.

Federico:

You were giving an example of a log in page, of course, it has to be secure.

Nicola:

Someone isn’t going to say, “It must be secure.” Well, they say that, but I’ve never seen someone say that because they’ll be like, “Everyone knows that. Why would you want your information to be out there easily accessible to bad parties.”

Federico:

When I said, of course it must be secure. I’m also connecting this idea of implicit requirements with assumptions because probably the person defining the requirements for a log in page is assuming that the one working on that feature will have the same understanding on so many things. Why bother writing this requirements? Probably the other person, the developer or the tester or the team working on this feature, they will also understand the same I’m understanding. So do you also see a correlation between assumptions and implicit requirements?

Nicola:

Yes. I think key difference would be okay. So an implicit requirement a key part it has to be there or should be there, right? It’s required. An assumption is a belief. A way that these two could diverge is maybe someone in a product team has an assumption that the email address field will have max characters of 50 limit, but that is not an implicit requirement. The max character is actually 60, so they’re wrong, but an implicit assumption could be an implicit requirement. It depends on whether not that person is right or wrong. Often it does help to make your assumptions explicit or internal as your implicit requirements. And then seeing, was it just an assumption or a belief that you had, or was it something that we do actually need to address?

Federico:

Interesting. Should we try maybe as testers, to make explicit what we understand they are implicit requirements.

Nicola:

As much as you can, yes. The reason is if you make clear how you understand things, then people can correct you, you can get a shared understanding of how the system should behave. Essentially with all these implicit requirements, you are creating model of the system. If you were to take a step back and think about testing as a whole, I talked to you about getting a shared understanding. Testing in my opinion is about trying to paint a picture of what the system is actually like. And if you’re doing your job right, the picture you paint of the system corresponds closely with the reality.

Federico:

It can help to find gaps between what is in our mind and what is in the reality. This is what you meant?

Nicola:

That’s about finding gaps, having same picture. People would often think that testing is about finding all the bugs or testing against all the requirements, but it’s hard to test against all the requirements, it’s going to be very hard to know what the requirements are. You’re dealing with known knowns and unknown knowns and all that jazz. But then for me, you’ve succeeded as a tester in your role if you have presented an accurate picture of reality or to the best of your knowledge. So being like, “This is what I’ve found and this gives you a very good idea of when you go live with this, this is what you would expect,” because if a tester spends a lot of time testing a feature and then it went live and their findings were very different, then either there’s a problem with testability, there’s a problem with their test environment or maybe the wrong tests were being carried out. And you were so focused on one area that you should have probably had a more overall approach.

Federico:

Makes sense. Related to that, what happens when you find a bug that it’s associated to an implicit requirement and then you have a discussion about, and maybe the developer, the product owner or someone assumes it should work in a different way than what you are assuming the implicit requirement was. You know what I mean?

Nicola:

Yes. In that case, I would wonder what your oracle is. An oracle is what you’re using to tell you whether behavior is wrong or right. On a project, this is often the requirement or a written requirement or a documentary user story. I’ve been in this situation, actually, what I would first do is see is there someone who could be used as an Oracle whose opinion trump’s ours. I would see what they have to say, I’m not going to start this discussion being like, “I’m right. You’re wrong” at this stage, what I have as an opinion, what I have as an assumption, I’m not a hundred percent sure it’s an implicit requirement. If that person doesn’t know and they try to pass me on to someone else or they may turn to me as a tester and say, “What do you think?” I would then try to explain my viewpoint to why it actually is a bug.

Also try to make sure that what I’m saying and what the developer hears are the same thing. It sounds a bit weird, but in terms of communication, they may think that you’ve got a problem with something else. There might be like a miscommunication. This also depends partly on how confident I am with my belief that this is a bug, because if I’m very sure it’s a bug and it’s important, I will persevere. But in terms of picking, if it’s a minor bug, a UI thing and there’s an easy workaround, it doesn’t seem worth fighting at this stage, then I may raise it and assign it to me or may rate… I’ve seen in some bug checking tools, it’s not a bug, there’s a like information, there’s some other category. At some projects I’ve been on the companies care about the those statistics around number of bugs and the severity. So I may handle it differently, the bug tracking tools. So there’s some evidence of it, but it doesn’t affect the metrics when people care about metrics.

Federico:

Interesting. I see your point. With your team, do you have working aa agreements or something to work these type situations or anything related to implicit requirements?

Nicola:

I have been working for a good period of time and I have earned the trust of my team. I’m actually currently on maternity leave, but the team that I was on for over a year before I went on maternity leave. I’ve earned the trust from my team. I’ve got credibility, they know that I know what I’m doing. I haven’t really gotten much pushback when I’ve raised bugs against implicit requirements. I think the context matters because it’s one thing to have a tester in your team who’s got a lot of experience who has demonstrated a lot of value raising these sorts of bugs because they’re like, “Nicola knows what she’s doing.”

If you are a new tester with a lack of experience, that’s a different story. Maybe a working agreement is needed answer your question, I do not have one. I have not had one. I don’t know how much I would personally benefit from one because I’ve been good at communicating why things are issues and referring to the Oracle, which explains why this behavior is right or wrong. I do see how working agreement could be needed either you’ve had issues and agreeing what a bug is or what a bug is not. Or if you wanted to get ahead of things.

Federico:

But you mentioned something that I find really important, which is explaining why also of course, with the time in your team, you earn that confidence, but explaining why it probably helped in earning that confidence from the rest of the team.

Nicola:

Yeah. I’ve never wasted time just writing bugs and not justifying why it’s an issue. When I would write them down or when I first start asking of the questions, either through Slack or face to face, I make sure to explain why, because any bug I find is going to require time from the developer in general. I want to show why is this worth your time and how will this benefit our team. So even if it’s not an implicit requirement or even if the bug isn’t against an implicit requirement, I make an effort to communicate why this bug should be addressed or what value is added by addressing this bug.

Federico:

Yeah. 100% with that. Nicole, I think this is this been very, very useful. I’d like to wrap up with some final questions. One, if you had to recommend a book to the audience, which one would it be?

Nicola:

I would have to say, Atomic Habits by James Clear. I think it’s when it comes to striving towards goals or working towards something that you want to achieve. It’s about the day to day, it’s about the systems you put in place. It’s not about the massive things you do. I had also read The Power of Habit and Tiny Habits. I believe it that’s called. Atomic Habits was very concrete and I like concrete, I’m not as good with inspirational truth be told. So I would really recommend that book if you have not read it already.

Federico:

Amazing. It’s going to be in my reading list soon.

Nicola:

Great.

Federico:

Is there anything you’d like to invite the audience to reaching social media access? I will share your website in the piece of notes, also the links to your book. Is there anything else you want to invite the audience?

Nicola:

I would just like to say if you know someone who’s going to start the testing career, I highly recommend my book starting your software testing career and feel free to say hello. Mainly I’m more active on Twitter than I am on LinkedIn but @NicolaLindgren on Twitter.

Federico:

Excellent. Thank you so much for all the information, all your thoughts for sharing all of this. Very, nice talking with you. Thank you.

Nicola:

Thanks for having me.