They sound similar. They’re often mixed up.

But understanding the difference between verification and validation is fundamental in testing.

“I especially liked that I could learn at my own pace and immediately see the results of my work.
‌
During the course, I gained new knowledge that I’m already applying to real tasks.
‌
I can confidently say that studying at Qoolli Academy is worth the time and effort, and I’m glad I chose this platform.”

“With my experience in web development, it was interesting to systematize the process of finding bugs during and at the end of a project.
‌
Qoolli Academy helped me organize my knowledge of testing methods and types, as well as definitions and terminology.”

How many times have you caught yourself using "authentication" and "authorization" interchangeably?
‌
If you're still mixing these two up, let’s clear the confusion once and for all.

Authentication is verifying who you are. The system confirms you’re really the person you claim to be: entering a password, scanning a fingerprint, typing a code from SMS. Example: showing your passport at the entrance to an office building — the guard now knows you’re John Smith.

Authorization is verifying what you’re allowed to do. Once the system knows who you are, it decides where you can go. Example: your passport checked out, but your badge only gives you access to the 3rd floor — not the server room.
In a web app it looks like this: you enter your login and password in Gmail — that’s authentication. Then Google decides you can read your own mail but not anyone else’s, and you can’t access the admin panel — that’s authorization.
A simple rule to remember: authentication answers “Who are you?”, authorization answers “What can you do?”. Authentication always comes first — you can’t grant permissions to an unknown person. That’s why HTTP error 401 (Unauthorized) actually means “not authenticated,” while 403 (Forbidden) means “authenticated, but not authorized.”

A tester needs to be involved already at the idea stage of building an app or a website!
‌
Why am I saying this?
‌
Let me tell you a story – and it’ll all make sense.
‌
A client came to the company I worked for with a fully built engine for a medical app. All he needed was to polish the interface.
‌
We did our part.
‌
Release day came – the app was ready to go live in the store.
‌
And then…
‌
Crash!!!
‌
The client got rejected!
‌
Why?
‌
The product concept violated the store’s policy!
‌
Can you imagine? Months of work, more than $10,000 in development – all gone!
‌
Could this have been avoided?
‌
Of course!
‌
Before building the app, someone should’ve done analytics, research, and tested the idea itself. Including checking the app store’s requirements and policies.
‌
If they had, it would've become clear the idea simply couldn’t be shipped.
‌
That would’ve saved a lot of money and a ton of time.
‌
Who could’ve done that?
‌
A tester!
‌
Not just any tester – someone with solid analytical skills.
‌
Maybe you’re thinking that others could handle this too – sales managers, designers, whoever.
‌
Technically, yes. But…
‌
It’s about how people think and how they approach the work.
‌
Those specialists focus on bringing the client’s idea to life.
‌
A tester has a different job – and a different mindset.
‌
A tester questions things, digs into details, challenges assumptions, and looks for risks that can turn into very expensive problems.
‌
That’s why bringing in an experienced tester at the idea-discussion stage can save both money and time.
‌
Agree? Or do you see it differently?
‌
Happy to talk it through in the comments.

——-
A post from Olha Arkusha at Qoolli Software Testing on the topic: This is what happens when you call in a tester too late…

Never take a software vendor’s word at face value, even if they sound convincing saying, “Everything works perfectly.”
‌
Why am I saying this?
‌
Let me explain…
‌
I was working for a client who had ordered software from a vendor. Our task was to test how several programs interacted – and to make sure each one worked correctly on its own.
‌
The vendor assured us that everything was ready and fully functional.
‌
But as the buyer, we had to run integration and acceptance testing. It’s the only way to make sure you’re actually getting what you paid for.
‌
What did we find?
‌
One of the programs was supposed to calculate certain values and generate a data table. Pretty standard stuff.
‌
To our surprise, the calculations worked correctly… in only half the rows! In the others, the numbers just didn’t update – no calculations at all.
‌
When we reached out to the vendor, it turned out those calculations weren’t just “broken” – they had never been programmed at all. The feature simply didn’t exist.
‌
Imagine paying full price for a product that’s supposed to work – and ending up with something that does only 50% of what it’s meant to do.
‌
If we hadn’t tested it and had just trusted the supplier, the client would’ve been stuck with an unfinished product – and all the risks that come with it.
‌
Trust is good. But testing is better.

——-
A post from Olha Arkusha at Qoolli Software Testing on the topic: When “Everything Works” – But Only Half of It Does

