Escaping the “Perfect”: Does it actually matter? - by Lina Zubyte

In this talk, Lena discusses the pitfalls of perfectionism in software quality assurance and emphasizes the importance of shifting focus from chasing perfect software to understanding what truly adds value. Drawing from her diverse international experience, she highlights how cultural context and user needs influence perceptions of quality, particularly through the examination of an open-source health information system called DHS2. Lena reflects on her journey from being a hardline perfectionist to embracing imperfections as part of the reality of software development. She encourages QA professionals to assess the significance of reported bugs and to prioritize user feedback over numerical metrics. Overall, Lena advocates for a holistic approach to quality that balances trade-offs and addresses real-world challenges faced by users.

Challenge accepted. [music] Challenge accepted. Challenge accepted. P2 [music] is always challenge accepted. Now we know how it goes after lunch. Half of you are already in hibernation mode. >> Please don't fall asleep now. We cannot mark as you idle in real life. >> But if anyone starts snoring, we will just call it low testing for the mics. >> So So let's shake of the food com our

brains and get ready for the afternoon session. Starting with someone who's definitely won't let you snooze. She's quirky, creative, and awardwinning. >> At Euro Star, she won best paper. At Tescon Europe, her talk has was rated the best of the entire conference. >> She's a consultant, writer, and the voice behind the quality bits podcast and blog. >> She's lived and worked across multiple countries, always curious to

learn from new teams and cultures. >> She once made a short documentary film. She loves writing and she brings artsy creativity into tech. >> Today she's here to challenge us to escape the trap of chasing perfect software and instead focus on what actually matters. Please give a big curious and very awake welcome to Lina. Hello everyone. That was quite a welcome. Um, when I read it first,

I was like, ooh, you know, artsy, quirky. I do use these words, but together they sounded very interesting. And I think the last sentence or like part of my bio says something like, she will make you laugh while you think deeply. I was like, what? But let's see if I make you laugh while you think deeply. So today, I would like to talk about perfectionism a little

bit. And I think a lot of us face this a little bit. So how can we escape the perfect uh and ask ourselves does it actually matter? That's a question I really hope all of you end up asking more. So first of all, why is it important? Well, because breaking out of perfection, you can actually become a better QA understanding what value is. Frequently in this role,

we're even thinking, yeah, you know, I test things and I have to find things. I have to be almost perfect and make sure that the software is perfect. Yet, are we actually talking about value when we do that? So, first of all, before I begin, I'll tell a little bit about myself. So, I am originally Lithuanian. I have lived in Hungary for two years and then I

moved to Germany where I lived for over five years and then I decided it's time to move back. So I moved back. I have worked in startups, multinational companies and consultancies. And right now I'm working as a freelancer. So in this diverse experience, I worked with different countries, different people. I worked in different contexts and projects and I learned lots of tricks on the way. I started

as a manual tester who would just say check. We actually verified that. I learned automation. But the biggest important learning for me was data. I fell in love with data and that shifted my whole approach of QA. And right now I do believe in whole team quality approach and accountability that we should actually all care about it and a lot of it is about the system and

the process, right? So a lot of problems we have with quality are system related. But it was not always this way. So when I started, I have this confession to make [sighs and gasps] that I am a recovering perfectionist to the level that you know if I have a scratch on my glasses and right now I do. It really bothers me. I'm like ah this is terrible.

And in a sense we get paid to sort of be perfectionists because we spot issues everywhere we go. Sometimes my friends even tell me, Lena, stop this QAing of real life. You know, you leave work at work. But you know that's also something we tend to do. So I used to be that QA especially at the start of my career where I would say imperfection shall not

pass. Everything should be great, right? It should be pixel perfect. It should be really functioning. And if it's not, well, you know, it's not that great. And I am this person who is telling how it should be. So, I remembered that I was actually proudly stopping releases, sending this email saying, "Yeah, no, we found a bug and we're not going to release this." And I remember also

not feeling good about my work as a QA. If I don't find bugs, I would actually end up piling up certain bugs and trying to find at least something because otherwise, am I useful and good at my job if I don't? And I remember that I really felt like I am representing the customer so I know better which bug should be fixed right isn't that our job

