TestGrow - software testing

Как у вас обстоят дела с документацией? Недавно с один учеником обсуждали тему того, что на проекте, который начинался как стартап, практически полностью отсутствует документация на проекте, причем это касается не только самих требований в формализованном виде, но и тест-кейсов или чек-листов. В целом если говорить про данную ситуацию, то с точки зрения менеджмента ситуация может быть двоякой, во-первых, отсутствие документации это не приговор, если команда эффективно работает без нее, регулярно из релиза в релиз поддерживает или повышает свою производительность, то возможно команды работает настролько слаженно с точки зрения коммуникации, что и без документации все получается отлично. Но такое если честно бывает крайне редко. Чаще я встречаю ситуации, что компания начинает новый продукт без документации, все работает отлично первые пару лет, а потом, по мере роста продукта, увольнений сотрудников, данная ситуация приводит уже к серьезным проблемам. Поэтому документация - это про стратегию и работу на перспективу, чтобы закрыть будущие риски того, что новые участники команды просто останутся без экспертизы, а люди как не крути, все равно увольняются и держать их вечно не получится. Сейчас может быть все классно и быстро, а через время начнутся проблемы, увеличение сроков тестирования, снижение качества, поэтому важно не упустить момент (и тут вспоминаем про метрики) и вовремя поймать момент, когда ситуация начинает выходить из под конроля. А как у вас обстоят дела с этим?👇 Все мои проекты: TG канал по тестированию AI | Курс по оценке и тестированию AI | Курс по тест-менеджменту | Youtube channel | Практика по тестированию | Платформа TestGrow | База знаний

Сегодня моему каналу 3 года! Именно 3 года назад, после запуска самой платформы TestGrow я решил сделать данный телеграм канал, в котором решил делиться всем, что связано с тестированием ПО. За это время я написал большое количество различных статей и полезных материалов по тестированию, мой канал вырос до 5500 подписчиков, что конечно не может не радовать, но написанные мной материалы постепенно начинают забываться в большой ленте постов, поэтому я решил раз в неделю выкладывать снова подборки моих материалов, которые были бы полезны для тестировщиков, особенно для новых подписчиков, кто достаточно недавно присоединился к каналу. И в этом посте я хочу поделится подборкой моих материалов по работе и тестированию API: Как писать API тесты Форматы передачи данных Краткий чек-лист по тестированию методов API Принципы построения REST архитектуры Шаблоны тест-кейсов для API Что такое микросервисы простыми словами Что такое WebSocket и как его тестировать? Видео по работе с WebSocket Что такое GraphQL и как с ним работать? Видео по работе с GraphQL Что такое GRPC и как его тестировать? 18 шаблонов готовых скриптов для работы с Postman Контрактное тестирование микросервисов Виды авторизации и принципы работы токенов в API Автоматизируем на Postman. Часть 1 Автоматизируем на Postman. Часть 2 Все мои проекты: TG канал по тестированию AI | Курс по оценке и тестированию AI | Курс по тест-менеджменту | Youtube channel | Практика по тестированию | Платформа TestGrow | База знаний

🎓 Теперь и на Stepik! Друзья, 4 месяца назад Дима Алексеев из @qa_road_channel запустил курс "Тестируем с ИИ" За это время: ✅ 300+ тестировщиков прошли обучение ✅ Сотни часов сэкономлено на рутине ✅ Курс улучшается и пополняется новыми уроками И вот теперь — курс на Stepik! 🔥 Почему Stepik: • Удобная платформа для обучения • Структурированный прогресс • Доступ с любого устройства Что в курсе: 📌 Промты для тест-кейсов, чек-листов и баг-репортов 📌 Промты для тест-планов и анализа требований 📌 API, UI/UX тестирование с ИИ 📌 Работа с Perplexity — доступ к топовым ИИ 📌 Как писать автотесты в Cursor  📌 Практические кейсы и адаптация под твои задачи 📌 Разбираемся с задачами, даже если не знаешь, с чего начать 📌 Чат для общения и поддержки 💡 Пример: анализ ТЗ на 30 страниц — с 6 часов до 30 минут! ⚡️ 5 часов изучения спасут недели жизни! 💰 Цена: 4990 2990₽ по промокоду GOOD_IDEA 👉 Вводите промокод и изучите новый инструмент уже сегодня! 🔗 Купить на Stepik: Ссылка скрыта

