Записки Тестировщика / Василий Волгин

описание

Канал про тестирование и мир IT. Здесь автор делится знаниями и помогает войти в IT. Немного о себе: - являюсь авто тестировщиком (был ручным и фулстек qa) - боевой опыт более 3 лет Личка: @VasiliiVolgin

← к каналу @QAtestingVas

408

подписчиков

Охват к подписчикам

39,7%

ERR

Реакции к просмотрам

2,66%

86 на 20 постов

Пересылки к просмотрам

0,03%

Постов в день

0,0

всего 20

Где отзываются чаще

доля реакций к просмотрам

1 авг.без подписи5,21%
13 июн.И такие кадры встречаются…)))4,74%
2 июл.без подписи3,85%
27 мая🐞 Баг, который стоил $370 миллионов - за 80 миллисекунд! В 1996 году ракета-носитель Ariane 5 взорвалась через 40 секунд после старта. Причина? 64-битное число с плавающей точкой не влезло в 16-битное целочисленное поле. Ошибка была в мёртвом коде - фрагменте навигационной системы, унаследованном от Ariane 4, который на новой ракете вообще не нужен был. Но его оставили «на всякий случай». Чему это учит: • Унаследованный код не бывает «безопасным по умолчанию» • Тестирование интеграции > тестирование компонентов в изоляции • Иногда самый дорогой баг - это тот, который ты даже не ожидаешь найти.3,82%
22 июл.Коллеги, цените своё время. Не соглашайтесь на многоэтапные отборы, огромные тестовые задания и недели собеседований ради зарплаты на уровне неквалифицированной работы. Исключение - адекватные junior-вакансии, где действительно готовы обучать, дают наставника и понятный путь развития. Но даже там процесс найма должен быть соразмерен позиции и зарплате.3,70%
24 маяТестовая шутейка😂 - Почему айтишник не спорит с женой? - Потому что в продакшене лучше не дебажить.3,66%
24 маяТестовая шутейка😂 Тестировщик пошёл на свидание. Всё было хорошо, пока он не сказал: - Давай сначала проверим негативный сценарий.3,64%
2 июн.По теме подработок / второй работы для QA уже несколько человек написали в личку. Сразу уточню важный момент: я не работодатель, не рекрутер и не предлагаю конкретную вакансию. Идея другая - собрать небольшой тестовый чат для QA/QAA, кому актуальна тема дополнительной занятости, и вместе разбираться: - где искать подработки и проектные задачи; - какие бывают форматы: part-time, project-based, ГПХ, ИП, самозанятость; - какие ставки сейчас адекватны; - как совмещать с основной работой; - какие есть риски по NDA, конфликту интересов, налогам и выгоранию; - как manual QA может расширять варианты через автоматизацию; - какие вакансии/проекты выглядят нормально, а какие лучше обходить стороной. То есть это не “я даю работу”, а рабочий обмен опытом, ссылками, находками и вопросами. Пока не хочу запускать пустой чат ради чата. Уже есть несколько заинтересованных, добираю ещё пару человек, чтобы был живой старт. Кому актуально - напишите мне в личку “подработка” и пару слов по опыту и целям: manual/auto, опыт, что сейчас ищете. Telegram: @VasiliiVolgin3,29%
24 маяТестовая шутейка😂 Тестировщик заказывает кофе: - Один латте, пожалуйста. - Большой или маленький? - Давайте оба. Надо проверить граничные значения.3,09%
7 авг.🧪 QA в 2026: что действительно важно прямо сейчас Тестирование становится всё более тесно связано с AI. Он уже помогает не только писать тест-кейсы, но и генерировать автотесты, анализировать падения, искать причины ошибок и сокращать рутинную работу. Что стоит держать в поле зрения 👇 🤖 AI всё глубже входит в QA Тестировщики всё чаще используют AI для подготовки сценариев, анализа логов, поиска edge cases, генерации тестовых данных и первичного разбора дефектов. ⚙️ Автоматизация становится умнее Фокус постепенно смещается от простого количества автотестов к их качеству, стабильности и полезности. Всё больше внимания уделяется flaky-тестам, скорости обратной связи и удобству анализа результатов. 🌐 Растёт роль комплексного тестирования Проверка только UI уже давно недостаточна. QA всё чаще работает с API, интеграциями, событиями, логами, базами данных и поведением системы целиком. ⚠️ AI-тест не всегда хороший тест Сгенерированный тест всё равно нужно проверять. Важно понимать, что именно он проверяет, какие риски покрывает и способен ли действительно поймать дефект. 💡 Главный тренд QA в 2026 году становится меньше про механическую проверку и больше про анализ рисков, качество продукта, архитектуру тестирования и грамотное использование AI-инструментов.3,03%
10 июл.Недавно впервые сходил на групповое занятие по баскетболу💪🥳 Думал, будет тренировка: разминка, упражнения, броски. А оказалось - просто час игры. Сразу попал к ребятам, которые явно играют давно. Первые минут десять пытался понять, куда вообще бежать. Потом втянулся. Два раза открывалось второе дыхание. И два раза сердце намекало: «Ну все, дальше без меня». 😄 Но самое кайфовое - в какой-то момент начал играть, а не выживать. Отдал пару голевых передач и даже забил из-под кольца через защитника🥇 И еще одна деталь, которая меня впечатлила. С нами играл мужчина лет семидесяти🤯 И он не просто присутствовал. Он играл. После такого начинаешь понимать, что возраст - далеко не главный фактор. Еще удивило, что все это бесплатно. Люди просто собираются поиграть. Без записи, без абонементов, без попытки что-то продать. Я много лет в IT, сейчас работаю в финтехе. И неожиданно поймал себя на мысли, что давно не чувствовал себя настолько живым. Кажется, теперь знаю еще один отличный способ перезагрузить голову🤘😇2,88%
13 маяСамый эффективный способ проверить веб-приложение сейчас Если коротко: не пытайтесь автоматизировать всё. Самый сильный подход - проверить критический пользовательский путь через E2E-тесты, а остальное закрыть API, компонентными и ручными проверками. В веб-тестировании главная ошибка - писать десятки хрупких UI-тестов на каждый клик. Они долго работают, часто падают из-за мелочей и быстро становятся дорогими в поддержке. Гораздо эффективнее идти от риска. Что проверять в первую очередь Начните со сценариев, где ошибка реально бьёт по бизнесу: - Регистрация и логин. - Оформление заказа. - Оплата. - Поиск и фильтры. - Личный кабинет. - Отправка форм. - Восстановление пароля. - Работа на мобильном разрешении. Один стабильный тест на критический путь полезнее, чем десять тестов на второстепенные кнопки. Лучший инструмент для старта Для современного веба я бы выбирал Playwright. Почему: работает с Chromium, Firefox и WebKit; хорошо подходит для SPA-приложений; умеет auto-wait, поэтому не нужно вручную расставлять sleep; имеет web-first assertions, которые автоматически ждут нужное состояние; удобно запускается в CI; позволяет тестировать UI и API в одном проекте. Минимальный пример E2E-теста import { test, expect } from '@playwright/test'; test('пользователь может найти товар и открыть карточку', async ({ page }) => { await page.goto('https://example-shop.com'); await page.getByRole('searchbox').fill('laptop'); await page.getByRole('button', { name: 'Search' }).click(); await expect(page.getByText('Search results')).toBeVisible(); const firstProduct = page.locator('[data-testid="product-card"]').first(); await expect(firstProduct).toBeVisible(); await firstProduct.click(); await expect(page.getByRole('heading')).toBeVisible(); await expect(page.getByRole('button', { name: 'Add to cart' })).toBeEnabled(); }); Что здесь важно - Тест проверяет не HTML ради HTML, а реальное поведение пользователя: - открыл сайт; - ввёл запрос; - получил результаты; - открыл товар; - увидел возможность добавить его в корзину. Это и есть нормальная E2E-проверка: не «кнопка существует», а «сценарий работает». Какие инструменты использовать Playwright - хороший выбор для стабильных E2E-тестов, кроссбраузерности и CI. Cypress - удобен для команд, которым важны визуальный runner, отладка и быстрый старт. Selenium - всё ещё актуален там, где уже есть большая инфраструктура, разные языки, Selenium Grid или legacy-проекты. Postman / REST Assured / Playwright API - для проверки API без тяжёлого UI. Lighthouse - для базовой проверки производительности, доступности и SEO. axe / Playwright Accessibility / Cypress Accessibility - для accessibility-проверок. Percy / Applitools / Playwright screenshots - для визуальной регрессии. Практичная схема проверки Я бы строил так: 1. API-тесты Проверяют бизнес-логику быстро и стабильно. 2. E2E-тесты Покрывают только главные пользовательские сценарии. 3. Визуальные тесты Ловят сломанную верстку, особенно после изменений CSS. 4. Ручное exploratory testing Находит то, что автотесты не предугадают: странные сценарии, UX-проблемы, баги на стыке логики. Главное правило Не спрашивайте: «Что мы можем автоматизировать?» Спросите: «Какая ошибка будет стоить нам дороже всего?» И начинайте тестирование именно оттуда. Хороший QA сейчас - это не человек, который пишет максимум автотестов. Это человек, который понимает риски, выбирает правильный уровень проверки и не превращает тестовую базу в склад хрупкого кода.2,46%