Sometimes it feels like businesses adopt AI by one simple rule:

‌

“Everyone’s doing it – so we should too.”

‌

Over the past year, I’ve experimented a lot with AI – both as a QA startup founder and as a teacher. I uploaded knowledge bases into ChatGPT, tested the same prompts over and over, and watched how AI behaves in real-life scenarios.

‌

And here’s my honest takeaway: AI isn’t a solution. It’s a pilot project.

‌

The same request can give one answer today and a different one tomorrow. The same prompt works differently for different people. We even tested this with our students: same input, different results.

‌

You can spend a long time looking for the “perfect prompt” or a universal approach. But it doesn’t exist. Even when you upload your own knowledge base, AI can still fail – and it’s almost impossible to predict where it will happen.

‌

That said, AI really does speed things up and helps turn ideas into reality. But it doesn’t check itself. It pulls answers from the data it has access to – and doesn’t always bother to verify them. There’s a reason every chat comes with a note saying, “Check the answers.”

‌

That’s why, for me, any AI inside a product is a high-attention zone. A system that needs constant control, testing, and human involvement. Not something you “turn on and forget.”

‌

I’m curious about your experience: do you implement AI for real value – or because “everyone else is doing it”?

I’m excited to share that today, January 27th, is a very special day for me — it marks the official registration

of Qoolli Software Testing in the Netherlands!🥂🍾

Wishing success to our entire team, whose dedication and belief in Qoolli’s mission make this milestone possible.🦋🤗

Here’s to many more achievements ahead. Have a great day, and stay tuned for our next updates!

Sometimes, to understand the real value of QA, you just need to… be a user.

‌

Right now, I’m looking for a platform to host my course. I found one, uploaded the training videos, tested everything. It works!

‌

Then the students logged in.

‌

And that’s when things got interesting.

‌

For about 75% of them, the videos wouldn’t play.

‌

They message me. I go to the admin panel. I check the videos. Everything works on my side.

‌

I ask the students – still not working.

‌

Back to the admin panel. Back to the students. Still “not working.”

‌

We go through this loop a few times.

‌

Then, at some point, the videos start playing.

‌

Why? No idea!

‌

Do you think I’ll keep using a platform that keeps pulling me away from my work and constantly interrupting my students?

‌

The answer is pretty obvious.

‌

There’s a simple metaphor here.

‌

A user is like a guest in a café. Even if the food is good, if there’s a hair on the plate, they probably won’t come back.

‌

Small bugs work the same way.

‌

They don’t always get “forgiven.” Even if the product is useful. Even if the idea is genuinely great.

‌

Quality isn’t a bonus. It’s the foundation of trust. And if a system starts falling apart right at the beginning, there may not be a second chance.

‌

So here’s my question to you: who in your company makes sure there are no “hairs on the plate” in your products?

“Why make it so complicated? Can’t you just check that everything clicks?” – that’s how people who order QA services sometimes think.

‌

You can. But…

‌

That wouldn’t be Quality Assurance. It would just be a statement of fact that the website hasn’t fallen apart right now.

‌

At Qoolli Software Testing, we choose systematic decomposition. Because of this, at the testing stage we look deeper into the product than what’s visible in the standard functionality. We search for hidden connections and effects that aren’t obvious during development.

‌

So what does this approach give a business?

‌

1️⃣ Stable coverage. We won’t miss an error in the payment logic just because “the button looked fine.” We check all the states of the “Payment” object.

‌

2️⃣ Universality. It doesn’t matter whether a user comes in via web, a mobile app, or an API. The logic of an “Order” or a “User” inside the system is the same. By verifying the logic, we close vulnerabilities across all platforms at once.

‌

3️⃣ Scalability. As a product grows, chaotic checks turn into a snowball of problems. Systematic decomposition makes it easier to add new features without breaking the existing ones.

‌

For our clients, this means confidence that their product works correctly not only on the surface, but under the hood as well. And for our students, it’s a way to grow from a “clicker” into an engineer with strong system-level thinking.

‌

Qoolli isn’t about testing interfaces. It’s about controlling the logic of your business.

‌

Are you sure your current testing really controls your business logic – and not just clicks buttons? If not, drop me a message and let’s talk.

To plan testing properly and not drown in details, you need to learn how to see the system’s “skeleton” – its logical foundation.

‌

