For about a year I tested a FinTech platform that customers could reach in three ways: a web client portal, a Telegram Mini App and a Telegram bot. Payments, billing and reports were the same underneath, but each channel showed them differently, and each one could break in its own way.
This is what I learned about testing that kind of product. It is not a complete guide to Telegram Mini Apps. It is the checklist I wish I had on day one.
Start from the API, not from the screens
All three channels talked to the same backend. That made the API the cheapest place to find most problems, and the first place I looked when something went wrong in any channel.
My daily tools were simple:
- Swagger / OpenAPI to see what each endpoint promised.
- Postman to call those endpoints directly, with the same requests the portal, the Mini App and the bot would send.
- DBeaver with SQL against PostgreSQL to check what actually landed in the database: invoices, ledger entries, exchange rates.
- Docker to run parts of the system locally.
- Browser DevTools to see what the front end really sent and received.
- Playwright for automated checks of the web flows.
A large share of the defects I reported came down to the same story: some API endpoints did not work correctly. Finding that at the API level saved a lot of time, because the channels shared one backend, so one broken endpoint could break the same feature in all three at once.
The Mini App is a web page, but not a normal one
A Telegram Mini App is a web application that opens inside Telegram. That sounds like ordinary web testing, and much of it is. A few things are different, and they are worth a line in every test plan:
- It runs inside Telegram's own browser view. The same page can behave differently in Telegram on iOS, Android, desktop and the web version. Test on more than one.
- The user is identified by Telegram. The app receives data from Telegram about who opened it, and the backend should verify it. It is worth checking what happens when the app is opened outside Telegram or with missing or old launch data.
- The screen is small and shared. Telegram's interface, the on-screen keyboard and the light or dark theme all change what the user sees.
- Debugging is harder. It is easiest to inspect the Mini App with DevTools in Telegram Desktop or Telegram Web, so reproduce problems there first when you can.
None of these is exotic, but each one is easy to forget if you only ever test the page in a normal browser.
The bot is a channel too
It is tempting to treat the bot as "just notifications". In a FinTech product, the bot message is often the first thing a customer reads about their money. If the message is wrong, the customer does not care that the portal is right.
The second big class of defects I remember was exactly here: bot messages that arrived incorrectly. I check bot messages for:
- the right amount, currency and status, matching what the portal and the database say;
- the right moment, so a message does not arrive before the operation it describes is finished;
- duplicates, when the same event is processed twice;
- formatting, so special characters in names or comments do not break the message.
Numbers must agree across channels
The third class of defects was the most expensive kind: statistics that were calculated incorrectly. A report total in one place did not match the sum of the operations behind it, or did not match the same figure shown somewhere else.
My rule became: for every important number, find every place it is shown, and check that they all agree. For a payment, that meant the portal, the Mini App, the bot message, the exported report and the database. When they disagreed, SQL against the database usually told me which one was wrong and why: a different rounding rule, a different period, or a record that was missing from one of the sources.
This habit later turned into an open-source tool I maintain, LogiParity, which compares the same records across an API, exports, UI tables and a database. But the habit works without any tool: pick one payment and follow it through every channel.
One regression suite for three channels
I built smoke and regression suites that covered all three channels, and they cut our regression time by about 40%. Automated API and reporting checks in GitLab CI/CD reduced manual testing further.
The idea I would recommend to anyone in the same situation is to describe each business flow once and then check every step of it in each channel: create a payment, see it in the portal, see it in the Mini App, receive the right bot message, see it in the report. Written this way, gaps are obvious. If a step has no check in one channel, it stands out immediately.
A short checklist
If you are about to test a product with a web portal, a Telegram Mini App and a bot, this is where I would start:
- Map every endpoint each channel uses, and test those endpoints directly first.
- Open the Mini App on at least two Telegram clients, in light and dark theme.
- Check what the backend does with missing or invalid Telegram launch data.
- Treat every bot message as a report: right amount, right status, right time, no duplicates.
- For every important number, compare all the places it appears, down to the database.
- Write regression scenarios once per business flow, then check each step in every channel.
Most bugs in a multi-channel product are not in any single channel. They are in the places where the channels are supposed to agree.
Written with AI assistance from my own notes and experience. The work described and the opinions are mine.
Top comments (0)