Про тестовые окружения (стенды). Иногда кажется, что тестовые стенды живут по своим законам. Ты начинаешь проходит тест-кейс, вчера все работало, а сегодня внезапно ошибка. При этом разработчик уверяет, что на его стенде все работает корректно. И несмотря на то, что чаще это конечно может быть реальный баг, но на самом деле я все чаще замечаю, что именно нестабильные тестовые окружения становятся главной причиной срывов регрессий и фейковых багов. И это не про плохую настройку окружения, а про системную проблему, что тестовые окружения никто не держит в актуальном состоянии. У них часто нет владельца, мониторинга, а данные там живут по принципу кто раньше успел , то и молодец, особенно в больших командах. Самое забавное, что иногда тестировщики часами ищут баг, а потом выясняется, что просто одна из зависимостей в тестовом окружении отвалилась, соседняя команда задеплоила свою версию микросервиса и случайно все тебе сломала или кто испротил тестовые данные. В идеале тестовое окружение должно быть предсказуемым, а именно чистые данные, стабильные сервисы, контроль версий, деплой как в проде. На практике же - это чаще набор контейнеров, которые поднимаются как попало и живут своей жизнью, пока кто-то не заметит, что тесты снова не работают, причем уже в больших масштабах Я за то, чтобы тестировщики начали относиться к окружению как к продукту, умели поддерживать версионность, мониторить, документировать и не стесняться попросить у DevOps нормальный пайплайн для обновлений. А у вас бывало, что баг оказался не багом, а особенностями тестового стенда? Как решаете проблему нестабильных окружений, автоматизацией, изоляцией от команд или просто привычкой перезапусти, вдруг заработает? 👇 Все мои проекты: TG канал по тестированию AI | Курс по оценке и тестированию AI | Курс по тест-менеджменту | Youtube channel | Практика по тестированию | Платформа TestGrow | База знаний

В последнее время часто вижу, как тестировщики делятся на два лагеря, когда речь заходит про вайбкодинг, когда используешь ИИ вроде ChatGPT, Claude или Copilot, чтобы писать автотесты, тест-кейсы, SQL-запросы или что-то еще. Одни говорят: Это деградация, тестировщики разучатся думать, другие Это просто новый инструмент, как когда-то Postman или Swagger. Я, если честно, ближе ко вторым. Потому что, по сути, вайбкодинг уже часть нашей реальности. Мы можем использовать ИИ где-то между задачами, чтобы сэкономить время, уточнить формулировку, найти паттерн, который мозг сейчас просто не видит. И это нормально. Не потому что мы ленимся думать, а потому что можно делегировать рутину и фокусироваться на смысле и аналитических аспектах задачи. Да, я тоже видел эти фразы в духе, что ИИ делает тестировщиков тупыми. Но по моему опыту все наоборот, ИИ делает тестировщика быстрее, если он умеет правильно задавать запросы. Ведь ИИ - это не волшебная кнопка, а инструмент, который усиливает твои знания. Если ты не понимаешь, что тестируешь, он не спасет. Но если понимаешь, что нужно, то он станет твоим вторым мозгом. Мне кажется, важно перестать делить тестирование на “старое доброе ручное” и “новое ИИ-шное”. Все, что реально работает - это часть профессии. Просто сейчас тестировщик, который умеет думать и использовать ИИ грамотно, выигрывает у того, кто принципиально все делает вручную. А вы как к этому относитесь? Используете ли ChatGPT, Claude, Copilot, Cursor и другие ИИ-инструменты в тестировании или пока держитесь по старинке? 👇 Все мои проекты: TG канал по тестированию AI | Курс по оценке и тестированию AI | Курс по тест-менеджменту | Youtube channel | Практика по тестированию | Платформа TestGrow | База знаний

Сравнительный анализ рынка тестировщиков: Россия и Европа, 2024–2025 Рынок QA за последние пару лет сильно перетряхнуло. В России к началу 2025 года он перегрет, потому что вакансий все меньше, а кандидатов все больше. На одну позицию теперь приходят десятки, а то и сотни откликов, особенно от джунов. При этом компании все реже ищут ручных тестировщиков и даже на младшие роли ждут хотя бы базовые навыки автоматизации. В Европе ситуация немного другая. Там рынок восстанавливается, например, в странах вроде Германии, Польши, Нидерландов и Чехии постепенно растет спрос на QA-инженеров, особенно в проектах, связанных с AI и автоматизацией. Сначала хотел просто написать обычным постом, но материала получилось так много, что в итоге я сделал отдельную на эту тему, в которой разобрал: - почему manual-тестирование стремительно теряет позиции, - как вырос конкурс на junior-места, - какие навыки теперь требуют даже у мидлов, - как миграция QA из СНГ влияет на Европу. Подробнее прочитать анализ можно по ссылке и поделитесь, чувствуете ли вы на себе изменения рынка? Все мои проекты: TG канал по тестированию AI | Youtube channel | Практика по тестированию | Платформа TestGrow | Автоматизация тестирования | Курс по тест-менеджменту | База знаний