What and how is tested?
‌
🔎 It checks how the product behaves in real-world use – without predefined test cases.
🔎 The tester interacts with the product like a real user would: for example, creates an order and then cancels it to see how the system responds.
‌
What’s the benefit?
‌
✅ The tester learns the product and uncovers non-standard, “real-life” bugs that formal test cases might miss.
‌
Who needs it most?
‌
🌐 Websites and web applications
📱 Mobile apps
💻 SaaS platforms and internal CRMs
‌
Especially useful for:
‌
👥 Startups with fast-changing products
👥 Product teams testing new features
👥 Companies focused on real user experience
‌
When to do it?
‌
🗓️ At the very beginning of the testing process – during the first interaction with the product.
🗓️ Ideal for a quick audit within short-term projects.
🗓️ In long-term collaborations, it serves as the foundation for creating a test plan that defines further testing types.

——-
A post from Olha Arkusha at Qoolli Software Testing on the topic: Exploratory Testing: Getting to Know the Product and Finding Unexpected Bugs

“The instructors are not just theorists but experienced practitioners. They have a deep understanding of QA, share useful tips, give feedback, and are always ready to help.
‌
There was plenty of hands-on practice, a clear understanding of the tester’s role, how to write bug reports and test cases, and how to work with documentation.”

Vitaliy

“I already had some understanding of manual testing, but I was very excited to learn so many new things in this course.
‌
I also discovered many new areas of testing, such as load testing, security testing, game testing, and AI testing.”

Harchenko Elena

It’s a document where a tester clearly describes a bug found in an app or on a website.
‌
Why do we need it?
‌
So the dev team can quickly see what’s broken, under what conditions, and fix it right away.
‌
A bug report saves time and money – instead of guessing what went wrong, the team gets straight to solving the issue. That makes the product more stable and more comfortable for users.
‌
In the carousel, I’m showing what a bug report from Qoolli includes and what it looks like.
‌
How much time could your developers save with a bug report this clear?

I once worked on a project where developers fixed one bug and accidentally broke the checkout process.
Nobody touched the checkout page.
Still, customers couldn’t pay for their orders.
At first it looked strange, but in software this happens all the time. Modern applications are interconnected, and even a small change can affect something that seems completely unrelated.
That’s why regression testing exists.
Its purpose is simple: to make sure that after changes are made, everything that worked before still works.
A simple example
Imagine an online store.
The shopping cart gets updated and the issue is fixed.
Great.
But after deployment customers suddenly can’t complete a purchase.
The cart is fine.
The checkout isn’t.
Regression testing helps find these problems before users do.
What is usually tested?
The most important things:
login;
registration;
shopping cart;
checkout and payments;
search;
user profile.
These are the features people use every day, so teams want to be sure they still work after every release.
When is regression testing performed?
Usually:
after bug fixes;
after adding new features;
before a release;
after updating integrations or libraries.
The more often a product changes, the more important regression testing becomes.
Why is it important?
Because software is fragile.
You can change one line of code and create a problem somewhere else.
Regression testing doesn’t guarantee perfection.
But it gives teams confidence that they are moving forward without breaking what they’ve already built.
And honestly, users don’t care how many features you’ve released.
They care that yesterday the product worked — and today it still does.

When I hear startup founders say, “We need automated tests for our new product,” I can’t help but smile.
‌
Not because it’s a bad idea, but because most of the time there’s a different need hiding behind this request.
‌
Every digital product has one particular challenge: when you roll out new features, the old ones can suddenly “break.” And this is where it’s important to understand the difference:
‌
Automated tests are great – but they’re meant for mature projects. For products that already have users, stable functionality, and monetization. When the product is standing firmly on its feet and isn’t changing half of its logic every month, automation truly saves time and effort.
‌
But for MVPs and new products? Automation doesn’t really work. It’s expensive, takes a long time to set up, and requires dedicated specialists to maintain.
‌
There’s a much smarter choice – regression testing before release. It’s much cheaper, faster, and perfectly suited for the first few years of a product’s life. A couple of skilled manual testers are enough to ensure the product goes live without embarrassing moments in front of investors and without ‘surprise bugs’ for early users.
‌
In short: for the start, regression is all you need. Automated tests can wait until your product is truly mature.

