Библиотека тестировщика

🚀❓ Играете в игры, но хотите зарабатывать на их тестировании? Тогда это ваш шанс! На открытом вебинаре «Инструменты для тестирования игр» вы узнаете, как стать экспертом Game QA и превратить хобби в карьеру.

Что обсудим:
- Какие инструменты нужны для тестирования игр и зачем.
- Как работать с документацией, замерять производительность и автоматизировать рутину.
- Как собрать идеальный инструментарий для эффективной работы.
- Как использовать AI для ускорения тестирования.

⭐️ Спикер Никита Шаченко — QA Automation Engineer в Redhill Games.
Курс «Game QA Engineer» стартует совсем скоро, а все участники открытого урока получат скидку на обучение.

👉 Записывайтесь прямо сейчас: https://vk.cc/cJlmi0

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

1.06K views07:05

🔥 10 Полезных SQL-запросов для Тестировщика

Привет, коллеги! Сегодня хочу поделиться подборкой SQL-запросов, которые спасали меня не раз при тестировании. Если вы работаете с базами данных, то этот список точно пригодится!

📌 1. Проверить количество записей в таблице:


SELECT COUNT(*) FROM users;

Когда нужно убедиться, что в таблице появилось нужное количество записей после теста.

📌 2. Найти дубликаты в таблице:


SELECT email, COUNT(*) 
FROM users 
GROUP BY email 
HAVING COUNT(*) > 1;

Полезно, если проверяете уникальность данных.

📌 3. Вывести последние 10 записей:


SELECT * FROM orders ORDER BY created_at DESC LIMIT 10;

Отличный способ проверить свежие данные.

📌 4. Проверить, есть ли в таблице определённая запись:


SELECT * FROM users WHERE email = '[email protected]';

Помогает быстро найти тестовые данные.

📌 5. Обновить данные в таблице (осторожно!):


UPDATE users SET status = 'active' WHERE status = 'pending';

Используйте на тестовых базах!

📌 6. Удалить записи по условию (ещё осторожнее!):


DELETE FROM users WHERE created_at < '2024-01-01';

Перед выполнением лучше сделать SELECT, чтобы убедиться, что удалите именно то, что нужно.

📌 7. Соединение двух таблиц (JOIN):


SELECT u.name, o.total 
FROM users u 
JOIN orders o ON u.id = o.user_id;

Когда тестируете связь между пользователями и их заказами.

📌 8. Найти записи, содержащие слово:


SELECT * FROM products WHERE name LIKE '%apple%';

Пригодится для проверки поиска в базе.

📌 9. Посчитать среднюю сумму заказов:


SELECT AVG(total) FROM orders;

Когда нужно проверить расчёты в отчётах.

📌 10. Найти пользователей, которые не сделали заказ:


SELECT * FROM users 
WHERE id NOT IN (SELECT user_id FROM orders);

Для анализа пользователей без активности.

Попробуйте эти запросы в деле и напишите, какие из них вам пригодились или какие ещё вы используете в тестировании! 👇

#qa #testing

Подпишись👉 @testlab_qa

👍9

1.39K views12:08

Библиотека тестировщика

#qa #testing

Подпишись👉 @testlab_qa

😁13❤2

1.12K views11:43

Библиотека тестировщика

🛠️ Как тестировщику доказать баг?

Бывало такое, что ты нашел баг, но разработчик говорит: "Это не баг, а фича", или "Не могу воспроизвести, у меня все работает"? Сегодня разберем, как аргументированно доказать существование бага и избежать холиваров с разработчиками.

✅ 1. Четкая и полная баг-репортация
Хороший баг-репорт — 90% успеха. Опиши:
- Ожидаемый результат: Как система должна работать.
- Фактический результат: Как работает на самом деле.
- Шаги воспроизведения: Детальный сценарий с примерами.
- Среда тестирования: ОС, браузер, версия ПО, устройство и т. д.
- Лог-файлы, скриншоты, видео: Визуальное подтверждение бага.

✅ 2. Доказательство на данных
Если баг связан с логикой работы системы, можно показать несоответствия в базе данных, логах или API-запросах. Например, разница между сохраненными и отображаемыми данными.

