🦊 Мой первый мобильный тест

Когда мне впервые дали на тест мобильное приложение, я честно думал: «Ну чё там, приложение как приложение. Потыкал кнопки, посмотрел, не крашится — и готово.»

Ага, держи карман шире.

🟣 Вот как было:

Начал с Android — вроде всё норм. Только кнопка чуть съехала. Ну, не критично же.

Потом включил iOS — и там начался цирк:

• кнопки налезают друг на друга,

• половина текста не помещается,

• скролл работает через раз,

• и на каком-то старом iPhone приложение просто решило: «я больше не с вами», и умерло.

До полуночи я бегал между эмуляторами, реальными телефонами, снимал скрины, записывал видео, заводил баги. Голова кипела. Хотелось спросить у вселенной: «Зачем столько разных экранов?! Кто вообще придумал адаптивность??»

Но под утро, когда я уже почти уснул с телефоном в руке, вдруг поймал странное чувство:
мне… нравится.
Нравится разбираться в этой каше. Нравится видеть то, что другим кажется мелочью.
Нравится ловить баг, о котором никто даже не подумал.

И я понял:

Мобильное тестирование — оно живое. Иногда бесит, часто утомляет, но почти всегда увлекает. Это как быть таким digital-детективом. И если не ждать идеальности — даже очень прикольно.

А вы помните свой первый мобильный баг? Или ту задачу, от которой хотелось выкинуть телефон?

Пишите, поддержим друг друга в этом безумии 🤗

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

#междусобойчик

📓 Автоматическое заполнение форм с помощью JavaScript в браузере

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

Как это работает:

1️⃣ Открываем DevTools в браузере (клавиша F12).

2️⃣ Переходим на вкладку Console.

3️⃣Копируем следующий код и нажимаем Enter:

(function() {
var inputs = document.querySelectorAll('input, select, textarea');
inputs.forEach(function(input) {
if (input.type === 'text' || input.type === 'textarea') {
input.value = 'Test Value'; // Заполняем текстовые поля
} else if (input.type === 'email') {
input.value = '[email protected]'; // Заполняем email
} else if (input.type === 'password') {
input.value = 'TestPassword123'; // Заполняем пароль
} else if (input.type === 'checkbox') {
input.checked = true; // Отмечаем чекбоксы
} else if (input.type === 'radio') {
input.checked = true; // Выбираем радиокнопки
} else if (input.tagName.toLowerCase() === 'select') {
input.selectedIndex = 1; // Выбираем первый доступный элемент в списке
}
});
})();

Что происходит в коде:

📍 Этот код перебирает все элементы формы на странице (`input`, textarea, `select`).

📍 Для текстовых полей, полей ввода email, паролей, чекбоксов и радиокнопок он автоматически заполняет соответствующие данные.

📍 Для выпадающих списков (select) выбирается первый элемент.

❗️ Если на странице есть динамически изменяющиеся элементы (например, поля, которые появляются при выборе определенной опции), вы можете добавить задержку или использовать MutationObserver для отслеживания изменений.

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

#буст

😎 ИИ-тестировщик: ожидания и реальность

ИИ в тестировании звучит как магия: всё автоматизирует, ошибки сам чинит, релизы ускоряет. Но на деле — всё не так гладко. Разберёмся, где он реально помогает, а где пока только мешает.

Что он уже умеет:

➡️ Дописывать автотесты по сценарию — экономит время, если правильно натренирован.

➡️ Создавать новые тестовые модели — на основе уже написанных.

➡️ Расширять тест-покрытие — подмечает нестандартные кейсы, которые человек может упустить.

Идеально было бы: дал ИИ техзадание — получил продукт с тестами.

В реальности: ИИ накидал тест, ты час разбираешься, что он вообще имел в виду.

Какие подводные камни:

🔘 Без опыта — лучше не лезь: ИИ может нагенерить кучу мусора.

🔘 Эксперта всё равно надо: чтобы проверять, допиливать, объяснять ИИ, что не так.

🔘 Облака — это риск: многие ИИ-сервисы зарубежные, а значит — возможны утечки.

