Product Reliability: A Chat with SeerBit's Quality Assurance Engineer

This week, we sat down with Blessing Olaiya, our dedicated Software Quality Assurance Engineer. With over five years of experience across fintech, banking and e-commerce, Blessing shares what it takes to keep our products reliable, secure and user-friendly. 

Hello, can you tell us your name and give us some information about your background? 

Hi, I’m Blessing Olaiya. I’m a Software Quality Assurance Engineer with about five years of hands-on experience in the QA field. 

I hold a BSc in Computer Science, and over the years, I’ve had the opportunity to work across different industries from fintech to banking to e-commerce. My focus has always been on ensuring quality, whether that’s through manual testing or automation. 

Right now, I work at SeerBit as a QA Engineer, where I test our products across the board. That includes everything from our mobile apps and web platforms to deep-level API, front-end, and back-end testing. Basically, if it’s part of the application, I’m making sure it works as it should. 

So yeah, that’s a little bit about me where I’ve been, what I do, and the kind of experience I bring to the table 

So, what inspired you to pursue a career in QA engineering? 
 

Honestly, I’d say it started with who I am at my core I'm a quality-focused person. I genuinely love it when users are happy and things just work the way they should. One of my strongest skills has always been attention to detail, and that naturally fits right into the world of QA. So pursuing a career in quality assurance felt like the right thing to do. 
 

So, you just looked at yourself and said, this is who I am, and this is what I can do? 

Well, not exactly. I’ve had some hands-on experience with both front-end and back-end development in the past. But truthfully, it just didn’t click with me. I wasn’t enjoying it as much as I thought I would. So I took a step back and did a bit of self-reflection asked myself, “What do I actually enjoy doing? What comes naturally to me?” And that’s when I found my path in QA. 

Once I got into it, everything just made sense. I enjoy the process, I love digging into the details, and there’s something really fulfilling about making sure a product is solid before it reaches users. I can confidently say I’m passionate about QA it’s not just what I do, it’s what I enjoy doing. 

Tell us, what your role at SeerBit entails, like on a day-to-day basis, as a Quality Assurance Engineer?  

So, typically, the first thing I do in the morning is attend our daily stand-up. It’s a quick sync where everyone shares what they’re working on and if there are any blockers. Right after that, I go straight to my board to check for any pending tasks or anything that needs my urgent attention. That gives me a clear picture of how to structure my day. 

Once I’ve mapped that out, I update my test cases I also make it a point to liaise with the software engineers. Since QA and Devs work closely, I always Sync with them to understand any new implementations. If I notice something isn’t working as expected, I don’t hesitate to flag it right away. 

I’m also in regular contact with the product team. I share feedback on the features they’re building and help ensure we’re aligned on what the end-user should experience. 

Another big part of my day is verifying bug fixes. So when engineers mark a bug as fixed, I double-check to make sure it’s actually resolved. And if we’re close to a deployment, I run regression tests to make sure everything still works as expected. 

That’s pretty much a typical day for me it’s a mix of communication, verification, and collaboration, all to make sure we’re shipping solid, reliable software. 

This means your work involves a lot of communication and cooperating with other teams and departments in the organisation, right? 

Yes, it does require me to communicate with different stakeholders like Software Engineers, Product Managers, Project Managers, Designers, Customer Support and Tech Support. 

That seems like a lot of work. 

Yes, it is. But I enjoy it.  

Alright, so can you walk us through the quality assurance process for a new product or a new feature at SeerBit? 

So, here’s how it typically works for me. 

Everything starts when there’s a new product or feature in the pipeline. The product managers are usually the first ones in the loop, they come up with the Product Requirements Document (PRD), which outlines what the product is all about and what each department needs to know. 

Once the PRD is ready, I jump right in. I take time to thoroughly review the document so I can really understand what’s expected from the product. Then we usually have sessions kind of like deep dives where we sit down to discuss the product in detail. 

After that, I collaborate with my QA team to break the feature down and come up with all the possible test scenarios and test cases we’ll need. A lot of my test case design is driven directly by the PRD. It’s really important to catch any unclear areas early, so these sessions help make sure we’re all aligned. 

Once that’s set, I move on to preparing my test data and getting the test environment ready. We usually test in a staging environment that mirrors production as closely as possible. I run a range of tests functional, non-functional, usability e.t.c. My goal is to make sure the product isn’t just working, but that it feels right to the end user. 

When I feel confident that the product is in great shape, I recommend it for beta testing. This is when we release it to a select group of users to gather real feedback. Their insights are gold, we use that feedback to fix bugs, tweak features, or make improvements before the full rollout. 

We also do a lot of internal testing. It’s not just me; the product team and sometimes other departments get involved. Everyone plays a part in making sure the product is truly ready. 

