TestGrow - software testing

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

🎓 Открытый бесплатный курс по автоматизации на Python Просто и доступно для всех кто с нуля. 23 декабря запускается бесплатный курс «Автоматизация на Python (основы): Selenium + Playwright» в @qa_road_channel 📌 В программе: • Автотесты фронта (Selenium + Playwright) • Автотесты API (pytest + requests) • Работа с БД • Docker для тестов • Allure-отчёты • CI/CD интеграция 🧑💻 Для всех кто хочет в автоматизацию 💎 Результат: твой первый проект автотестов для портфолио. 💡 Формат: короткие видео уроки + задания. Бесплатно! 👉 Приходи в @qa_road_channel Старт 23 декабря — не пропусти! 🚀

Всем привет! Хочу сообщить, что 15 января 2026 года я запускаю второй поток на курсе по оценке и тестировани ИИ 🚀. Напомню, что это едиственный полноценный русскоязычный курс по тестированию ИИ, которые охватывает большое количество апспектов работы с ИИ, такие как: - Оценка моделей ML/DL - Оценка и тестирование LLM - Оценка и тестирование RAG систем и AI агентов - Оценка генерации картинок и видео - Оценка предвзятости моделей и их безопасность Курс включает в себя: 1. Теоретические знания (16 часов онлайн лекций в живую) 2. Лекции по практике (более 20 часов дополнительных видео) 3. Домашние задания (в среднем у ученика уходит от 2-8 часов на выполнение домашней работы после каждой лекции) 4. Работу с реальными ИИ системами (для курса подготовлены реальный RAG системы, ИИ агенты, модели OpenAI и Google Gemini) 📌И самое важное!!! При бронировании места и внесения предоплаты 20% от стоимости курса до конца декабря, скидка на общую стоимость курса составит 15%. 👇Оставить заявку можно на сайте: eval-ai.com или написать мне в ЛС: @al_meshkov Если думали, где стоит развиваться и расти, то это ваш шанс получить для себя абсолютно новые, но востребованные навыки оценки и тестирования ИИ! Все мои проекты: TG канал по тестированию AI | Курс по оценке и тестированию AI | Курс по тест-менеджменту | Youtube channel | Практика по тестированию | Платформа TestGrow | База знаний

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

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

Знакомьтесь, это Артём Русов. Автор курса для QA-инженеров, который прошли более 90 000 человек на Youtube и Stepik. Артём создал Telegram-экосистему для тестировщиков, основанную на боевом опыте в реальном IT. 🧠 [Мысли и реальность QA] Неочевидный опыт. Разбирает реальное тестирование, менторство и то, что поможет вам перестать совершать ошибки новичков. ⚙️ [База знаний и инструментов] Инструменты и Симуляторы. Собрал всё, что помогает расти: от рабочих чек-листов до интерактивных тренажёров. 💬 [QA-комьюнити] Решение ваших проблем. Живое общение, карьерные советы и ответы экспертов. Вы больше не останетесь один на один со сложным багом или вопросом. Рекомендую подписаться, так как это не просто контент. Это проверенный путь, который прошли сам Артём и его коллеги по цеху.

Сегодня просто не могу обойти стороной вчерашнее масштабное падение большого количества сервисов в интернете на пару часов, включая ChatGPT, Spotify, X, Uber, ClaudeAI, Google store, Zoom, GitHub, Netflix и тысячи других. И причина на самом деле иронична, потому что сервис Cloudflare, который должен был все эти сайты как раз защищать от таких падений, сам упал и утащил за собой половину мирового интернета. По последним комментариям от компании причина не в хакерской атаке на сервис, а в том, что один конфигурационный файл после обновления системы как то не так сгенерировался и привел к глобальному сбою. Ущерб от отказа системы, которой пользуются огромное большое количество сервисов по всему миру оценивается в 15 триллионов долларов. Вот так бывает, что-то не досмотрели, тут забили, это не проверили и как итог массовые падения, причем уже не первые за этот год. С другой стороны, после таких падений, инциденты на продуктиве небольшой компании уже кажутся и не такими критичными. Представляю лицо руководителя команды сопровождения Cloudflare, которого по среди ночи (а в штатах на момент инцидента была ночь) будят со словами, “мне кажется наш деплой положил половину интернета” Ну и провокационный вопрос, а как бы вы отреагировали в такой ситуации, если это была бы ваша ошибка? Все мои проекты: TG канал по тестированию AI | Курс по оценке и тестированию AI | Курс по тест-менеджменту | Youtube channel | Практика по тестированию | Платформа TestGrow | База знаний

Сегодня хочу продолжить публикацию моих материалов, которые могут вам помочь в различных задачах, как в работе, так и в обучении. Мои материалы по работе с БД: Кратко о типах взаимосвязей внутри БД Как тестировать Базы Данных Что такое ETL и как его тестировать? Тестирование Big Data и noSQL Советы по написанию SQL запросов Инструменты для работы с БД Цикл лекций по работе с SQL Все мои проекты: TG канал по тестированию AI | Курс по оценке и тестированию AI | Курс по тест-менеджменту | Youtube channel | Практика по тестированию | Платформа TestGrow | База знаний

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