as QA to represent and you know is this the mindset we should have find and fix all the bugs test all the things the more I worked in the QA the more I was like wait a minute is that actually what matters is it is it so important that we find every single bug and that there's It's pixel perfect and every specification works. Is it that And

the idea of what an issue is can be very subjective and even played for the sake of the system we're in. This comic really illustrates this for me. Our goal is to write bug-free software. I'll pay a $10 bonus for every bug you find and fix. Yahoo! We're rich. Yes. Yes. Yes. I hope this drives the right behavior. I'm going to write me a new minivan this

afternoon. This comic is the situation in many companies. If we're measuring defect amounts, easy, we can rig it. And a lot of bugs, are they about quantity? Do they actually matter when we work on them? That's a big question to ask. And it's a little bit harder than than just seeing a number, right? I reported 10 bugs. I'm so productive. And it takes effort to break out

of this and realize that there's a lot of complexity in this. So one thing that helped me a lot was data. And it humbled me a lot because being an all knowing force is also not easy and bound to fail. So it was just a matter of time until I failed, right? All this imperfection shall not pass and I'm perfect. It wasn't sustainable, right? So, [snorts] one

of the earliest memories I have where I realized that maybe I'm not necessarily like my customer was when we had to talk and think about Internet Explorer 11. I don't know, some of you may be lucky enough to have never tested it. But, uh, but the ones that are laughing likely you were lucky enough. Uh, Internet Explorer always had issues with the UI. So something would just

get distorted out of the blue and our team at that moment was like let's stop supporting it. We were working on this automotive project where we were building this like a very modern white label platform where you can basically heat up your car from where you are. So we were like you know these are techsavvy users right and they announced that it will be deprecated next summer.

So we're like who uses it right? definitely not our users and I was on board with the team right it's fine let's not support it and then we were like just let's ask some data right and we got the data back and it was in top three most popular browsers that was the first moment when I was like my idea of the customer is not necessarily correct

because frequently we are not our customers and that's a little bit humbling right in a role where you're supposed to represent the customer. You're not really your customer. You could be a very different person than they are. But it's okay as long as they put in the effort to learn from them. And that's the humbling part because it's not that we know everything. It's understanding that you

have to put in some effort to learn more about your customers. And the more I am in the field, the more I make peace with myself that imperfections are part of life. It's still very difficult. I challenge the status quo of our perceived quality. Like who said that this is quality and is it actually? And maybe we're a little bit stuck up in our certain rules and

assumptions and I question if that bug actually matters even if I reported it. I may be wondering is this actually, you know, very important. Not always I question it. Sometimes I still feel like I know it but that's not always the case. And there is a product that challenged my perception of quality the most. So currently I work as an independent consultant and I work with a

project that's developed but by Oslo University. It's called DHS2. DHS2 is an open-source product that is actually district health information system 2 that is used in so many countries and a lot of us maybe don't know about it but it's generic design open source product. It's especially used as a national health system. So likely in your countries you have it as well. You have a certain system

that's used there. However, um a lot of countries have enough funds to have it. And if you don't have funds, especially less developed countries may use something like DHS2. The first time I saw it, I was like, uh, it's a bit ugly. No. Um, and then when I would click around and I would be like, you know, what's going on, I would realize that there are so

many bugs and so many usability problems in this product that sometimes you click somewhere and it's like not intuitive. It's a little bit clunky. and I would find so many bugs there and I joined them as the QA lead. So I was like what matters in a project like that that you can really customize you can enter data you can visualize data you can make it work

the way you want and it's used all around the world right so your users may be in South America they could be in Africa and you have to understand with whom you're working so I sat down with the lead design Joe and I was like Joe don't you think that design is a little bit you know not great and I was a little bit sassy there because

I was like you know I Oh, I have worked in companies. And Joe was really like just calm and reserved. And he was like, you know what, look around. And we were sitting in Oslo University and there was this picture. Joe said, this picture was taken in a field trip. This picture was taken when we were going to meet our users. And this lady is sitting on