And once we’re all confident, we push it to production. 

Interesting, you've mentioned a lot of testing, right? Are there more tests you carry out? Can you throw more light on the different types of tests? 

 So, for a new feature, I run all kinds of tests on it. For e.g, Usability testing - I want to be sure that when people are using the products, they are not angry. Performance test - the application is performing as optimal as possible. Imagine you want to click a button and it's taking up to 10 seconds for it to respond, you're going to get frustrated and be like, what's all this? So we run lots of tests, and they're important. 

So how do you then ensure that critical issues don't slip through to production? 

By running different kind of tests, like I said earlier. I also make sure to understand what the product team wants. I read through the PRD thoroughly and I write comprehensive test cases that would help and guide me while I'm testing. Aside from that, I mentioned that after we've run several tests in-house, we roll out the product to some specific users so that we can get their feedback from the product. 

So, after we've done that, we take their feedback and use it to make necessary updates. Then, we run another test before we go live. I think based on all those processes, it ensures minimal issues, not like the products would be 100% bug-free, right? But it would be very minimal bugs that would go to production. 

What about rare payment scenarios or edge cases how do you handle testing for those? 

So, what we usually do is boundary testing. That’s where we explore different payment conditions like minimum and maximum amounts, decimal values, and even negative numbers. We run test cases for things like ₦0.01 payments, bulk transfers, really high amounts, or even entering invalid values just to see how the system reacts. It’s about making sure the app handles both expected and unusual scenarios properly, because in payments, even the smallest mistake can have a big impact. 

You’ve worked in e-commerce and other industries how does testing differ in FinTech compared to, say, a social app or e-commerce platform? 

Oh, testing in FinTech is a different ballgame entirely. You’re dealing with money, and that comes with a lot more responsibility. For instance, in e-commerce, if an image doesn’t load or a product is out of stock, it’s frustrating but not critical. But in FinTech, if something goes wrong with a transaction like a wrong debit or a failed transfer it affects people’s trust and finances. 

I take testing in FinTech seriously. I approach it with a security-first mindset, always thinking, “What if this app fell into the wrong hands?” A good example: with an e-commerce app, I can open it, leave it idle for hours, come back and still use it. But with a FinTech app, that shouldn’t happen. There needs to be session timeout, auto logout, and other compliance rules to protect user data and funds. 

 Aside from session control, are there other nuances that make FinTech testing unique? 

Definitely. There’s compliance, data privacy, encryption, and third-party API checks. Many FinTech platforms integrate with banks, payment processors, or KYC services. So part of my job is to make sure those integrations are reliable. I always test the connectivity, the response data, and how gracefully we handle errors if a third-party service is down. 

And of course, there's security testing you have to think like someone trying to break the system. Because if you don’t, someone else will. 

 When testing payment flows or integrations, what are the key things you look out for? 

The first thing for me is always data integrity. If I’m sending ₦10.15 to someone, that exact value should reflect all through the process initiation, processing, transaction history, and confirmation. Nothing should be lost or rounded incorrectly. And if there are transaction charges, they should be clear and logical. For example, only the sender should get charged; the receiver should get the exact expected amount. 

I also watch for duplicate payments. A user shouldn’t mistakenly send the same amount twice due to a lag or glitch. And if something goes wrong during the payment say network disruption the user should either not be debited, or if debited, the system should trigger a swift refund. That refund logic is very important. 

Since you joined SeerBit, what has been your proudest moment so far? 

One moment that really stands out for me is when we launched the new merchant dashboard. It was a big project, and I played a key role in testing it. Seeing it go live and hearing positive feedback from merchants honestly, it felt so good. I could look at it and say, “Yes, I tested that.” That pride of ownership as a QA engineer is unbeatable. 

Also, I’ve been able to improve some of our QA processes since I joined. I’ve contributed ideas that made our testing more efficient and our releases smoother. That, for me, is very fulfilling.  

What advice would you give to someone starting a career in QA? 

First of all, you need to have passion for quality. That’s non-negotiable. You must pay attention to detail and, most importantly, think critically. You need to constantly ask yourself, “How would a user interact with this feature?” or “What could go wrong here?” 

After that, start with the fundamentals understand the software development lifecycle, learn how to write test cases, test plans, and other core documents. Once you’re confident in manual testing, move into automation. Whether it’s UI, API, or performance testing, pick a path and stick to it for a while. 

Then choose tools that align with your goals maybe Selenium, Cypress, Postman, or JMeter and go deep. If you can, get a certification like ISTQB; it’s recognized and helps you stand out. 

But honestly, beyond all that, be curious. Keep learning. And always, always test with the end user in mind.  

Thank you for your time, Blessing. It was nice having this conversation with you.  

It was my pleasure.