✅ 3. Использование аналогий
Некоторые баги сложно объяснить словами. В таком случае помогают аналогии:
"Представь, ты заказал кофе, а тебе принесли чай. Вроде тоже напиток, но явно не то, что ожидалось."

✅ 4. Повторное тестирование на разных окружениях
Если разработчик говорит "У меня работает", попробуй:
- Разные браузеры и версии.
- Другое устройство/операционную систему.
- Включение/отключение кэша.
- Использование другого тестового аккаунта.

✅ 5. Сообщение о критичности
Не все баги одинаково важны. Покажи влияние бага:
- Нарушение функциональности?
- Угроза безопасности?
- Блокировка работы пользователя?

👉 Если разработчик все равно не соглашается — можно привлечь тимлида, аналитика или другого QA, чтобы обсудить баг с разных точек зрения.

Как ты доказываешь баги? Поделись в комментариях! 👇

#qa #testing

Подпишись👉 @testlab_qa

👍3❤1🔥1

1.1K views12:03

Библиотека тестировщика

Подборка Telegram каналов для программистов

https://t.iss.one/bash_srv Bash Советы
https://t.iss.one/win_sysadmin Системный Администратор Windows
https://t.iss.one/lifeproger Жизнь программиста. Авторский канал.
https://t.iss.one/devopslib Библиотека девопса | DevOps, SRE, Sysadmin
https://t.iss.one/rabota1C_rus Вакансии для программистов 1С

Системное администрирование 📌
https://t.iss.one/sysadmin_girl Девочка Сисадмин
https://t.iss.one/srv_admin_linux Админские угодья
https://t.iss.one/linux_srv Типичный Сисадмин

https://t.iss.one/linux_odmin Linux: Системный администратор
https://t.iss.one/devops_star DevOps Star (Звезда Девопса)
https://t.iss.one/i_linux Системный администратор
https://t.iss.one/linuxchmod Linux
https://t.iss.one/sys_adminos Системный Администратор
https://t.iss.one/tipsysdmin Типичный Сисадмин (фото железа, было/стало)
https://t.iss.one/sysadminof Книги для админов, полезные материалы
https://t.iss.one/i_odmin Все для системного администратора
https://t.iss.one/i_odmin_book Библиотека Системного Администратора
https://t.iss.one/i_odmin_chat Чат системных администраторов
https://t.iss.one/i_DevOps DevOps: Пишем о Docker, Kubernetes и др.
https://t.iss.one/sysadminoff Новости Линукс Linux

1C разработка 📌
https://t.iss.one/odin1C_rus Cтатьи, курсы, советы, шаблоны кода 1С
https://t.iss.one/DevLab1C 1С:Предприятие 8

Программирование C++📌
https://t.iss.one/cpp_lib Библиотека C/C++ разработчика
https://t.iss.one/cpp_knigi Книги для программистов C/C++
https://t.iss.one/cpp_geek Учим C/C++ на примерах

Программирование Python 📌
https://t.iss.one/pythonofff Python академия. Учи Python быстро и легко🐍
https://t.iss.one/BookPython Библиотека Python разработчика
https://t.iss.one/python_real Python подборки на русском и английском
https://t.iss.one/python_360 Книги по Python Rus

Java разработка 📌
https://t.iss.one/BookJava Библиотека Java разработчика
https://t.iss.one/java_360 Книги по Java Rus
https://t.iss.one/java_geek Учим Java на примерах

GitHub Сообщество 📌
https://t.iss.one/Githublib Интересное из GitHub

Базы данных (Data Base) 📌
https://t.iss.one/database_info Все про базы данных

Мобильная разработка: iOS, Android 📌
https://t.iss.one/developer_mobila Мобильная разработка
https://t.iss.one/kotlin_lib Подборки полезного материала по Kotlin

Фронтенд разработка 📌
https://t.iss.one/frontend_1 Подборки для frontend разработчиков
https://t.iss.one/frontend_sovet Frontend советы, примеры и практика!
https://t.iss.one/React_lib Подборки по React js и все что с ним связано

Разработка игр 📌
https://t.iss.one/game_devv Все о разработке игр