the street, likely a very busy, noisy street, trying to fill in health records. What matters to this woman? Does she care that our DHS2 is such a shiny, beautiful UI? No, she just wants it to work. She just wants it to be easy to enter data. She wants it to be functional. And maybe her internet connection is so bad that she cannot even load that fancy UI.

So Joe said, "You know what? Maybe, you know, I cannot put this product in my portfolio of design. how amazing this is and that it uses latest libraries. But maybe that's not the point of it. Maybe the point is to make it work so that you wouldn't need to fill in healthcare records like that so that you could digitalize it. And that's what DHS2 is for. So

working with this product, I was like, huh, it really questions my understanding of quality and what actually matters. Because what I learn is usually in companies that are like, "Oh, it's very fast internet and we have to make it really nice and shiny, but we don't talk that much about value actually behind it or like does it matter to be that shiny?" Maybe in some context it

does. So what I realized was that quality is about balancing tradeoffs and admitting where it's okay not to be perfect. In this case, it was obvious that, you know, maybe we shouldn't even make the heavy UI because as beautiful as it would look, it could be challenging in certain countries. Another thing that makes me think of trade-offs is security triangle. These imperfect circles are displaying where you

may be in this triangle. Security triangle says that there's functionality, security, and usability. You cannot have it all. So once you're thinking oh yeah we should be definitely very secure but then your usability will not be that great like just think about your parents and relatives trying to use second factor authenticator or like internet banking they don't want that and they're like oh where do I have

to find it and working in a healthcare so when I joined I was like okay it's mostly used for healthcare so it must be secure right it's very important that we have security but then we would see articles like this workarounds to computer access in healthcare organizations you want my password or a dead patient the more feedback we would get from users the more they would say

oh this is annoying I don't want you enter very difficult password I don't want you enter second factor authenticator and so on so these comments make you think because you're like you know it's a healthcare data we should make it secure but the reality in those organizations is that there are for example stickers where you just write your username and password and there was a desktop shortcut

found on abandoned PC with all the login and passwords. this it was in this paper right so I was like okay maybe you know that's not necessarily reality I don't know then I went on a field trip and I saw this in this healthc care facility under the screen there is PW and there is a password so anyone walking into this room could actually connect and see

the data of patients some of this data is quite sensitive however in healthcare sometimes you may want to access data very quickly right? Because it could be a matter of life or death. So thinking of all these challenges, I was like, "Oh my goodness, there's so much to balance here, right? And trade off and I cannot have it all." But we have to somehow learn and understand

what we should work on. So QA is a lot about risk management and realizing what is valuable and it may prove your assumptions wrong on a daily basis. I may think something is important, but is it who said it? I thought that right. But we should actually re-evaluate some of our assumptions as you know definitely a holy grail. So what we did was actually we tried to

explore on what matters by learning from actual users. So we went on two trips which were really awesome. One was Ghana and another Ethiopia. And I learned lots of useful things for my work but I also learned some fun things like Ghana's very creative coffins. So if you die and you're a very honorary person of the community, you could and you really like Coca-Cola, your coffin could

look like a Coca-Cola bottle, but then if you're a fisherman and you really love fish, then maybe it could be a fish. So here is a question to you. If you died, what would your coffin be? And exactly likely it's a bug for many of us. And when we were stuck in a traffic jam in Ara, I remember also asking the our colleagues an implementation lead who

works usually with users implementing the HS2 said about the tech lead, "Oh, he's definitely a big bug." And I was like, "What?" But then I realized why he said it because he meant it a little bit sarcastically that he doesn't fix those bugs. But it made sense because he was actually trying to think of tradeoffs. he wouldn't close a bug very easily because he wouldn't just say

oh it doesn't matter he would always ask why like why is this user reporting it maybe it is very important then another thing is the calendar in Ethiopia is different so my question to you is what's the year in Ethiopia currently so we have 2025 here what is the year in Ethiopia does anyone know what 4,000 no it's Not 4,000. No, not 7,000. Actually, it's 2018. I

really love this headline which says, "Party like it's 2018." Um, because Ethiopian calendar is seven years behind. They just had their new year in September. So, we have to support the whole other calendar. In Ethiopia, there are 13 months. 12 months have 30 days. And the last one, 13th month, has five days. Actually what we heard from Ethiopians is that if you work on those days and

