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

#qa #testing

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

Новый сезон конференции Podlodka QA Crew пройдет с 1 по 5 сентября.

В фокусе — инструменты, которые делают тестирование быстрее, качественнее и удобнее.

В программе:

💡Как раскрыть потенциал Postman и ускорить обратную связь — вместе с Ариной Ладесовой (Payler).

🪄Внедрение ИИ для генерации тестов без лишней боли — с Натальей Петровской.

📱Современные инструменты мобильного тестировщика — практические кейсы от Елены Фёдоровой (Garage Eight).

🔍 Observability автотестов и мониторинг — с Кириллом Ивлиевым (Работа.ру).

Знания, которые легко применять в работе!

🔗 Подробности и регистрация по ссылке

P.S: Для подписчиков скидка 500 р по промокоду qa_crew_14_EV9xC0

SQL для тестировщиков: 5 полезных запросов

SQL - это язык для работы с реляционными базами данных (например, MySQL, PostgreSQL, Oracle). SQL является отличным инструментом для проверки целостности данных, анализа связей между таблицами и поиска скрытых багов.

1. Возвращаем набор данных из базы (SELECT)
Когда использовать: После регистрации, создания заказа и т.д. - проверяем, что пользователь/заказ создался, смотрим на корректность и полноту данных

Найти пользователя по email:
SELECT * (Выбираем все поля записи)
FROM users (Из таблицы users)
WHERE email = 'test@example.com'; (Где email равен указанному значению)

Проверить последний заказ:
SELECT * (Выбираем все поля записи)
FROM orders (Из таблицы orders)
ORDER BY created_at DESC (Сортируем по дате создания (новые сначала))
LIMIT 1; (Ограничиваем результат одной записью)

2. Фильтрация данных по условиям (WHERE)
Когда использовать: для поиска и анализа ошибочных записей, для выборочной проверки данных по определённым критериям

Найти неоплаченные заказы старше 3 дней:
SELECT * (Выбираем все поля заказов)
FROM orders (Из таблицы orders)
WHERE status = 'unpaid' (Где статус "неоплачен")
AND created_at < NOW() - INTERVAL 3 DAY; (И дата создания старше 3 дней от текущего момента)

Найти пользователей без подтвержденного email’a:
SELECT id, email (Выбираем только ID и email)
FROM users (Из таблицы users)
WHERE email_verified = false; (Где email не подтверждён)

3. Проверка количества записей (COUNT)
Когда использовать: для проверки массовых операций

Сколько пользователей зарегистрировалось сегодня:
SELECT COUNT(*) (Считаем общее количество записей)
FROM users (В таблице users)
WHERE DATE(created_at) = CURRENT_DATE; (Где дата регистрации = текущий день)

4. Обновление тестовых данных (UPDATE)
Важно! Используйте только в тестовых базах и всегда делайте резервную копию перед массовыми изменениями

Сбросить пароль тестового пользователя:
UPDATE users (Обновляем таблицу users)
SET password = 'test123' (Задаём новое значение для поля password)
WHERE email = 'test@example.com'; (Условие: только для пользователя с этим email)

Изменить статус заказа:
UPDATE orders (Обновляем таблицу orders)
SET status = 'completed' (Меняем статус на "completed")
WHERE id = 12345; (Условие: только заказ с ID 12345)

5. Удаление тестовых данных (DELETE)
Осторожно! Используйте только в тестовых базах и всегда делайте резервную копию перед массовыми изменениями. Всегда сначала делайте SELECT с тем же условием

