Почитать:
TestEngineer:
Четыре признака оверинжиниринга автотестов
Избыточные функции, уровни абстракции и архитектурные решения, которые делают тесты громоздкими.
Новый практикум команды Playwright.
Тестовые стратегии на Android: обновления гайдов Google
Скриншотные тесты, большие е2е-наборы, Robolectric и прочее.
Тестирование, основанное на рисках: быстрый практикум
Практикум, дающий представление о методике.
Также:
Нагрузочное тестирование Redis
Я собираюсь объяснить, как можно измерить производительность Redis. Об этом уже написано множество статей, но я хочу поделиться своим опытом, опытом DevOps-инженера. Я также хочу рассказать о методах, которые внедряются в нашей компании.
Восстанавливаем надежность тест-результатов
Как тестировщики, мы хотим, чтобы тесты говорили нам, если код продукта ведет себя не так, как мы ожидаем. Во многих окружениях непрерывной интеграции и деплоя (CI/CD) мы привыкли ожидать, что упавшие тесты будут «красными» на дашборде результатов. Красный цвет сообщает, что где-то есть проблема.
Тесты, которые падают время от времени, особенно в областях продукта, подверженных регрессионным дефектам, очень полезны, ЕСЛИ становятся красными по веской причине: когда внедрен дефект, или в тест-окружении произошло что-то неожиданное.
Хорошая практика, когда сначала по нему проходишь сам, а потом уже отдаёшь коллеге в более чистом виде. С ним, кстати, удалось и подтянуть менее опытных коллег — например, они использовали его как шпаргалку, где ожидаемый результат должен быть 400, а где — 404, какие проверки валидны, какие — уже и нет, а какие — следует добавить.
Тестирование персональных предложений
Тестирование персональных предложений критически важно для приложений, применяющих ИИ и предлагающих такую возможность. Эти предложения важны как для Apple Intelligence в iPhone 16.0, так и для других областей, так как применяются для:
- Предложения часто используемых приложений
- Уведомлений на основании времени, локации или деятельности
- Рекомендаций при поиске (приложений и виджетов)
- Интеллектуального ввода текста.
Я разработал детальную тест-стратегию для некоторых подобных задач и выяснил, что кейсов тут очень много – иногда непомерно много. Но, как пытливый тестировщик, я считаю, что очень важно покрыть максимально возможное количество сценариев, тем самым улучшая качество приложения.
В этой статье перечислены основные команды Git, которые должен знать QA-специалист для управления репозиториями GitHub. Как новичкам, так и опытным пользователям будет полезно еще раз повторить базовые повседневные команды.
Как найти настоящую проблему, а не рисовать гипотезы
Каждый день я работаю с самыми разными документами: BRD, пользовательскими сценариями, SRS, UML-диаграммами. В этой серии статей я не собираюсь выдавать сухой чек-лист или заумные определения. Я хочу предложить живой, понятный путеводитель – карту, по которой сможет пройти каждый: будь то начинающий аналитик, тестировщик, проджект-менеджер или просто человек, столкнувшийся с навязчивым ощущением «что-то идет не так».
Риск-ориентированное тестирование по-русски
Когда сроки поджимают, прод не ждет, а баги прячутся где угодно, тестировщик должен действовать стратегически. Вместо того чтобы пытаться проверить всё подряд, разумнее задать себе вопрос: что тестировать в первую очередь? Какие баги реально опасны для бизнеса, а какие можно отложить? Ответ в оценке рисков в тестировании. В этой статье разберём, как выглядит управление рисками в тестировании ПО на практике. Покажем методику, которая экономит десятки часов и спасает релизы, даже если QA-команда работает в одиночку.
Use case и тестовые сценарии: документация страхует бизнес
Перестаньте спорить с заказчиком на тему «что должно работать». Пишите Use Cases как профессионалы: разбираем скрытые ошибки, даем работающие шаблоны, аргументы для руководства против цейтнота и гайд по тестированию для веб-студий.
Тимлид как система: перестать всё тащить на себе
Роль тимлида — это не про задачи, а про ответственность. Раньше можно было открыть таск-трекер и просто работать по списку, а теперь любая проблема становится твоей. Чтобы не утонуть в потоке прилетающих задач, нужна система. Один из простых и действенных инструментов — это визуализация ответственности через «квадраты»: ключевые области, за которые сейчас отвечает тимлид. Эта статья — подробный разбор подхода, который помогает расти без потерь для команды.
Хабр:
О количестве минимальных тестов
В статье рассматриваются способы формального построения тестов и задача минимизации их количества. Приводится пример применения классического метода построения минимального набора тестов и более простой способ — метод нейтрального элемента.
Как спасти проект, если нашли баги перед релизом
Документация есть, тесты написаны, проверки закончили, даже QA не выгоревший. И всё равно за день до выкладки что-то ломается. Мы собрали истории — из больших и не очень команд — о том, как баги всплывают в последний момент и что с этим делать, если вы не Google, а просто хотите выкатиться без боли.
Я тестировщик и два месяца работал без рук. Вот, что я понял
Дело было в Питере ― я шел по брусчатке и оступился. Чтобы сохранить лицо, я пожертвовал руками. Ну и как теперь жить и работать? ― спросите вы. Рассказываю. Спойлер: больничный я не брал.
Нефункциональные проверки мобильных приложений
В этой статье я не только разберу основные нефункциональные проверки, но и расскажу, что происходит с приложением в моменты, когда, например, вы сворачиваете его или выключаете экран – не взаимодействуете с телефоном. Часть тестов применима к обеим платформам, а некоторые актуальны только для Android или iOS. Примеры всех багов взяты из личного опыта тестирования.
Как я перестал бояться тестов и полюбил зеленый CI
Когда-то мой чек-лист «готова ли фича» выглядел как молитва джуна: открыть браузер, нажать пару кнопок, убедиться, что в консоли нет красного цвета (желтое — это нормально, да?), и смело делать merge.
В те времена React был еще зеленым, Backbone уходил в архив, а модные парни на конференциях говорили про какое-то тестирование. Я слушал их как индеец — много слов, мало понимания.
Проект жил быстро, но баги плодились еще быстрее. Каждый хот-фикс тянул за собой новый хот-фикс, как матрешка багов. Я начал бояться рефакторинга сильнее, чем дантист боится собственных зубов.
C каждой розетки про MCP, но давайте по-человечески
Последние месяцы Model Context Protocol (MCP) — буквально из каждого утюга.
YouTube, Twitter, конференции, доки — все жужжат:
MCP — это прорыв, новый стандарт дебага, интеграция AI в тесты нового поколения и прочее.
Звучит круто. Но, как это часто бывает, — всё сложно, перегружено и на птичьем языке.
В этой статье — простой, честный взгляд на MCP: без зауми, с примерами и аналогиями, которые реально помогают врубиться в тему.
Мифический стеклянный потолок в карьере QA
Обычно проблема выглядит так: ты доходишь до определенного уровня и перестаешь понимать, куда двигаться дальше. Возникают сомнения: «я не могу стать руководителем», «я постоянно варюсь в однотипных задачах», «мне некуда развиваться». Это состояние создает ощущение, будто ты столкнулся с невидимой преградой. Я сам сталкивался с такой проблемой и потратил много времени и сил, чтобы ее понять и преодолеть.
Postman + Newman: быстрый старт API-автотестов на практике
Автоматизация тестирования API — задача, с которой сталкиваются даже опытные инженеры, но многие всё ещё предпочитают полагаться на ручные запросы в Postman, а затем переносят их в код — и так годами. Но можно ли избежать этого лишнего шага? В этой статье мы покажем, как настроить эффективную автоматизацию тестов API с Postman и Newman, интегрируя их в процессы CI/CD, чтобы избежать ошибок и повысить производительность.
Гайд по техникам тест-дизайна: нюансы и механики
Проблема в том, что на реальном проекте инженер использует те техники тест-дизайна, которые уже приняты на проекте, исходя из устоявшихся процессов и, как следствие, количества времени на тестирование. Ограниченность тестирования во времени часто не даёт инженерам использовать тот набор техник, который хотелось бы. Из-за отсутствия практики техники, которые изучались ранее, постепенно забываются, и их понимание размывается в восприятии.
Посмотреть:
iOS в VK DeviceHub, или Универсальный провайдер для устройств в ферме ⏱️45 минут
VK совместно с open source-сообществом продолжают активно развивать VK DeviceHub. В этом докладе спикеры поделились ключевыми улучшениями и новыми возможностями.
Как мы тестируем генеративные модели ⏱️45 минут
Сейчас, когда слышишь слова «тестирование» и «генеративные модели» в одном предложении, зачастую речь идет про то, как генеративные модели могут помочь в тестировании. Но генеративные модели кто-то создает, а значит, и тестирует.
Асинхронность в API: как тестировать Webhook ⏱️1 час 15 минут
В рамках курса по тестированию бекэнда.
Обновлённые Гайдлайны для Mobile QA ⏱️20 минут
Главное об обновлениях Material 3 Expressive и Liquid Glass.
