Совет от тестировщика 51/∞ : Не закрывайте плавающие баги просто так
Если дефект воспроизвелся один раз и больше не хочет, не спешите переводить ее в статус "Can't reproduce". Потратьте еще 15 минут: проверьте логи, вспомните свои точные шаги, спросите коллег, зафиксируйте все, что вы о нем помните в отчете.
Плавающий баг на тестовом стенде это почти всегда гарантия того, что на проде он выстрелит у тысячи пользователей. Заведите тикет, опишите все догадки и приложите логи, даже если шаги не 100% точные.
Совет от тестировщика 50/∞ : Тестируйте пустые состояния
Дизайнеры обожают рисовать красивые макеты, где у пользователя загружена аватарка, добавлено 100 друзей и заполнен профиль. Но что видит новый юзер, который только что зарегистрировался?
Всегда проверяйте Empty States. Пользователь не должен видеть пустой белый экран или сломанную верстку. Там должен быть понятный призыв к действию: "Добавьте первого друга", "Загрузите фото" и т.д.
Совет от тестировщика 49/∞ : Граничные значения не только про поле ввода
Когда мы слышим про классы эквивалентности и граничные значения, мозг сразу рисует поля ввода возраста или цены. Но эти техники работают вообще везде, где есть лимиты.
Размер загружаемого файла, количество символов в названии статьи, дата окончания подписки. Всегда ищите границы в бизнес-логике, именно там система ломается чаще всего.
Совет от тестировщика 48/∞ : Делитесь знаниями
Напишите статью, проведите внутренний митап, заявите о своей экспертизе. Не держите все в себе.
Это не только развивает комьюнити, но и отлично работает на ваш личный бренд. Когда-нибудь это обязательно окупится крутым оффером.
Говорю, как человек, за плечами которого не одна конференция, митап и 300.000 аудитории в разных соцсетях.
Совет от тестировщика 47/∞ : Следите за трендами с умом
Не бросайтесь внедрять каждый новый модный фреймворк на проект. То, что красиво звучит на конференциях, не всегда подходит под ваши текущие задачи.
Сначала оцените профит для проекта, а потом уже тащите технологию в команду.
Совет от тестировщика 46/∞ : Учите английский
Вся актуальная и передовая документация по инструментам выходит именно на нем. Ждать перевода статей или обновлений фреймворков = отставать от рынка.
Даже базовый технический английский сильно расширит ваши карьерные горизонты.
Совет от тестировщика 45/∞ : Оперируйте цифрами
Собирайте метрики качества. Бизнес и менеджеры понимают язык цифр, графиков и денег, а не ваши эмоции про "у нас тут все криво работает".
Придите с отчетом, где видно количество багов по модулям и общее качество продукта – и к вам прислушаются.
FromSoftware объявила даты сетевого тестирования своей новой игры The Duskbloodsi — оно пройдёт с 21 по 24 августа. Игра остаётся эксклюзивом Nintendo Switch 2, при этом дата релиза до сих пор не названа.
Это первая возможность для игроков опробовать проект студии, известной по Dark Souls, Bloodborne и Elden Ring, до полноценного выхода.
Совет от тестировщика 44/∞ : Менторите новичков
Обучая других, вы сами структурируете свои знания. То, что вам кажется очевидным, для джуна может быть откровением.
К тому же, это отличная прокачка софт-скиллов для будущего лида, если вам это интересно.
Совет от тестировщика 43/∞ : Не спорьте ради спора
Ваша общая цель с разработчиком и менеджером – выпустить качественный продукт, а не доказать, кто тут умнее. Если баг минорный и никак не влияет на юзеров, умейте уступать.
Токсичные воины за идеальный код только удлиняют процесс разработки и оттянивают решение действительно важных проблем.
В комментах спросили "а что такого?". Поясняю.
Какой смысл выкатывать фичи на комьюнити конкурсов вместо комьюнити авторов ботов?
Подмножество конкурсантов с подмножеством активных авторов популярных ботов не связано. Это вообще разные тусовки.
Участники конкурсов это удобные для Телеграм тестеры, с ними проще работать, но ценными являются авторы ботов, потому что ЦА и потребители ботапи это они, а не олимпиадники, которые вокруг конкурсов тусуются.
Телеграм пошел куда проще, а не куда надо — в плане того, что функция тестируется не на тех, кому она может быть нужна.
Совет от тестировщика 42/∞ : Помните про пирамиду тестирования
Не пытайтесь покрыть UI-тестами каждую кнопку, это долго, дорого и нестабильно. Основная масса проверок должна лежать на уровне API и юнитов.
Совет от тестировщика 41/∞ : Пишите понятно
Суть проверки, шаги воспроизведения, результаты, должны быть понятны даже стажеру в его первый рабочий день. Избегайте сленга, который понятен только вам и паре старичков на проекте.
Баг-репорт, чек-лист, тест-кейсы - это документ, а не личная переписка лучших друзей.
Совет от тестировщика 40/∞ : Удаляйте мусор
Не привязывайтесь к старым проверкам. Регулярно удаляйте неактуальные тесты, которые дублируются или проверяют фичи, отключенные год назад.
Чистая база тестов это залог быстрого регресса. Не копите хлам.
Совет от тестировщика 39/∞ : Прикладывайте видео, скрины и другие вложения
Запись экрана или скриншот с выделенной проблемой, список логов, дефектные тестовые данные экономят часы пустых споров. Разработчику проще один раз увидеть, чем вчитываться в ваши формулировки.
Самое важное в баге: понятный заголовок и вложение с доказательством дефекта.
Порекомендовали AI-детектор Яндекса. Проверил его на одном из текстов Claude. Для симметрии проверил тем же текстом ещё AI-детектор Сбера и хваленый Pangram с его 99% точности.
В общем, нет, никто не может.
Совет от тестировщика 38/∞ : Сужайте локализацию дефекта
Прежде чем завести баг, найдите минимальный набор шагов для его воспроизведения. Не пишите 15 шагов, если ошибку можно повторить за три. Не записывайте 5минутное видео, а только ту часть, которая важная для воспроизведения бага.
Разработчик не должен тратить полчаса, чтобы просто понять, как добраться до проблемы. Уважайте чужое время.
Совет от тестировщика 37/∞ : Фиксируйте договоренности
Любое устное изменение требований должно быть записано в тикете. Поговорили у кулера или на созвоне: зафиксируйте это в комментариях к задаче.
Слова к делу не пришьешь, а когда придет время релиза, никто и не вспомнит, о чем вы там договорились месяц назад.
Особенно это важно для багов, они всегда должны быть в системе, а не в переписках с разработчиками. Спросят в первую очередь с вас.
Совет от тестировщика 36/∞ : Дробите сложные задачи и декомпозируйте
Разделяйте объемные требования на атомарные проверки. Тест-кейс на 40 шагов никто никогда не дочитает до конца, да и поддерживать его сущий ад.
Маленькие и понятные проверки легко переиспользовать и проще автоматизировать в будущем.
Коллеги, как там дела на рынке? ИИ уже "убил" тестировщиков?
Сейчас активно веду в тредс и там, что ни день, то боль про найти работу.
Все реально так плохо или есть еще способы ее найти?
Интересно послушать тех, кто в поиске последний год, кто с опытом или без него.
Что сработало, что нет? Какие технологии сейчас просто мастхэв в резюме?
Просто пост, чтобы подарить хоть какую-то надежду, но желательно не убить ее.
Совет от тестировщика 35/∞ : Изучайте доменную область
Понимание того, как пользователи зарабатывают деньги с помощью вашего продукта или какую проблему он решает, делает из вас крутого инженера. Именно это в первую очередь ценят в тестировщике, а не в его умении придумать 100 кейсов с напитками, когда он заходит в бар.
Тестировщик, который понимает домен, всегда найдет более критичные баги, чем тот, кто просто идет по шагам тест-кейса.