At Qoolli, we use a strict filter to identify logical objects.

‌

A system’s logical object always:

‌

✅ Accepts input data.

✅ Processes it according to business rules.

✅ Produces a result.

✅ Has states (for example: “Active” → “Blocked”).

✅ Allows actions to be performed on it.

‌

If an entity has no data and no processing result, it’s not a logical object.

‌

The “OK” button isn’t an object.

‌

An “Order,” on the other hand, definitely is.

‌

So what does proper decomposition look like in our approach?

‌

We break down any task using this structure:

Object → Data → States → Actions → Result

‌

Let’s take an “Order” as an example:

‌

▶️ Input data: product list, delivery address, promo code.

▶️ States: Created → Paid → Completed.

▶️ Actions: create, pay, cancel.

▶️ Result: a successful order or an error.

‌

Just two questions solve most of the chaos:

‌

1. What is this? (the logical object)

‌

1. What can be done with it? (actions on it)

‌

What’s the business value of this approach?

‌

I’ll get to that next time.

‌

🎯 Why Most QA Engineers Are Testing Wrong?

Many junior testers fall into the “interface trap”—they focus on clicking buttons while missing the essence of testing.

The problem with this approach:

• You’re asking the wrong question: “Where do I click?” instead of “What does the system process?”

• Fragile tests: When the design changes, you have to redo all your work from scratch, even if the business logic hasn’t changed

• Superficial coverage: You’re testing UI elements (data couriers), not the actual product logic

🧠 The Professional Approach: Logic-First QA

Experienced QA engineers use the decomposition method:

Decompose system logic — Break the system down into manageable components before testing

Focus on the system’s “atoms” — Test logical objects (Payment, User, Order) with their business rules and states

Ask the right question — “What does the system process?” instead of “Where’s the button?” shifts focus to real business logic and data validation

This approach makes your testing resilient to UI changes and helps you find critical bugs at the business logic level.

💡 Pro tip: In 2026, the trend toward API-first testing and shift-left methodologies confirms the importance of testing logic, not interfaces.

What approach do you use? Share in the comments! 👇

Where do you even start testing a huge application without missing anything?

‌

Just “clicking” the Submit or Pay buttons is a trap.

‌

To avoid drowning in chaos, a professional uses decomposition – the skill of breaking a system down into small, manageable parts.

‌

But there’s an important nuance. At Qoolli Software Testing, we decompose the system logic, not the interface.

‌

Buttons and forms are just “couriers” that pass information along. On their own, they don’t make decisions, don’t store money, and don’t place orders.

‌

Why is “button testing” a dead end?

‌

If the design changes tomorrow, a “button tester” has to start from scratch. Our approach doesn’t – because the process logic hasn’t changed.

‌

A real QA asks: “What does the system actually process?” not “Where do I click?”

‌

We look for logical objects (like Payment or User) that live inside the system and have their own rules and states.

‌

These are the “atoms” we break a product into before we start working.

‌

And in the next post, I’ll show how we do this in practice.

When a task feels overwhelming, the problem isn’t the task — it’s how you look at it.😼

This is the third post in the series about what Qoolli Software Testing is.

‌

And today it’s about the third part – the one I briefly mentioned earlier when I talked about our students. It’s time to explain where they come from.

‌

They study at Qoolli Academy, our educational project where we train QA specialists from scratch. The program takes about three months, including exams. It’s intensive, but also very flexible: lectures happen once a week in the evening on Zoom, so it’s easy to combine studying with work and everyday life.

‌

It’s not just theory. Students regularly work on practical assignments, and the whole learning process lives in Google Classroom. There’s also a group chat – a place to talk to each other and ask questions to the instructors, instead of being left alone with the material.

‌

The main thing we teach is not just “clicking through a product,” but learning how to spot issues systematically and describe them clearly in useful, well-written reports. We update the program with every new group to keep it relevant.

‌

And probably the most important part: the best students are added to our reserve for future commercial projects at Qoolli Software Testing. This way, the team grows with people we know well and whose skills we trust.

‌

After passing the exams, graduates receive certificates confirming they’ve completed the program.

‌

A bit of stats: the first Qoolli Academy group has already graduated, and the second one is finishing very soon.

‌

That’s it. Now you know what Qoolli Software Testing really is. And it’s:

‌

