Iman is an experienced QA Lead based in Québec, Canada. She was the winner of The Test Factor at The Testing Festival2021, which is surely the highlight of her career so far…
We caught up with her to hear more about the winning concept, what inspired it, her approach to testing, and her journey up to this point. We imagine a lot of it will resonate with you!
Hi Iman, welcome to the QAL community. Let’s start from the beginning. How did you get into testing, were you a developer before a tester?
I studied as a developer so I know how to code, but I never worked as a coder. After my studies, I went for some job interviews and one of them was for looking for a tester. I asked, “okay, so what’s testing?” the person did not answer the question in detail really, she just asked me a lot of questions about me as a person—she was interested in my personality. Then she told me “you’re going to have an interview at ING Direct, the online saving bank ”
When I got to the interview, the same thing happened. The interviewer also asked me some questions about testing, for example: “How would I test this contract or these interests?” and “imagine we have these offers for this kind of account, how would you test it?” And I remember asking him more questions than he asked.
When I arrived home, my friend asked me how it went and I said “well, it’s weird. I asked him more questions than he asked me, I couldn’t answer his testing questions. So I don’t know, I think it went bad.”
To my surprise, I was hired and I kept asking myself “okay, what’s this testing? What am I going to test?” And my first boss said, “You don’t know about testing. Here’s a sentence or requirement, write a test case.” I told him “I’ve never written a test case.” He said, “Do it, we’ll see afterward” So [I] did it. And he said, “So you got it right.” Then I was like “Right, okay. I’m not going to test buttons?” “No, you’re going to test the requirements. If they’re reliable and understandable.” So I was like “Okay, it’s a job where I have the right to ask questions?” And he said, “That’s correct.” So, from that moment, it became a passion. I love the job.
So that’s how you’d describe testing then, asking the right questions?
That’s what I like because I have the right to ask whys and hows. In France, when you’re a young student, you’re not allowed to ask deep questions of why and how, unless you have a diploma first, but I always like to understand why things are happening. Why are they asking me to do something? So with this role, I had the right to ask these questions. I had the role, so I was very thrilled about it. Very excited. This is the first thing I loved.
The second reason is I like people and working with different people. I love the challenge around it, and making people speak the same language and target the same goal. Because you have the user who wants something, you have the boss [who] wants another thing, the developer that says something else. And you’re somehow in the middle of all this, and you need to make them understand. So that’s the challenge I like most, to make people understand each other.
So testing isn’t just you come in at the end of like a software build and poke around and try and break things then?
For me, no, it’s much more than this. That is the basic thing, it’s one of the tasks. Let’s say you have 100% of passed tests, what makes these 100% passed tests okay for the user?
You’re happy because you have covered 100% of the requirements. But what makes you think that your coverage is what is really needed? If you don’t see the users, and if you don’t understand the whys and the hows, you can test anything you want but it won’t be right.
So you like to work closely with the UX and user research team?
I push to work with everyone. You have some project teams where the product owner will be the one that’s in front, the speaker for everyone including the users. And that’s okay, I like to work with them. But I also like to hear what users really need as a quality point of view, not the functional. So even if the product managers tell me that these are the people, and these are your stakeholders, I push the frontier and ask more questions. Who are they? Are they aware that what you’re asking will mean this impact? Things like this. So it’s not only testing for me, this was just one part.
So it’s more like a holistic kind of thinking about the whole project?
Okay got it. So this is what inspired the Shift Up and Spread concept? Congratulations on your Test Factor win by the way!
Thanks! The concept came after working in France and Canada and seeing that whatever the sector, and whatever the continent, we still have the same problems. Quality and testing are kept at the project level only. And, as I told you, I push the frontiers, I push the stakeholders, because if we keep them at the same level, trying to solve or to test whatever is given here, I know with the experience I have that we will have problems with the users in the end. We will have some budget problems, we will have some other problems.
So one day I said “okay, stop thinking shift right, stop thinking shift left. First of all, you need to go up and convince the hierarchy, the top management, of what is quality? What is quality assurance, what’s our aim? How it goes. How it works. It’s not only testing. And when we say that quality is everyone’s responsibility: for me, it starts from them. They are first responsible for the quality and the testing of everything.
So this is why the idea came up, or at least the name, because everyone knows that from now we need to convince the top management and somehow get them involved. For me, it’s a prerequisite. It’s not in the middle. It’s the first thing we need to do before thinking where we can put the best testing areas.
And then spread because it’s not enough just to go and convince the hierarchy or the top management or the CEOs. You need to work with them to spread the quality all around the company, to have this quality culture and this quality mindset. If a project fails, or there’s a huge bug—like in the social networks for example—the teams that worked on it will not stay there. No one will remember that guy who worked on that project that failed, or what caused the bug. What’s remembered is the name of the company. So it’s more important than just saying that the project and the teams are responsible for the quality, everyone is.
So what you’re saying is that you want to come in and change the whole business culture, and business mindset?
Exactly. Testing is just an action. It is just the last component of quality. For quality, you need to put the strategy, you need to think about what criteria you need to highlight for this project with the users. For example, if the user needs high performance, to test this high performance we need a tool and it happens that this tool is very, very expensive. And for instance, they did not budget it, they did not put any budget. So, again, it comes late.
So yes, we need to test earlier, but we need to get involved earlier and to understand the quality and the quality criteria — I think there are 10 now with the ISO 25010. Users need to express themselves towards all these criteria, and the top management needs to understand why these criteria are very important.
Once this is done, once we understand all the risks, then we can test. TDD, all these things, they’re great and this is very important and I’m not saying they don’t solve any issues, but there’s a lot of issues that can be solved before testing.
Yes. For example, in some of the projects the project manager is happy to have me in his team. They’ll say “Okay, we have Iman, she’ll take the test strategy.” I say “Okay, great. Can you put us in the loop with the client, where we can present him with the strategy”? And they are usually ok with that. They seem to understand the philosophy and let me speak with the client. That’s perfect. But the next week, he says, “Okay, we estimated your budget.” I say “Who estimated the budget the QA needs for their activities?”
They don’t understand that it’s not only theory that says we need to be involved in every aspect. So it’s hard for them to change their mindset and realize that testing and quality is not just a percentage of what developers do, I think they take 40% of the estimations. It’s not a reflex yet to go and get the QA, as the experts, and say “okay, here’s the project even if there is no QA involved here, what do you think?”
And with our experience, we can highlight what the client really wanted. I love reading between the lines and saying “okay, he said this, this is what it means in reality, this this this, ask him the question, you will see.” And this is what experts in quality, or experienced people that have worked in many, many sectors, can highlight. It’s important to help the even top management understand this; and project management.
Okay, understood! Looking forward to seeing how the project develops with Jonathon as your new mentor. Thanks for your time, just one more question: for new people who are just starting out in their careers with testing, do you have any advice for them about how to approach their role or their development or anything?
Continue to ask questions and don’t be scared when people tell you “no, your part, your role is there, at the end”. No. QA testers have a huge role to play. They’re not just testing or executing, they have to play the role of making people understand each other and ensure that we’re speaking the same language and that we’re looking at the same goal. Over the next ten years, the technologies will develop, and people will be needed less for actual testing, but the testing philosophy will stay, and it will still be very needed.