Библиотеки 📌
https://t.iss.one/book_for_dev Книги для программистов Rus
https://t.iss.one/programmist_of Книги по программированию
https://t.iss.one/proglb Библиотека программиста
https://t.iss.one/bfbook Книги для программистов
https://t.iss.one/books_reserv Книги для программистов

БигДата, машинное обучение 📌
https://t.iss.one/bigdata_1 Data Science, Big Data, Machine Learning, Deep Learning

Программирование 📌
https://t.iss.one/bookflow Лекции, видеоуроки, доклады с IT конференций
https://t.iss.one/coddy_academy Полезные советы по программированию
https://t.iss.one/rust_lib Полезный контент по программированию на Rust
https://t.iss.one/golang_lib Библиотека Go (Golang) разработчика
https://t.iss.one/itmozg Программисты, дизайнеры, новости из мира IT
https://t.iss.one/php_lib Библиотека PHP программиста 👨🏼‍💻👩‍💻
https://t.iss.one/nodejs_lib Подборки по Node js и все что с ним связано
https://t.iss.one/ruby_lib Библиотека Ruby программиста

QA, тестирование 📌
https://t.iss.one/testlab_qa Библиотека тестировщика

Шутки программистов 📌
https://t.iss.one/itumor Шутки программистов

Защита, взлом, безопасность 📌
https://t.iss.one/thehaking Канал о кибербезопасности
https://t.iss.one/xakep_2 Хакер Free

Книги, статьи для дизайнеров 📌
https://t.iss.one/ux_web Статьи, книги для дизайнеров

Математика 📌
https://t.iss.one/Pomatematike Канал по математике
https://t.iss.one/phis_mat Обучающие видео, книги по Физике и Математике

Excel лайфхак📌
https://t.iss.one/Excel_lifehack

https://t.iss.one/tikon_1 Новости высоких технологий, науки и техники💡
https://t.iss.one/mir_teh Мир технологий (Technology World)

Вакансии 📌
https://t.iss.one/sysadmin_rabota Системный Администратор
https://t.iss.one/progjob Вакансии в IT

Bash Советы

🚀 Секреты и советы по Bash

🔹 Полезные трюки, хитрые однострочники и лайфхаки для работы в терминале.
🔹 Автоматизация, скрипты и оптимизация работы в Linux.
🔹 Стать мастером Bash легко – просто подпишись!

По всем вопросам @evgenycarter

1.03K views15:32

Библиотека тестировщика

Как убедиться, что баг исправлен?

Сегодня поговорим о важной теме – как правильно проверять баг после его исправления. Часто разработчик говорит: "Исправил, проверяй!", и тут важно не просто кликнуть на кнопку, а провести грамотную регрессию.

🔍 Как правильно проверять исправленный баг?

1️⃣ Проверяем, что баг действительно исправлен.
– Берём шаги воспроизведения из бага.
– Повторяем их в той же среде и на той же версии, где было исправление.
– Сравниваем результат с ожидаемым поведением.

2️⃣ Проверяем окрестности бага.
– Часто фиксы ломают соседний функционал. Например, исправили баг в авторизации – проверьте регистрацию, сброс пароля.

3️⃣ Проверяем на разных данных.
– Если баг связан с вводом данных, попробуйте крайние случаи: длинные строки, спецсимволы, пустые значения.

4️⃣ Тестируем в разных окружениях.
– Проверьте на разных браузерах, устройствах, API-запросах (если актуально).

5️⃣ Смотрим логи и консоль.
– Иногда баг "ушёл в тень" – UI работает, но в логах ошибки. Проверьте DevTools или серверные логи.

6️⃣ Запускаем регрессию.
– Если баг был в сложном сценарии, стоит перепройти весь сценарий целиком.

7️⃣ Оцениваем влияние на производительность.
– Если был сложный рефакторинг, проверьте, не замедлился ли интерфейс или API.

💡 Совет: Важно не просто убедиться, что баг "пропал", но и что он не привёл к новым проблемам.

Как вы проверяете баги после фикса? Делитесь своими лайфхаками в комментариях! 👇

#qa #testing

Подпишись👉 @testlab_qa

👍3

1.16K views12:31

Библиотека тестировщика

#qa #testing

Подпишись👉 @testlab_qa

😁18🤣2

992 views10:59

