🚀 Подборка 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

😀

#qa #testing

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

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

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

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

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

Что делать:

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

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

#qa #testing

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

#qa #testing

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

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

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

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

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

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

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

#qa #testing

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

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

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

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

Как я делаю:

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

Плюс:

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

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

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

#qa #testing

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

#qa #testing

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

#qa #testing

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

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

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

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

В программе:

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

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

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

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

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

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

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

#qa #testing

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

👁️‍🗨️ Agile vs Waterfall

Всем привет! Давайте разберёмся, в чём разница между Agile (Scrum/Kanban) и Waterfall, и как это влияет на нашу работу.

🌊 Waterfall («Водопад»)
Как работает:
1. Этапы идут строго друг за другом (как вода в водопаде):
Требования → Дизайн → Разработка → Тестирование → Внедрение → Поддержка
2. Тестирование - в самом конце (когда весь продукт уже готов)

Плюсы для QA:
✔ Чёткий план (знаем все требования заранее)
✔ Участники проекта, не задействованные на определенной фазе, могут переключаться на другие проекты
✔ Подходит для госпроектов, систем, где нельзя менять требования и для модернизации уже существующих проектов

Минусы:
❌ Если баг найден поздно - исправлять дорого
❌ Нет гибкости

🔄 Agile (Scrum, Kanban)
Как работает:
1. Разбиваем проект на маленькие кусочки (итерации по 2-4 недели)
2. Тестируем каждую фичу сразу (не ждём конца разработки)

Scrum
- Есть спринты (обычно 2 недели)
- Каждый день daily (короткая ежедневная встреча команды разработки, которая проходит в одно и то же время. На ней каждый участник команды отвечает на вопросы «Что было сделано вчера? Что буду делать сегодня? Есть ли что-то, что может помешать работе над задачами спринта?»)
- Тестировщик встроен в команду (не отдельный «отдел»)

Kanban
- Нет спринтов - гибкий поток задач
- Задачи висят на доске, их прогресс наглядно виден по колонкам статусов (To do → In Progress…)

Плюсы для QA:
✔ Быстрая обратная связь
✔ Раннее вовлечение в процесс
✔ Постепенное тестирование

Минусы:
❌ Нужно быстро адаптироваться (требования могут меняться)
❌ Много рутины (ежедневные митинги, ретроспективы)

⚖️ Что лучше для тестировщика?

- Скорость: Waterfall - медленно, Agile - быстро
- Гибкость: Waterfall - нет, Agile - да
- Риски: Waterfall - баги находятся поздно, Agile - ловим баги в процессе разработки
- Документация: Waterfall - много, Agile - минимум

автор: Aleksandra Primako

#qa #testing

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

#qa #testing

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

Пилотное тестирование

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

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

https://artoftesting.com/pilot-testing

#qa #testing

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

#qa #testing

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

#qa #testing

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

🐳 Docker для тестировщиков

📚 Что такое Docker?
Docker - это платформа для контейнеризации приложений.
Контейнер - это легковесная виртуальная «коробка», куда упакованы:
- Код приложения
- Библиотеки
- Настройки окружения

В отличие от виртуальных машин, контейнеры не эмулируют всю ОС, а используют ядро хоста, что делает их быстрыми и компактными.

Аналогия:
- Виртуальная машина - это отдельная комната со своей мебелью, вещами. Если мы захотим порисовать, то нам может понадобиться что-то передвинуть, чтобы поставить мольберт, принести краски.
- Контейнер - этюдник, в котором находится уже все, что нам нужно, мы можем в любой момент его открыть и приступить к рисованию.

❓Зачем Docker тестировщику?
1. Идентичное окружение на всех этапа
Проблема:
«На моём ноуте тесты проходят, а на CI/CD падают!»
Решение:
Docker гарантирует, что тесты запускаются в одинаковой среде (версии Python/Java, БД)

2. Быстрый подъем инфраструктуры
Пример:
Вместо ручной установки PostgreSQL + Redis + Kafka:
docker-compose up -d

3. Тестирование в изоляции
- Можно запускать параллельные тесты в разных контейнерах
- Тесты не влияют на основную систему (например, не засоряют БД)

4. Эмуляция продакшена
- Тестирование на точной копии продакшен-окружения
- Проверка конфигов, переменных среды, сетевых правил

👁️ Ключевые концепции Docker
1. Образ (Image)
Шаблон для создания контейнеров

2. Контейнер
- Изолированная «коробка» с программой внутри (например, с вашим тестовым фреймворком или базой данных)
- Можно создать/остановить/удалить

3. Dockerfile
Инструкция для сборки образа

4. Docker Compose
Инструкция для управления несколькими сервисами (БД, кеш, API)

Почему Docker стоит освоить?
🔹 Стандартизация - больше никаких «на моей машине работает»
🔹 Экономия времени - окружение разворачивается за минуты
🔹 Гибкость - можно тестировать разные версии ПО

Docker - не панацея, но незаменимый помощник в арсенале современного тестировщика 🛠️

автор: Aleksandra Primako

#qa #testing

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

#qa #testing

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

#qa #testing

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

#qa #testing

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