ИИ — полезный инструмент, если умеешь с ним работать. Но просто так его внедрить и сэкономить — не выйдет. Придётся учиться, настраивать и думать головой.

🔗 Оригинал статьи

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

#свежак

Хорошо, что сегодня выходной. Да, друзья? 👍

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

#развлекалово

⚙️ Подборка полезного по Cypress

📍 Полное руководство по Cypress

Подробное введение в Cypress: установка, написание тестов, работа с асинхронным кодом и интеграция с CI/CD.

📍 Cucumber в Cypress: Пошаговое руководство

Интеграция Cucumber с Cypress для написания тестов в стиле BDD с использованием Gherkin.

📍 Cypress Tutorial Full Course | Learn Cypress in 5 Hrs

Полный курс по Cypress на английском языке, охватывающий основные аспекты работы с инструментом.

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

#свежак

🌸 Вопросы с собеседований: как протестировать продукт, если требования еще не установлены

Использовать гибкую методологию, такую как Scrum:

1️⃣ Определение целей. Выполнение модульного, интеграционного, приемочного и системного тестирования, с обновлением

2️⃣ Разбиение на пользовательские истории и назначение спринтов.

3️⃣ Выполнение модульного, интеграционного, приемочного и системного тестирования, с обновлением сценариев по мере изменения требованй.

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

#междусобойчик

😎 Топ-вакансий для тестировщиков за неделю

Инженер по автоматизации тестирования — от 240 000 ₽, удаленно (Москва)

Quality Assurance Engineer (Senior) — Москва

QA Engineer (middle) — от 130 000 до 180 000 ₽, удаленно (Москва)

Senior Mobile Automation & Manual QA Engineer — гибрид (Москва/Санкт-Петербург)

Junior Продуктовый QA (без опыта) — офис (Москва)

➡️ Еще больше топовых вакансий — в нашем канале QA jobs

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

#свежак

🐞 Как быстро заводить баг-репорты прямо из браузера

Эта инструкция помогает упростить и ускорить процесс: баги оформляются автоматически — с видео, логами и всей нужной информацией — буквально в пару кликов.

Как это работает:

1️⃣ Устанавливаем расширение в браузер

Используйте специальные расширения, которые:

• записывают экран и шаги, которые мы выполняем

• автоматически сохраняют консольные ошибки и сетевые запросы

• фиксируют данные об окружении: браузер, язык, разрешение экрана

• формируют баг-репорт, который можно отправить сразу в Jira, Trello, GitHub или просто скопировать

Что можно использовать:

➡️ Bird Eats Bug — очень удобное расширение, подходит и для ручного, и для регресса.
Оно работает прямо в браузере, не требует установки, записывает всё: экран, действия, логи, XHR-запросы, URL.

➡️ BugReplay — если нужно больше акцента на видео.
Также сохраняет сеть и консоль. Подходит, если баг сложно воспроизвести.

После установки расширения — входим в аккаунт и включаем запись, когда начинаем тест.

📌 Пример:

Во время теста у нас слетает кнопка оформления заказа. Мы нажимаем “Start recording”, повторяем шаги, где проявляется баг — и останавливаем запись. Всё готово: лог, видео, действия, URL.

2️⃣ Настраиваем шаблон баг-репорта

Чтобы не описывать каждый баг с нуля, настройте шаблон. Тогда при каждом репорте автоматически подставляется:

• шаги воспроизведения
• описание окружения
• консольные ошибки и сетевые запросы
• ссылка на видео
• URL страницы

📌 Пример шаблона:

Проблема: кнопка не реагирует на клик
Шаги: подставлены автоматически
Видео: [ссылка]
Логи и XHR: вложены
Окружение: Chrome 123, Windows 11, 1920×1080

3️⃣ Отправляем баг сразу в систему

Отправьте баг сразу в систему, где его будут обрабатывать разработчики. Это может быть: Jira, Trello, GitHub Issues, Notion.

📌 Пример:

Баг записан. Мы нажимаем “Create bug” → выбираем Jira → баг улетает в проект с видео, логами, шагами и средой.


Как можно улучшить:

• Настроить горячую клавишу для начала записи

• Создать шаблоны под разные типы багов (UI, функционал, мобильные)