Удаление тестовых заказов:
DELETE FROM orders (Удаляем записи из таблицы orders)
WHERE user_id IN ( (Где user_id соответствует…)
SELECT id FROM users (…ID из таблицы users)
WHERE email LIKE '%test%' (…для email с подстрокой "test»)
);

Как тренироваться?
На помощь приходят бесплатные тренажеры, например:

- https://sqlbolt.com/
- https://sqlzoo.net/

#qa #testing

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

#qa #testing

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

#qa #testing

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

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

Ситуация:
Проект огромный, релизы частые, тест-кейсов — сотни. Каждый регресс гонять вручную — невозможно, автоматизация есть, но покрывает не всё.

Решение — приоритизация тестов через "smoke + risk-based" подход.

Как я делаю:

1. Составляю smoke-набор — минимальный список тестов, который проверяет, что система вообще жива (логин, основные функции, критичные интеграции).
2. Выделяю модули с высоким риском изменений — туда иду с расширенным тестированием.
3. Использую свежий git log — смотрю, какие файлы менялись, и беру тесты, связанные с этими зонами.
4. Подключаю автоматизацию на всё, что уже покрыто автотестами, и вручную иду только в непокрытые части.

Плюс:

- Быстрее получаем обратную связь о состоянии системы.
- Меньше тратим время на очевидно стабильные зоны.
- Концентрируем усилия там, где вероятность бага максимальна.

Этот подход особенно полезен в стартапах или на проектах с частыми деплоями, где времени на полный регресс просто нет.

А вы в регрессе — бежите всё подряд или используете приоритизацию?

#qa #testing

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

Сегодня хочу рассказать про баги, которые «убегают» в прод, и почему это не всегда только вина тестировщика.

Очень часто вижу, как в компаниях после релиза, где вылез критичный баг, начинается «охота на ведьм». Виноват тестировщик — не нашёл, не проверил, недоглядел.
Но на практике баги попадают в прод по трём основным причинам:

1. Отсутствие чётких требований. Если спецификаций нет или они постоянно меняются, тестировщик проверяет «на глаз», а не по чётким критериям. Итог — разные ожидания у QA и у заказчика.
2. Сжатые сроки. Классика: дедлайн вчера, тестирование в два раза короче запланированного, при этом проверок меньше, автоматизация не прогоняется полностью.
3. Сложность воспроизведения. Есть баги, которые проявляются только при определённых нагрузках, конфигурациях или после долгой работы приложения. Их реально трудно найти до релиза.

Поэтому важно не искать виноватого, а разбирать причины:

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

А ещё полезно после каждого релиза проводить post-mortem — разбор инцидента без обвинений. Это помогает команде учиться, а не бояться.

#qa #testing

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

#qa #testing

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

Сегодня поговорим про "невидимые" баги, которые вылезают только в проде

Бывало ли у вас так: на тестовом стенде всё идеально, а в продакшене – краш за крашем? 🤯
Почему так происходит?

Мой топ причин:

1. Разная конфигурация окружений – на тесте одна версия базы или сервиса, на проде – другая.
2. Данные – тестовые данные “чистые”, а продовые – живые, с миллионом нюансов.
3. Нагрузка – под сотней пользователей система ведёт себя иначе, чем под тысячами.
4. Фича-флаги и конфиги – в тесте включено одно, в проде другое.

Что делать:

- Использовать продоподобные стенды – даже если это дорого.
- Делать smoke-тесты сразу после выката – ловить баги до того, как их увидят пользователи.
- Мониторинг + алерты – чтобы баги вас находили, а не наоборот.
- Chaos testing – симулировать нестандартные ситуации.

А как вы ловите такие баги? Может, есть свой лайфхак? Делитесь в комментах! 👇

#qa #testing

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

😀

#qa #testing

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

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

Системное администрирование, DevOps 📌

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

1C разработка 📌
https://t.me/odin1C_rus Cтатьи, курсы, советы, шаблоны кода 1С
https://t.me/DevLab1C 1С:Предприятие 8
https://t.me/razrab_1C 1C Разработчик
https://t.me/buh1C_prog 1C Программист | Бухгалтерия и Учёт
https://t.me/rabota1C_rus Вакансии для программистов 1С

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Математика 📌
https://t.me/Pomatematike Канал по математике
https://t.me/phis_mat Обучающие видео, книги по Физике и Математике
https://t.me/matgeoru Математика | Геометрия | Логика

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

https://t.me/mir_teh Мир технологий (Technology World)

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

Чит-листы:

- тестирования арі
- основных концепций тестирования
- эвристик при тестировании
- тестирования форм ввода
- планирования тестирования
- тестирования web-ui

#qa #testing

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

Apache Kafka - обзор

00:00 Apache Kafka - просто о сложном
00:09 Пример задачи обработки событий
05:02 Передача события http запросом
07:02 Передача события через очередь
08:15 Недостатки очередей
10:10 Брокеры сообщений
13:36 Распределенный журнал сообщений
15:35 Publisher-Subscriber
17:04 Масштабирование через партиции топика
18:35 Масштабирование группы консъюмеров
19:50 Позиции (смещения) записи и чтения партиций
20:42 Метаданные в Zookeeper
21:20 Распределение сообщений по партициям топика
25:35 Распределение партиций между консъюмерами
27:00 Принципы выбора ключа
29:34 Репликация
30:28 Чтение с произвольной позиции чтения
34:40 Сегменты и сжатие топиков
39:44 Репликация и размещение брокеров по стойкам
44:57 Теорема CAP
50:20 Теорема CAP в работе с Apache Kafka
58:26 At-least-once delivery

https://www.youtube.com/watch?v=jlNNgFfM58c

#qa #testing

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

😀

#qa #testing

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

Рутину — ИИ, исследование — людям: новая реальность Surf QA

Всего за пару недель мы создали инструмент, который превращает трудоёмкий процесс создания проверок в автоматизированный сценарий. Теперь, чтобы написать тесты, мы делаем всего несколько кликов.

Тест-документация рождается быстрее, а свободное время инженеры используют для исследовательских тестирований, погружения в продукт и проработки нефункциональных требований. И всё это вместо монотонного создания проверок по требованиям.

Вместе с Марией, техническим руководителем QA в Surf, расскажем, как сократили время создания проверок в 5 раз и не потеряли в качестве.

https://habr.com/ru/companies/surfstudio/articles/928254/

#qa #testing

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