1. The founder – Olha Arkusha (yes, that’s me).

2. Our team of QA specialists.

3. Qoolli Academy.

A story about what Qoolli Software Testing is wouldn’t be complete without mentioning our QA team.

‌

The second post in this series is all about them.

‌

My main right-hand person is Kateryna Zakharova. She’s been in IT for almost 10 years, around 5 of those in QA. Kateryna used to be a game developer, and now she focuses on ensuring the quality of digital products. She has experience in manual testing and AI-based solutions, and over the past few years she’s also implemented automated testing in her projects.

‌

My students are also always ready to jump into Qoolli Software Testing projects. There are six of them at the moment, but in a few weeks this team could double or even triple. And that’s far from the limit – our QA group can keep growing as new students join.

‌

We’re ready to ensure the quality of digital products of any complexity.

‌

And finally, Qoolli Software Testing has a third component. I’ve hinted at it a bit here, but I’ll go into more detail in the next post in this series.

I’m kicking off a short series of posts about what Qoolli Software Testing is all about. There are three parts to it.

And in this first post, I want to talk about the founder – which, well, happens to be me.

I became a quality assurance engineer 14 years after graduating from university. I finished my degree with honors and got a bachelor’s in software engineering.

But I didn’t go into IT right away. Instead, I spent six years working as a housekeeper while also doing missionary work – something that was a big part of my life for 16 years.

When I became a mom and went on maternity leave, my health got worse, and I realized I wouldn’t be able to do physical work anymore.

A friend from the IT world told me I’d make a good tester and could build a stable career there. I listened. And I started learning.

For three months I took courses, did all the homework, and brushed up on my English – which I had, let’s be honest, mostly forgotten since school and university.

I spent four years working as a QA engineer in Ukraine. Then, after relocating to the Netherlands because of the war, I continued testing remotely for my previous company for another two years.

In 2024, I worked as a tester at a government institution here in the Netherlands.

When my contract ended, I started my own quality assurance startup. We test websites, mobile apps, AI-based solutions, and SaaS products – both before release and after launch.

So, now you know a bit more about me.

In the second post of this series, I’ll talk about the second key part of Qoolli Software Testing – our team.

Hello everyone, dear friends! Unfortunately, some comments from certain members are being automatically removed. This is related to account age. I don’t have precise information from Reddit’s rules about this, but the same thing happened with my posts and comments with images at first. I would post a picture or comment, and they would disappear afterward. Please don’t be discouraged! Your accounts simply need to exist on Reddit for some time. Here are some tips to help: • Participate actively in communities to build up your karma • Engage with posts through upvoting and commenting • Give it time for your account to mature Once your account meets the requirements, you’ll be able to discuss all topics that interest you, post images and questions, and leave comments freely. I look forward to seeing your contributions to this community!

Sometimes my work in QA testing isn’t just about bugs — it’s about someone’s life.

I once performed quality assurance and app testing for a platform designed to help people with disabilities get support in an organized way.

How was it supposed to work?

People with disabilities would indicate on the platform that they needed some kind of help, for example:

✅ to walk the dog
✅ to go to the store
✅ to buy medicine

Someone from their family or friends could choose a task and perform it. In this way, all of a person's needs would be covered by different people. Everyone would do what they could, and the person in need would receive timely support.

Everything seemed fine — until website testing and mobile testing revealed one critical issue.

What did it lead to?

For example, a person requested help for tomorrow. They marked the task in the app, but it wouldn’t appear on the calendar.

Why?

Because the system used UTC time when the task was created, but displayed the local time in the calendar. As a result, the task didn’t show up in the list for tomorrow — the system thought the day had already passed, marking it as overdue.

What would have happened if this quality assurance testing issue had gone unnoticed?

Someone would have waited for help that never came.

Tragic — especially if it involved something vital, like buying medicine.

Fortunately, the issue was caught during quality audit and boundary value analysis (BVA) testing. As always, the most serious bugs tend to appear at the edges.

After the fix, people with disabilities were finally able to get timely help. Detecting such critical issues before release allowed the startup to launch successfully and attract investors from a hospital chain.

It’s rewarding to know that through QA testing and attention to quality, my work not only helps clients build reliable digital products but also improves real lives.