• Использовать расширение даже для нестабильных или «разовых» ошибок, которые тяжело повторить

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

#буст

💼🚫 Собес провален? 8 советов, как извлечь пользу из каждого отказа

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

Однако отказ — это всего лишь один из этапов в поиске работы и не стоит воспринимать его как конец света.

➡️ Читать статью

🐸 Библиотека программиста

🔍 Инструмент недели: Fiddler в нагрузочном тестировании

Несмотря на то, что инструмент чаще используется для отладки и анализа API, в нагрузочном тестировании он может сыграть ключевую роль.

Чем может помочь:

😗 Позволяет изучить реальное поведение клиента: какие именно запросы отправляются, какие заголовки, параметры и последовательность. Это критически важно при создании реалистичных нагрузочных сценариев.

😗 Можно использовать для записи последовательности действий пользователя, которые потом адаптируются в скрипты для JMeter, Gatling, k6 и других инструментов. Это повышает точность моделирования поведения пользователей.

😗 Если при нагрузке сервер отвечает нестабильно или возникают ошибки, Fiddler помогает локализовать проблему: показывает точное содержимое запросов и ответов, HTTP-коды, время ответа, редиректы и пр.

😗 Многие системы используют авторизацию, сессионные токены, cookies. Fiddler показывает, как они передаются, что упрощает их интеграцию в нагрузочные скрипты.

Пример использования:

1️⃣ Запись пользовательского сценария:

• Запустим Fiddler и выполним необходимые действия в приложении, чтобы зафиксировать соответствующий трафик.

• Сохраним сессию в формате .saz через меню File > Save > All Sessions.

2️⃣ Настройка скрипта для повторного воспроизведения:

• Откроем Fiddler Script Editor через Rules > Customize Rules.

• Вставим кастомный скрипт, который реализует команды load и run.

• Сохраним изменения и перезапустите Fiddler.

3️⃣ Выполнение нагрузочного теста:

• Откроем QuickExec (нажмите Alt+Q).

• Выполним команду load <путь к файлу .saz>, чтобы загрузить записанную сессию.

• Выполниим команду run <интервал в миллисекундах> <количество повторов>, чтобы начать воспроизведение запросов с заданным интервалом и числом повторений.

Этот подход позволяет симулировать нагрузку на приложение, воспроизводя реальные пользовательские сценарии с заданной интенсивностью.

📍 Полезные материалы:

— Fiddler для тестировщика / Установка и настройка

— Fiddler Everywhere для тестировщика | Как тестировать API в Fiddler

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

#буст

Мы или не мы? 🥹

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

#развлекалово

😇 Подборка подкастов от TestGuild

➡️ Как оптимизировать автоматизацию и CI/CD — и при этом сэкономить

Если ты работаешь с Jenkins, GitHub Actions или вообще в DevOps-среде — это видео must-see.
Гаураф (чувак, которого уважают и за AI, и за автоматизацию) делится конкретными подходами, как навести порядок в пайплайнах, уменьшить затраты и не потерять в скорости или качестве.

📍 Что вы узнаете:

• как не платить лишнего за лицензии,

• как встроить безопасность в тестовую инфраструктуру,

• и как автоматизировать «по уму», а не «потому что модно».

➡️ Как AI меняет профессию тестировщика — с Джейсоном Арбоном

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

📍 Джейсон рассказывает:

• как ИИ-платформы сами пишут и выполняют тесты,

• почему автоматизация больше не про Selenium-скрипты,

• и какие навыки нужно прокачивать, чтобы не остаться за бортом.

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

#буст

📈 Как «ленивая разработка» захватывает IT-рынок

Пока мы выстраиваем архитектуру, пишем тесты и спорим о лучших практиках, рынок всё активнее обживают те, кто вообще не пишет код. Low-code и no-code решения не просто живы — они становятся нормой для бизнеса.

Порог входа минимальный, скорость разработки — бешеная, а заказчику всё равно, написано ли это на Java или накликано в визуальном редакторе. Вопрос: как долго останется актуальной классическая разработка?

🔗 Подробнее в статье

🐸 Библиотека джависта