Библиотека тестировщика

Автоматизация тестирования, которая не ломается при первом редизайне

Меня зовут Артем, я эксперт по тестированию в компании TData — разработчике высоконагруженных корпоративных решений для работы с данными в реальном времени. Мы создаём ПО, где особенно важны стабильность, отказоустойчивость и предсказуемость поведения — вне зависимости от нагрузки и сложности сценариев.

Автоматизация тестирования для нас — не просто способ снять нагрузку с ручных тестировщиков, а часть инженерной культуры. В этой статье поделюсь тем, как мы выстраивали автоматизацию: с чего начали, почему стартовали с UI, какие инструменты прижились, как справлялись с нестабильными тестами. Давайте разберёмся, как не заблудиться на этом увлекательном, но местами запутанном пути.

https://habr.com/ru/companies/rostelecom/articles/894074/

#qa #testing

Подпишись👉 @testlab_qa

👍2

953 views05:02

Библиотека тестировщика

Как избавиться от нестабильных тестов и ускорить развертывание?

Приглашаем на открытый урок «Оптимизация CI/CD для мобильных тестов на Kotlin»

Настроим CI/CD для мобильных тестов на Kotlin: работа с GitHub Actions/GitLab CI, эмуляторами и реальными устройствами.

Разберем причины флейковых тестов в Android-тестировании: тайминги, нестабильные UI-элементы, инфраструктурные ограничения.

Рассмотрим методы ускорения и инструменты для стабильности и отчетности: Espresso, UIAutomator, Firebase Test Lab, Allure.

✅ Практика: Настроим CI/CD пайплайн для запуска тестов на Android-устройствах и эмуляторах.

👉 Регистрация на урок: https://vk.cc/cKf50g

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

825 views06:32

Библиотека тестировщика

0:11

This media is not supported in your browser

VIEW IN TELEGRAM

#qa #testing

Подпишись👉 @testlab_qa

🤣12

945 views12:06

Библиотека тестировщика

Сегодня хочу напомнить об одной неочевидной ловушке при проверке багфикса.

Допустим, разработчик починил баг, вы повторили шаги — баг не воспроизводится. Всё, можно закрывать?

❌ Нет. Это ошибка новичка.

✅ Проверка багфикса — это не только “воспроизводится/не воспроизводится”.
Нужно всегда делать микро-регрессию вокруг бага. Почему?

Пример из практики:
*Баг — не сохраняется поле "email" при редактировании профиля.*
После фикса вы проверили — теперь email сохраняется. Но из-за изменения логики перестало сохраняться имя. 🤦‍♂️

🔁 Что делать правильно:

1. Проверить сам баг по шагам
2. Проверить смежные поля, действия, модули
3. Заглянуть в логи (если можете)
4. Задать себе вопрос: “Мог ли фикс задеть что-то ещё?”

Такой подход выделяет сильного тестировщика.
Будь не просто “проверяющим баги”, а гарантом стабильности 💪

А ты делаешь мини-регрессию после фикса или ограничиваешься проверкой одного сценария?

#qa #testing

Подпишись👉 @testlab_qa

👍6💯1

924 views12:16

Библиотека тестировщика

Bash Советы

1.09K views14:29

Библиотека тестировщика

🔁 Как убедиться, что баг пофикшен?

Привет, коллеги! Сегодня поделюсь одной из простых, но часто игнорируемых практик: как правильно проверять, что баг действительно исправлен.

Многие ограничиваются просто: ну, теперь вроде работает, — и закрывают баг. Но это путь к регрессии.

Вот мой чеклист, который я использую после того, как разработчик говорит: готово, можно проверять:

1. Повторить шаги воспроизведения из описания бага.
Если баг воспроизводился при специфическом сценарии — проверь именно его.

2. Проверить рядом стоящий функционал.
Часто правка одной части кода влияет на соседние участки. Потрать 2–3 минуты на мини-ревизию.

3. Проверить, что баг действительно был.
Если ты не был автором бага — воспроизведи его на предыдущей версии (например, на staging-е или через старую сборку). Так ты точно знаешь, что баг не магическим образом исчез.

4. Погоняй автотесты.
Если есть автотесты — запусти регрессию хотя бы частично. Особенно, если баг был в критичном месте.