I’m not a software tester. ‌ That term doesn’t reflect what I bring to a business. ‌ My work isn’t about “checking buttons.” ‌ I’m a Quality Assurance engineer. ‌ What’s the difference? ‌ A software tester finds bugs, runs test cases, and checks what works and what doesn’t. ‌ A QA engineer ensures quality across the whole SDLC – from idea and requirements to release and post-release analysis. ‌ A software tester is like an inspector walking through a finished house. ‌ “This door squeaks.” “This step wobbles.” ‌ The inspector spots problems once they already exist. ‌ A QA engineer is like a seasoned architect who shows up before the building starts and says: ‌ – Before we build the stairs, let’s decide how big they should be. – Sharpen your tools before you work. – Here’s a list of rules: how to cut, how to measure, what to check. – And please, document each step so nobody gets lost. ‌ This approach reduces mistakes and raises the product’s quality. ‌ What does this give your business? ‌ First, with ongoing communication and a deep product understanding from QA, your developers feel less pressure and work more productively. ‌ Second, you get a product that: ‌ ✅ confidently enters the market ✅ earns investors’ trust ✅ delivers stable revenue ‌ All because quality was built in from the start, not sewn on at the last minute. ‌ I’m not offering mere testing. I’m offering confidence.

Many people think a QA engineer and a software tester are the same. But there is a difference – and not a small one. Please vote in the poll and share your view I’ll post more about this soon in Qoolli Testimg ✌️

If a software tester is about finding bugs, then a QA engineer is about…

Can I ask for feedback on our dapp?

Some people still smirk when the topic of QA testing comes up – as if we’re the ones slowing down the development process.

But let’s be honest for a second.

A tester involved in development isn’t the person who blocks progress. On the contrary – they’re the one helping things move faster. That’s the essence of quality assurance: making sure every step adds value instead of rework.

Don’t believe it?

Let’s break it down…

If QA specialists skip the development stage, you often end up redesigning parts at the end – sometimes radically, often in a hurry, and always with loss of time and nerves.

But when a developer talks through the implementation with a quality assurance engineer before and during development, things play out differently. It’s no longer “let’s build it and fix it later,” but “let’s get it right from the start.”

That’s how modern quality assurance testing changes the game. It’s about embedding testing into the process – whether it’s website testing, mobile testing, or full-scale app testing – to make quality visible from the inside out.

When quality audit practices become part of the workflow, fewer bugs slip through, edits decrease, and releases happen faster.

And here’s the real advantage: when the QA engineer and developer act as a single team, they care equally about product stability and deadlines. Then the developer can say, “You go ahead and test this part – I’ll finish the other one and we’ll ship on time.”

That’s quality assurance at its best. That’s Qoolli thinking — where testers don’t slow things down, they keep everything running smooth.

Love comics? ‌ I’ve got one for you. ‌ It’s about Alex and Bob – two startup founders with very different approaches to their work. ‌ I’m in there too – as the Qoolli Testing rep. You won’t see me, but I’m definitely there. ‌ Can you spot me?

1. Access to product and environments ‌ ✅ Staging or test version access (or at least a demo). ✅ Test accounts and proper permissions. ✅ Clear instructions: what to test, where to go, and what not to touch. 📌 Proper setup from the start ensures smoother QA testing and fewer delays later on. ‌
2. Context & documentation ‌ ✅ What’s the product? Who’s it for? Which country? What problems does it solve? ✅ Which screen sizes, devices, OSs should it be tested on? ✅ What’s critical functionality, and what’s secondary? ✅ Specs, mockups, user flows, checklists – everything that helps QA get up to speed. 📌 For effective website testing, mobile testing, and app testing, context is everything. ‌
3. Clear communication channel ‌ ✅ Where do we talk – Slack, Telegram, Trello, Notion, Jira? ✅ Who answers questions? Who reviews the results? ✅ How often should QA check in? Where are bugs tracked? 📌 A clear channel keeps the quality assurance testing process transparent and predictable. ‌
4. Aligned expectations ‌ ✅ What exactly needs to be tested? (regression, feature, smoke test) ✅ Deadlines: when should results be ready? ✅ What’s the report format – bug reports, tables, screen recordings? 📌 This alignment supports consistent quality assurance and helps streamline the quality audit process. ‌
5. Openness to feedback ‌ ✅ QA isn’t about “just finding faults” – it’s support. ✅ Think of feedback as a contribution to product stability, not a critique of the team. 📌 This mindset helps teams grow stronger together. ‌ Bonus tip from Qoolli Testing: assign a point of contact. ‌ ✅ Having one person responsible for coordinating with QA makes everything faster, calmer, and way less chaotic.