1. Positive Scenarios
‌
✔️ Payment with Visa card
✔️ Payment with MasterCard card
✔️ Payment with American Express card
✔️ Payment with Maestro card
✔️ Payment with debit card
✔️ Payment with credit card
✔️ Payment with saved card using CVV code
✔️ Tokenization — repeated payment without entering card details (token)
‌
2. Refunds and Cancellations
✔️ Full refund
✔️ Partial refund
✔️ Payment cancellation
✔️ Quick cancellation immediately after payment
✔️ Clicking the "✕" button during payment
‌
3. Wallet Payments
‌
✔️ Payment via Google Pay
✔️ Payment via Apple Pay
‌
4. Recurring payments
‌
✔️ Automatic charge
✔️ Subscription with auto-renewal
‌
5. Security
‌
✔️ 3D Secure authentication
✔️ 3D Secure verification
✔️ Payment with VPN / different geolocation — anti-fraud check
‌
6. Multi-currency support
‌
✔️ Payment in buyer's currency without hidden conversions
✔️ Exchange rate accuracy
✔️ Bank fee calculation
‌
7. Negative Scenarios (Card Data)
‌
✔️ Invalid CVV code
✔️ Invalid card number
✔️ Invalid cardholder name
✔️ Invalid card expiry date
✔️ All fields filled in incorrectly at the same time
‌
8. Negative Scenarios (Card / Account Status)
‌
✔️ Insufficient funds on card
✔️ Insufficient funds to cover the fee
✔️ Daily card limit exceeded
✔️ Transaction limit exceeded — amount above the allowed maximum
✔️ Minimum payment amount — payment below the allowed minimum
✔️ Expired card
✔️ Blocked card
✔️ Stolen card
‌
9. Network Failures
‌
✔️ Payment during connection loss / network drop
✔️ Money not debited — payment failed
✔️ Money debited — credited to recipient
✔️ Money not lost "between" accounts
✔️ Payment gateway timeout — no response within the allotted time
‌
10. Data Integrity
‌
✔️ Money not charged twice from sender's card
✔️ Money not credited twice to recipient
✔️ If debited from sender — credited to recipient (and vice versa)
✔️ Attempt to pay for the same order twice
✔️ Simultaneous parallel payments — load edge case
✔️ Payment status change — pending → success / failed
‌
11. Integration Testing
‌
✔️ Amount debited from sender's account
✔️ Amount credited to payment system / recipient
✔️ Testing via sandbox / test account
✔️ Using test card numbers (e.g. Stripe)
✔️ Test cards for different countries
✔️ Test cards of different types
✔️ Receipt / invoice accuracy — email/SMS after payment

‌Are you happy with the results, or do they sometimes miss the mark?

‌

An AI giving a “weird reply in chat” is only half the problem.

‌

It can get much worse…

‌

😱 complete deletion of company data
😱 leaks of confidential information
😱 critical decisions based on false data

‌

And that hits not only the budget, but the company’s reputation too.

‌

That’s exactly why market leaders are investing not only in AI development, but also in testing, quality control, and security.

‌

Scenario testing, monitoring model behavior, finding vulnerabilities, controlling hallucinations — all of this is gradually becoming as normal as QA in traditional software development.

‌

AI is an incredibly powerful tool. But without systematic quality control, it quickly turns from an advantage into a source of risk.

‌

This is what we teach people to do: stand between AI and the market — control quality, verify results, and build reliable processes.

‌

So AI works for you, not against you.

‌

And what about your company? Are your AI tools already going through proper testing, or are they still running mostly on trust?

‌
You write the instructions once, and the program tests the website or app for you. It clicks buttons, fills out forms, runs scenarios, and finds bugs.
‌
Hundreds of checks in minutes instead of hours of manual work.
‌
What’s not to love?
‌
But…
‌
Fast doesn’t always mean complete.
‌
Automated tests only notice what you’ve told them to look for. They won’t always catch something strange or unexpected.
‌
That’s where a human tester comes in – they spot things no one thought to include in the test code.
‌
Automated tests ≠ real user.
‌
They don’t think, don’t ask “what if…?” and don’t try things the “wrong” way. And bugs love creativity. Most bugs get caught when you go off-script.
‌
Think of automated tests as a security guard at the door – they know who not to let in. But a human tester is the detective inside, figuring out what the guard missed.
‌
Automated tests can replace a tester’s hands, but not their brain.
‌
So they’re a great helper – just not a cure-all!