5. Коммуникация с разработчиком.
Не бойся задать уточняющие вопросы: что именно поменяли? или может ли это повлиять на X?. Это не придирки — это твоя работа.

Если ты внедришь эту практику — количество возвращающихся багов в спринте ощутимо уменьшится.

#qa #testing

Подпишись👉 @testlab_qa

👍6

1.14K views04:03

Библиотека тестировщика

0:07

This media is not supported in your browser

VIEW IN TELEGRAM

😀

#qa #testing

Подпишись👉 @testlab_qa

😁9

1.02K views06:34

Библиотека тестировщика

✅Зачем нужно контрактное тестирование в Kotlin QA и как гарантировать, что фронтенд и бэкенд понимают друг друга?

Приглашаем вас на открытый урок курса «Kotlin QA Engineer» от Otus, где рассмотрим инструменты для контрактного тестирования на Kotlin: Pact, Spring Cloud Contract и их отличие от интеграционных тестов.

Разберемся, как Kotlin QA-инженеры могут использовать Pact для тестирования API взаимодействия между сервисами.

Проведем интеграцию контрактных тестов на Kotlin в CI/CD

Обсудим best practices для Kotlin QA и разберем кейсы

Регистрация и подробности: 👇
https://vk.cc/cKBaKi

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

👍1

1.01K views08:20

Библиотека тестировщика

🔍 Что спрашивать на собеседовании QA'шнику: мой топ-5 вопросов

Сегодня покажу вам свои любимые вопросы, которые я задаю кандидатам на позицию тестировщика. Эти вопросы помогают быстро понять уровень человека — как технический, так и общий подход к работе.

1. Что ты будешь делать, если продакшн упал, а разработчика нет на месте?
Смотрю на реакцию: паникует или предлагает конкретные действия (логи, откат, алерты).

2. Как ты определяешь, что баг действительно критичный?
Тут важно мышление. Вижу ли я понимание бизнес-приоритетов или просто «красный экран = P0»?

3. Опиши самый сложный баг, который ты ловил. Как нашёл?
Оцениваю глубину анализа и навыки коммуникации — баг же надо не только найти, но и донести.

4. Как ты тестируешь без документации?
Умеет ли кандидат работать с продуктом «руками», искать баги через исследование?

5. Когда автоматизация вредна?
Идея — узнать, понимает ли, где ROI автоматизации низкий и когда ручное тестирование выгоднее.

Эти вопросы — не про запугать. Они про реальный опыт и зрелость. Часто кандидат сам раскрывается намного лучше, чем при стандартных вопросах вроде «что такое баг-репорт».

А какие вопросы вы задаёте/встречали на собеседованиях? Делитесь в комментариях — соберём народный список!

#qa #testing

Подпишись👉 @testlab_qa

👍9❤2

1.13K views05:59

Библиотека тестировщика

🎯 Что делать, если баг не воспроизводится у разработчика?

Привет, коллеги! Сегодня расскажу о ситуации, которая случается, пожалуй, с каждым тестировщиком: вы находите баг, всё четко описали, приложили скрины и логи, но… разработчик пишет: «У меня не воспроизводится». Что делать?

Вот мой чеклист, который помогает не устраивать битву QA против Dev:

1. Проверить окружение.
Одна из частых причин — разные сборки, версии браузера или мобильной ОС. Уточните, на чём тестили, и сравните с тем, что использует разработчик.

2. Уточнить данные.
Некоторые баги проявляются только при определённом пользователе, ролях или специфическом наборе данных. Проверьте: может быть, баг связан с конкретной записью или конфигурацией.

3. Пошаговая инструкция.
Иногда важен порядок действий. Убедитесь, что шаги в баг-репорте полностью воспроизводят ваш путь — вплоть до конкретной кнопки, на которую вы нажимали.

4. Добавить видео.
Скриншоты — хорошо, но короткое видео с багом часто снимает все вопросы. Особенно если баг нестабильный.

5. Проверка логов.
Даже если баг не виден, он может оставить след в логах. Приложите записи с уровнем error или warning.

6. Воспроизведение вместе.
Иногда проще устроить короткий Zoom/Teams и показать баг вживую. Часто это быстрее, чем переписка на 20 сообщений.

