One SQL topic especially useful for backend testing is subqueries.
A few patterns worth remembering:
🔹 IN (SELECT...) - dynamically filter records without manually copying IDs.
🔹 EXISTS - quickly check whether related data exists.
🔹 NOT EXISTS - find missing relationships. Very useful for spotting data inconsistencies.
🔹 WHERE value > (SELECT AVG(...)) - compare records against an overall value, such as an average.
The key takeaway: you don't need to memorize every syntax pattern. Think about what your main query needs and how another query can provide it.
For QA, this is especially useful when investigating API responses and checking what actually happened in the database.
How to Prioritize Test Cases When You Have No Time
You’ll never have enough time to test everything. The real skill is knowing what to test first.
When deadlines are tight, I use a simple risk-based approach:
🔹 Prioritize high-impact and high-risk areas
🔹 Check what actually changed in the release
🔹 Cover critical user journeys
🔹 Use automation to identify testing gaps
🔹 Focus on modules with a history of defects
🔹 Timebox testing to avoid getting stuck
🔹 Be transparent about what was and wasn’t tested
The goal isn’t to test less — it’s to make better testing decisions under constraints.
🚒 Production Failure Stories: How We Saved Production
“Production is down!” – the message no engineer ever wants to see. 😅
On August 27, join Mikhail Shtura (Tech Lead / Architect, Sam Solutions) for real production incidents, their root causes, and lessons learned — no theory, just practical cases.
🔥 A bot taking down a search service
⚡️ Why Redis Cluster doesn’t guarantee HA
👻 Where “ghost” services come from
📡 How workloads can overwhelm a cluster
🛠 Turning hotfixes into long-term solutions
🎯 For: Java Developers, Team Leads, Architects, SREs & anyone working with production systems.
⏰ 19:00 Minsk / 18:00 CEST | 🕒 1 hour
🗣 Russian | 📍 Offline: Andersen Minsk
💻 Online stream available after registration
Microservices change not only architecture, but also how we test.
A service can work perfectly on its own while the whole system is broken.
The biggest risks often appear at service boundaries: incompatible contracts, changed schemas, timeouts, retries, duplicated messages, and unexpected assumptions.
A balanced strategy looks like this:
🧪 Unit tests → business logic
🔌 Integration tests → realistic interactions
📜 Contract tests → service boundaries
🌐 E2E tests → critical user journeys
📊 Production validation → real-world behaviour
Don't make E2E tests responsible for everything. A few critical scenarios can provide more confidence than hundreds of fragile E2E tests.
The goal isn't to have the maximum number of tests.
It's to have the right tests answering the right questions at the right level.
👉 Read the full post on LinkedIn
What would you add to this testing strategy?