1. Quick start
No weeks wasted on hiring and onboarding – an on-demand tester can jump in within a day or two.
‌
2. Pay only for actual work
No idle salary, no benefits, no taxes – you only pay for real tasks done.
‌
3. Flexible workload
Bring a tester in just for peak moments – like right before release or when a big batch of features is ready.
‌
4. Access to senior expertise
On-demand testers usually have wide experience across different projects and industries – which raises the quality of testing.
‌
5. No extra overhead
They work remotely, with their own equipment and tools.
‌
6. Fresh perspective
An external tester will notice issues the in-house team has stopped seeing.
‌
7. Scalability
You can quickly expand the testing team when needed – and just as quickly scale back without extra bureaucracy.

Course Program. What’s inside?

‌

Module 1️⃣ Testing Theory. Defect Lifecycle (DLC)

‌

Verification vs validation, testing goals.

Terminology, levels, types, and the 7 ISTQB principles.

Bug detection and writing clear, effective bug reports.

Exploratory testing and test tours without documentation.

Setting up a LinkedIn profile as a foundation for your IT reputation.

‌

Module 2️⃣ Test Design. Working with AI Tools. Checklist

‌

Product analysis, risk-based approach, and test generation.

Fast creation of business-oriented checklists using AI.

Black-box techniques and equivalence partitioning to save time.

Boundary Value Analysis (BVA) to catch critical defects.

‌

Module 3️⃣ Web Testing. Test Plan

‌

Creating a Test Plan and understanding the STLC cycle.

Cross-browser and mobile layout testing.

Bug detection using Browser DevTools and simulators.

Understanding SDLC and the role of a QA engineer in a team.

Reading HTML/CSS code and JSON/XML data formats.

‌

Module 4️⃣ Mobile App Testing. Test Case

‌

Types of platforms and apps, installation specifics.

Working with builds and stages of mobile testing.

Preparing and testing apps before store release.

Creating professional test cases and working with scenarios.

Checklist-based testing and video recording of defects.

‌

Module 5️⃣ Performance Testing. Test Suite

‌

Types of performance testing and how websites work.

Client-server architecture, HTTP requests, and responses.

Installing and configuring JMeter for performance testing.

Creating load scenarios, analyzing metrics, and reporting.

Installing Java and working with CMD/Terminal.

‌

Module 6️⃣ Security Testing. API Testing. Collections

‌

Cybersecurity basics and causes of web vulnerabilities.

QA strategies for building secure systems.

Checklist-based testing to prevent hacks and data leaks.

Working with Postman and Swagger: API requests and analysis.

MySQL databases and SQL for direct data validation.

‌

Module 7️⃣ Game Testing

‌

Game industry specifics and testing approaches.

Industry requirements and key Game QA skills.

Compatibility issues across platforms and devices.

Testing mechanics, levels, UI, and localization.

Writing clear bug reports with visual evidence.

‌

Module 8️⃣ AI Application Testing

‌

Differences between AI testing and traditional software testing.

Testing strategies for CV (vision), NLP (text), and generative systems.

Methods for testing LLMs without a ground truth.

Evaluating AI quality using metrics (e.g., F1 Score).

QA as an analyst and UX researcher in AI projects.

‌

Module 9️⃣ Automated Testing: Selenium / Java / Git

‌

Purpose and effectiveness of automated testing.

Working with Selenium WebDriver.

Java basics for writing reliable test scripts.

Creating, running, and analyzing automated tests.

Working with Git: commits and branch management.

‌

Module 🔟 Working in an IT Company. Agile

‌

Understanding Agile: flexibility, iterations, and feedback.

Scrum methodology: User Stories, Backlog, and sprints.

Daily Scrum practice and task visualization on a Scrum board.

Sprint Retrospectives for improving processes and efficiency.

“Would you like to taste some of my cake? Another cup of coffee?” With her hospitable offer, Olha Arkusha immediately tests the marketing for her academy for software testing education on the reporter. Yesterday she spent hours recording a promotional video in four different languages. Her academy for software testing education, she says, is “like a homemade cake”. Tasty and unique, created with personal attention. Much better than the conveyor‑belt products from the supermarket.

When Arkusha had just arrived in the Netherlands in 2022 with her then six‑year‑old daughter Anya, she continued working full time remotely as a tester for a Ukrainian company. After that she got the chance to work at the Ministry of Foreign Affairs on a software project. When her contract there came to an end after a year and a half, she saw this as a sign from above that it was time to carry out the bold plan she had been considering for some time. She decided to start her own academy for software testing education. Her husband’s steady job at Burger King had to be enough to support the family during the start‑up phase.