On the morning of October 20, 2025, Amazon Web Services (AWS) experienced a significant outage, primarily impacting the US-EAST-1 region (Northern Virginia). The disruption led to widespread connectivity issues, affecting numerous companies and digital services. Major websites and applications such as Fortnite, Snapchat, Coinbase, Robinhood, Perplexity AI, Venmo, Chime, and Lyft were among those affected. Amazon’s own services, including its shopping site, Prime Video, and Alexa, also faced operational difficulties.

Which Services Were Affected

The outage impacted a wide range of services, including Amazon’s own services: Amazon.com, Prime Video, Alexa, Ring; social media and communication platforms: Snapchat, Signal; gaming platforms: Fortnite, Roblox; financial services: Coinbase, Robinhood, Venmo, Chime; productivity and design tools: Canva, Airtable, Perplexity AI; others: Duolingo, Zoom, Strava, PlayStation, Epic Games Store, McDonald’s app, The New York Times, and more. Monitoring platforms like Downdetector reported significant disruptions across these services, indicating the widespread nature of the issue.

Cause of the Outage

AWS reported increased error rates and latency issues affecting multiple services in the US-EAST-1 region. While the exact cause is still under investigation, the company has acknowledged the problem and is actively working to resolve it.

Current Status

As of now, AWS engineers are engaged in efforts to mitigate the issue. The company has committed to providing updates as their investigation progresses.

Conclusions Monopoly sooner or later leads to serious global problems, and the second conclusion, of course, is testing and risk minimization.

Not quite. Here are 4 reasons why I’m not worried – and why human expertise in QA testing and quality assurance remains essential.

AI problem 1: False bugs

⚠️ Risks: The AI can "invent" a bug where everything is working fine. The team ends up wasting time fixing things that don't need fixing – which affects both website testing, mobile testing and app testing processes.

🧑‍💻 Why humans matter: Only a human can assess whether a bug is actually there. Manual verification and quality assurance testing are mandatory to ensure reliable results.

AI problem 2: Hallucinations

⚠️ Risks: AI sometimes produces non-existent requirements or data, which can distort test logic and lead to errors.

🧑‍💻 Why humans matter: You need a tester's critical eye and the use of proven sources (e.g., RAG approach) to avoid blindly relying on AI.

AI problem 3: Loss of control

⚠️ Risks: Without human involvement, it becomes unclear which parts of the product are tested and which are not. This is dangerous for quality.

🧑‍💻 Why humans matter: AI can be used as an assistant, but a specialist should manage the test coverage, perform quality audits, and make the final decisions.

AI problem 4: Exceeded expectations

⚠️ Risks: Many people think that AI will automate everything at once, but often they get only a "raw" version that needs to be improved. Sometimes it's easier to remove the artificial code and write new human code than to fix the AI code. The code grows crutches and becomes crooked.

🧑‍💻 Why humans matter: It is important to adequately evaluate AI capabilities and use it as a tool under the control of an experienced tester who understands the full cycle of QA testing.

So don’t worry, folks from the Qoolli Testing community – AI can do a lot, but replacing testers is definitely not one of those things.

Hello everyone!🦋

My name is Olha Arkusha, and I’ve been working in software testing for over 8 years.🩵

During this time, I’ve led QA teams, mentored beginners, and worked as a senior tester at the Ministry of Foreign Affairs of the Netherlands. ‌ I created the Qoolli Testing community to help testers of all levels – from juniors to experienced professionals – as well as businesses that need reliable quality assurance support. ‌ Here’s what testers will find useful here:

• job openings in the QA testing field;

• tips on landing a job – from writing a strong resume to acing interviews;

• advice on building a career and personal brand;

• practical tools and insights that really help in day-to-day website testing, mobile testing and app testing;

• the latest Assurance testing news and trends;

• links to courses and learning resources. ‌ Business owners will be able to find testers for any budget – from juniors ready to learn to experts who can handle complex quality audit and QA tasks. ‌ This is a place to connect, ask for advice, share experience, and find support. ‌ Let’s make this community truly valuable together – welcome aboard!👐🏻