Когда на собеседовании тебе задают вопрос, на который ты не знаешь точного ответа, это не конец света. Но важно не замолчать и не начать зарываться в свои попытки угадать ответ. Потому что именно так компании видят не только уровень знаний, но и твой уровень мышления. Вот как я это вижу на практике: – Слышишь вопрос, помнишь что где-то слышал или делал это, не суетись. Скажи: “Хороший вопрос, дайте минуту подумать”. – Если действительно не знаешь, то лучше сразу признаться. Например, “Я с этим напрямую не сталкивался” и дальше: “но если бы столкнулся, первым шагом сделал бы…». Так ты показываешь подход, а не просто пробел в твоих знаниях. – Попробуй связать с тем, что знаешь. Интервьюер обычно проверяет когнитивные способности, не зубрежку. Например: “Я не работал с Charles proxy, но в предыдущих проекта я решал похожие задачи через DevTools…». – Если не понятен вопрос, то можно попросить уточнить его: “Не могли бы вы немного пояснить, что имеется в виду под …?” или “Я правильно понимаю, что вы имеет ввиду это ….” Это даст время и иногда повернет вопрос в знакомое направление. Интервью это не про экзамен, где нужно назвать все ответы, а разговор про то, как ты решаешь задачи, особенно те, к которым не готов. Если ты покажешь, что не знание вопроса тебя не остановит, это будет уже большой плюс. Все мои проекты: TG канал по тестированию AI | Youtube channel | Практика по тестированию | Платформа TestGrow | Автоматизация тестирования | Курс по тест-менеджменту | База знаний

Часто слышу от разработчиков и менеджеров фразу, что тестирование тормозит процесс разработки. И если честно, я понимаю, откуда она берется. Когда проект горит, сроки сжаты любое дополнительное действие кажется лишним, особенно тестирование. Но тут есть парадокс. Когда тестирование тормозит релиз, оно на самом деле спасает время. Только не сейчас, а потом, уже на этапе поддержки приложения. Я вижу это регулярно, особенно в небольших компаниях и стартапах. Команда решает выкатить фичу быстрее со словами, если что, потом поправим. Но это потом наступает уже на проде и обычно обходится в 5 раз дороже, потому что нужно чинить, откатывать, искать причину, а иногда и объясняться с пользователями. Тестирование действительно занимает время. Но если его нормально не сделать, можно быстро схватить проблемы. И в отличие от разработки, где эффект виден сразу, в формате, что вот фича готова, у тестирования эффект отложенный. Потому что результат тестированияпо факту - это отсутствие проблем у пользователей. И вот тут начинается самое сложное, что нужно убедить бизнес ценить не то, что видно, а то, чего не случилось, фактически манипулируя только рисками, которые еще не произошли. Я не раз видел, как компании, которые гнали фичи в прод без нормального тестирования, а потом через некоторое время тратили недели на поддержку, фиксы и разбор проблем. И наоборот, те, кто инвестировал в нормальное тестирование, выпускали релизы чуть медленнее, но потом жили спокойнее и стабильно. Поэтому, да, тестирование действительно замедляет разработку. Но оно также экономит кучу времени, нервов и денег, когда все уже работает в продуктиве у пользователей. А вы сталкивались с тем, что после пары неудачных релизов тестирование вдруг становится приоритетом номер один? 👇 Все мои проекты: TG канал по тестированию AI | Youtube channel | Практика по тестированию | Платформа TestGrow | Автоматизация тестирования | Курс по тест-менеджменту | База знаний

НОВЫЙ ФРЕЙМВОРК ДЛЯ ОЦЕНКИ ИИ Всем привет! Хочу поделиться с вами отличной новостью, что я наконец-то опубликовал мой собственный разработанный evaluation framework для оценки решений на базе генеративного ИИ. Я работал над этим фреймворком практически 6 месяцев, в том числе изучая и применяя на практики различные другие фреймворки, такие как deepeval и RAGAS, но в итоге не один из них так полностью и не удовлетворил меня в плане оценки ИИ решений в рамках моих проектов. Поэтому я решил пойти другим путем и написать свою собственную бибилиотеку для оценки ИИ, которая бы решала проблемы, с которыми я сталкивался: ⁃ сделать возможность изменения требовательности оценки в зависимости от проекта, потому что на одном проекте нужно строгая жесткая оценка, а на другом, например, у обычного чат бота не сильно критично, если он добавляет от себя контекста, поэтому требовательность может быть ниже. ⁃ сделать оценку более точную и использовать LLM для косвенной, а не прямой оценки. ⁃ расширить и улучшить систему вердиктов, которая также используется в deepeval в более упрощенном варианте ⁃ сделать процесс оценки прозрачным, то чего мне не хватало в других фреймворках, когда не совсем понимаешь, почему получился тот или иной скор балл. И все эти проблемы я постарался решить с моем фреймворке eval-ai-library. Что сейчас там есть: ⁃ Поддержка более 15 метрик для оценки ИИ ⁃ Полноценная имплементация алгоритма оценки G-Eval ⁃ Поддержка разных LLM провайдеров ⁃ Генерация датасета с нуля или из документов ⁃ Регулировка строгости оценки через температуру ⁃ Визуализация результатов оценки в терминале ⁃ Прозрачное логирование, которое показывает полностью из чего получился финальный скор балл. ⁃ Полноценная документации по работе с фреймворком Я буду благодарен за использование моего фреймворка в вашей работе, а также вы всегда можете что-то конрибъютить сами в данный проект. Скачивание доступно через официальный установочник python pip. Ссылка на библиотеку в pypi Ссылка скрыта Ссылка на открытый GIT репозиторий проекта Ссылка скрыта