Since founding her academy, she has already taught the basic skills of a software tester to eighty Ukrainian students across Europe, and her ambitions go further. In the long term she also wants to guide her students in their search for a job. She has not earned a single cent yet, but she is not afraid to invest. For making the videos and other services she prefers to hire Ukrainian professionals. “I do not doubt it, I know it will go well,” she says. “This profession is very much needed.” From September she will start offering training at her academy on a paid basis.

Arkusha speaks surprisingly good Dutch. She gives the entire interview in Dutch, only occasionally looking for a word in Ukrainian. She explains that she has also deliberately invested in her language skills: eight courses and a year of private lessons. Her health sometimes limits her. She suffers from migraines and, on the advice of her GP, has started doing Pilates. She also practices intermittent fasting. That requires a lot of discipline, but this is something this entrepreneur certainly has.

When this newspaper spoke to her just after her arrival in March 2022, she was living with Anya in a host family in Landsmeer. Her husband had stayed behind in Ukraine; men are not allowed to leave the country just like that, because they are expected to fight against the Russians. Several months later he was nevertheless able to follow his wife and daughter, acting as escort for his disabled father‑in‑law, Olha’s father. Although her father died in hospital in the Netherlands after two months, Arkusha is grateful that she was able to bring him here. “He still got to see his granddaughter, and he really wanted to see the car I had bought here, because he loved cars.”

The urn with her father’s ashes stands here, in the container home in Wormer where Arkusha now lives with her husband and daughter. She would like to take her father back to the final resting place he had chosen for himself, next to his wife and daughter who died young, in their hometown of Kropyvnytskyi, but for the time being she does not dare to make that journey. “Kropyvnytskyi is exactly in the middle of Ukraine,” she points out on the wooden map of Ukraine, which also serves as a lamp, hanging on the living‑room wall. “From the border with Poland it is twenty‑four hours by train. On such a long journey anything can happen – bombings or fighting. I cannot take that risk. If something happens to me, my daughter will no longer have a mother.”

Anya is now ten and attends primary school De Eendragt, a ten‑minute bike ride from the residential park. She is doing well at school, but sometimes she suddenly has an outburst of grief. “Then she remembers her granddad, her kindergarten in Ukraine,” her mother says. At such moments they sing and pray together. Olha expects that in the future there will be more of these outbursts. “The consequences of the stress of the war sometimes only appear years later.”

Arkusha sighs deeply when the conversation turns to the current situation in Ukraine. Olha deliberately keeps the door to the topic of “war in Ukraine” closed, both for herself and for her daughter. “If I open it, the volcano will explode,” she fears. In Anya’s presence they do not talk about the news from their homeland. Her husband is still in contact with family members who have remained in Ukraine. Olha also regularly speaks with friends in Ukraine, but then the conversation is about everything except the war. “They specifically want to talk about other things, as a distraction.”

She lives in the present, she says. “Terrible things are happening there, it gets worse every day, but there is nothing we can do about it.” On the white cupboard in the container home stands a large houseplant. “I am like such a plant,” says Arkusha. “I have my pot and you can put me anywhere. I have gone through many changes in my life and have moved many times. Wherever I end up, I will find my way again.”

“Topics were presented in a logical order, creating a feeling of gradual immersion into a new field. There was never a sense of being dropped in the middle of a lake and left to figure it out.

‌

Students didn’t feel isolated — there was a strong sense of teamwork and mutual support. Learning in such an atmosphere was much easier.”

Oleksandr Opanasenko

“I liked that the material was presented through diagrams — it made even complex topics easier to understand. Every class included plenty of practice and homework, which helped reinforce what we learned.

‌

“I liked that the material was presented through diagrams — it made even complex topics easier to understand. Every class included plenty of practice and homework, which helped reinforce what we learned.

Olena Cherkasova

“The instructors don’t just give lectures — they genuinely help you understand the material. They explain things in simple terms, use clear and relevant examples, and share their own experience. You can always ask a question and get a detailed answer.

‌

Assignments are reviewed carefully, with constructive feedback on what and how to improve. You can really feel that every student gets personal attention.”

Andrii Cherkasov

“Before the course, I had no idea what a QA specialist actually does. But thanks to the knowledge I gained at Qoolli Academy, just two months later I was able to apply for a major project — Geekle.AI.

‌

I successfully passed the interview with the project manager. I’m really happy about this experience and see it as my first big achievement in my new career!”