you it falls to be work days you don't really get paid because it's just five days who cares right you can work there so this whole system like expands your view because you're like did you make your system you know something that others could use especially in you know different calendar systems because we work in one type of calendar we cannot realize that there's so many other

ways people use the understand this time. Another thing is we visited health facilities and sometimes you would walk in and you would see these sun-kissed posters and you would be like I don't know this is very clean and then you're like who am I to question this right I'm just a visitor and there are certain realities in countries that you cannot comprehend so what we realize is

that it's okay and part of the job to be proven wrong on what actually matters and when we went there we realized that offline mode is hard to imagine but it is a reality in In one of the facilities, someone was so excited. They were like, "You know what? Now we have this internet stick. We no longer need to go three hours with our hard drive to

upload data in the nearby district." And you know, I went on a trip recently and there was this lady and she said, "Oh yeah, how come in the mountains there's no signal?" And I was like, "Well, there's lots of countries where there's no signal." And then she was like, "Yeah, but like in Canada it does work." like yeah in Canada but not in other countries. So a

lot of countries still do even SMS data recording because you go in the villages and you don't really have it. There's no infrastructure as well. So this uh internet which even is like super super slow and bad. It could save so much time in those countries. Another thing that I realized was well that's some bugs that seem to be an outdated UI that nobody uses actually should

be fixed because for some people it was daily scenario when we asked some officer like show us how you use the product and then we saw them open an old app we were like what we thought that's deprecated you shouldn't be using that but then these statements also don't work if I say upgrade it or just use it like that who am I to say it because

a lot of them are getting their systems managed by an administrator or Like even politically it's a decision if it should be upgraded or not because that means training that means funds. A lot of those cases also when we would just try to figure out sitting here you know with good internet we would not realize what's happening where for example in Ghana they had lots of duplicate

records and they also had some records where a person would be in the system and then they would just disappear and we're like what's going on there and then they said well what's going on is that actually there's a huge HIV stigma so if you have HIV you can have medication but you get that medication, you sometimes go to a different district because you're embarrassed. So that's

how duplications come to the system. Another thing was actually people disappearing and we were like, well, what's going on? Why would people just disappear? And we took this health care officer in in and then we were going to some facility and they were like, well, it's easy. I was like, what do you mean it's easy? Like why do you take medicine that helps you to have a

normal life and then one day you're like, okay, I'm not taking it anymore. And then he said, 'Well, it's the church. I was like, what? And then they said, apparently in Ghana, if you go to the church very frequently, you are being told that we will heal you. You don't need medicine anymore. So these problems are very different than, you know, just me thinking, oh, there's a

duplicate in data and or like infrastructure of the country, right? When it comes to internet access and I may say, oh, but who has offline mode? Because I'm annoyed even if I click on something and it doesn't load immediately. I'm like this is slow. So this field data was actually something that added extra weight for us in the backlog. So when we found information we would add

this context because otherwise it's a lot of assumptions right? So I'm assuming what is important but actually going to the field you realize that realities in other countries can be very different than your own. Frequently when we find a bug we say oh it's an edge case but like who said that something is an edge case and when we were in Ethiopia we realized that some of

the edge cases are your daily business so here is not a sped up gif so actually this is the real time so it's a person switching tabs and they open the same software in two tabs and they switch super quickly because they see which one loaded because their computer is super slow and internet is really slow and then at that moment when we were looking at them

we were like almost like calm down it's okay wait for it because like do we do that right if you have good internet connection we don't really open multiple tabs of the same thing trying to wait it to load and then what the user did was when it finally loaded they clicked upload button seven times like furiously and when it did not react the first time they

just kept clicking and it was slow connection it was old computer and at that moment we had this like horror moment in our team because we're looking at them and we're like we're not going to stop them, right? We're observing how they use the product and we held our breaths because we were ready for some race conditions. We knew something ugly is about to happen and we

admitted our defeat. We haven't tested that because who does And there was a user just doing that in front of our eyes and actually we found quite big bugs with this case and apparently it was a important issue. So testing is a continuous learning process and we have to embrace our creativity. If we cannot really go to the users, well, maybe we can try at least to