✨ И помните: мы не боремся с разработчиком, мы вместе боремся с багом. Сотрудничество — наше главное оружие.

Как вы обычно решаете такие ситуации? Делитесь в комментах!

#qa #testing

Подпишись👉 @testlab_qa

👍4👏1

913 views13:42

Библиотека тестировщика

0:36

This media is not supported in your browser

VIEW IN TELEGRAM

😀

#qa #testing

Подпишись👉 @testlab_qa

😁14💯4🤣3👏1

889 views07:46

Библиотека тестировщика

👨‍💻 Сегодня я покажу, как быстро проверить API без Postman и других инструментов

Обычно, когда тестировщики слышат «проверь API», рука сама тянется к Postman или Swagger. Но что если нужно быстро глянуть ответ эндпоинта, а под рукой — только терминал?

В таких случаях я использую curl. Вот пара примеров, которые спасают мне время:

🔹 GET-запрос:


curl -X GET "https://api.example.com/users" -H "Authorization: Bearer <токен>"

🔹 POST с телом запроса:


curl -X POST "https://api.example.com/login" \
-H "Content-Type: application/json" \
-d '{"username": "qa_user", "password": "123456"}'

🔹 Сохранить ответ в файл:


curl -o response.json "https://api.example.com/data"

⚡️ Почему это удобно?
- Не надо открывать интерфейс
- Работает даже на удалённых машинах (через ssh)
- Можно быстро включить в автотесты или скрипты

💬 А ты используешь curl в своей практике? Напиши, какие команды у тебя в закладках.

#qa #testing

Подпишись👉 @testlab_qa

👍5

846 views09:02

Библиотека тестировщика

🧪 Как Fiddler спасает нагрузочное тестирование

Если ты до сих пор записываешь скрипты в Recorder — пора прокачать инструментарий.
Fiddler — не просто альтернатива, а настоящий универсальный солдат в нагрузочном тестировании.

🔥22 апреля в 20:00 мск. приглашаем на бесплатный вебинар «Без Fiddler как без рук: как инструмент спасает нагрузочное тестирование».

Что разберём:
🔹 как Fiddler помогает отлаживать скрипты быстрее и надёжнее
🔹 как перехватывать трафик и работать с системами без прокси
🔹 как подменять пакеты, использовать заглушки и гибко настраивать среду

📌 В конце — бонус: шпаргалка по настройке Fiddler для твоих проектов

🔧 Полезно всем, кто хочет добавить в свои тесты больше контроля и меньше боли.

👉 Регистрируйся: https://vk.cc/cKTxPx

Занятие приурочено к старту курса “Нагрузочное тестирование”, на котором вы научитесь составлять методику, разрабатывать скрипты, запускать тесты и настраивать мониторинг нагрузочного тестирования.

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

834 views09:59

Библиотека тестировщика

🧪 Сегодня хочу поговорить о функциональном тестировании API.

Очень часто вижу, как ручные тестировщики не используют Postman/REST Client на максимум. А ведь с его помощью можно реально ускорить рутину.

Например, вместо того чтобы вручную дергать эндпоинты с одними и теми же параметрами — соберите коллекции, настройте переменные окружения, добавьте предусловия и пост-обработку. Да, немного времени на настройку — но потом просто нажимаете “Send” и смотрите результат.

📌 А если вы еще не используете тесты прямо в Postman, обязательно попробуйте:


pm.test("Статус 200", function () {
    pm.response.to.have.status(200);
});

Плюс, можно писать более сложную валидацию:


pm.test("Ответ содержит userId", function () {
    const jsonData = pm.response.json();
    pm.expect(jsonData).to.have.property("userId");
});

Прелесть в том, что это всё можно закоммитить в git и запускать через Newman, встроить в CI — и вы уже автоматизируете функциональное тестирование API. Пусть не на 100%, но шаг в эту сторону сделан.

Попробуйте и расскажите, как вы используете Postman — просто для ручных запросов или уже как полноценный инструмент для автотестов?

#qa #testing

Подпишись👉 @testlab_qa

❤5👍2

1.12K views08:51

About

Blog

Apps

Platform