think different ways to a little bit exercise the muscle of creativity or like different people because I think we have to be sort of humble in this role because we may not be our users and that's totally okay. So what could you do even if you cannot go to your customers? Well, there is a book 50 quick ideas to improve your tests. And there is a pneummonic

of shaded figs, which could be a nice way for you to think about testing. So, you could test a scary path, which is the highest risk path. Happy the usual path. Angry, where application may react badly to delinquent security risks path. Embarrassing. If it broke, well, that would be really embarrassing. Desolate, give bleakness, zeros, nulls, and so on. Forgetful. Fill up the storage. indecisive. Similate an indecisive

user, greedy, select everything or stressful, explore the breaking points of the functions and components. This is just one type of pneummonic. There are more pneummonics that you could use to try to be like okay maybe now we do a creative session and try to understand okay today we will test as you know a very indecisive user. So time to time think about your users and how you

could test it and just put on you know a different hat a different persona for this So to wrap up this there are some more tips and reminders for you that I have. First of all working with quality is very important and broad. So we have to keep on learning. It's not just writing certain automated tests in one language and or framework. Sometimes when I would interview

people and they're like, "Oh yeah, for 15 years I've wrote selenium test cases." I was like, "Isn't it boring for you?" And also like but that's not you know the field you should really keep up to date. And when it comes to this there are some questions you can ask as well to learn more about the product you're with which is who are the c users and

stakeholders of your product. Can you get to know them? Do you know your users or do you assume who they are? And even if you cannot get to know them directly, maybe there is data. So you could get data from analytics or monitoring. I think that for me was a a lifecher in the career because I was like okay this is something that I can actually learn

from and even understand which bug is how important because you know maybe 50% of users are facing it and maybe it's just 0.5 then keep only what's essential. So, I'm really big on decluttering overall and thinking about messes that we live in. How does your backlog look like? If it's more than 100 bugs, can we be honest here? Are you going to fix all of them or

you're just hoarding them? Maybe it's time to be a little bit real here and balance trade-offs. Can you answer question, how much testing is enough without telling me never enough? Sometimes I ask it in the interviews and then a person says, "Oh yeah, we could always test and continue testing." And I'm like, "Okay, we are not going to work together." Um, so [laughter and gasps] I don't

I don't mock them like that. But um, working in testing, you have to understand the risk. You have to understand what you're working with. You have to understand what's the critical core functionality and what is going to be traded off because you cannot have it And lastly, does that bug that you reported actually matter or it's much more important that you actually release the product with that

bug in it and get feedback from your users? So to wrap up, always question yourself and others if it actually matters because the hard truth is that some of your release stoppers should never be fixed. as much as it hurts. While some of the edge cases are real people. Thank [applause] >> Thank you. Thank you. So you can find Lena in speaker corn. Do you want to

answer? You have time for one question. >> Yes. >> Just one question. The next will be in the speaker corner. So the first one wins. Who wants the the t-shirt now? >> So you will meet Lena in speaker. Uh there is a question of course the far the the most far away. >> I also have some resources. >> Hello. >> Hi. >> Uh I'm Alex. So back

to the recent question uh that was asked towards the audience. How much testing is enough testing? I would like to ask if it's uh safe to assume that uh enough testing when the product no longer has critical or like the highest severity issues it and it's already like ready to >> for example. >> I think it's sort of philosophical and I'm quite philosophical and quirky apparently. [laughter]

So you would need to dig deeper what it means severe, what it means important for you and your context. So yes, it's understanding the value behind it, right? Do we have any areas that are very important for this product that we haven't tested and got feedback on? If we still haven't gotten feedback and we are not okay, this is good to go, then you need to test

those areas. Um, and if you have bugs, then of course it's a conversation. It's a conversation what is valuable for you in your context also. who may be involving most of the organization. >> Okay. Thank you. >> Thank you very much. >> And once again, you can meet Lena in speaker corner. Now, let's hear let's send her off off the stage with big round of applause. Lena

Zuvite. is always sh.