Автор: Баз Дейкстра (Bas Dijkstra)
Оригинал статьи
Перевод: Ольга Алифанова

«Ну, на моей машине все работает».

Я уверен, что каждый из нас слышал такую фразу от разработчика в какой-то момент своей карьеры, и все мы в ответ закатывали глаза. Очевидно же, что не работает оно на твоей машине…

Было бы хорошо применять эту же философию «это должно работать не только у меня» и к нашим тестам: каждый в команде должен иметь возможность запускать их. Автоматизация тестирования — это прежде всего быстрая обратная связь, а она возможна только тогда, когда запуск тестов быстр, плавен и не сбоит.

Автор: Никита Филонов
Оригинальная публикация

Введение

Когда мы начинаем погружаться в нагрузочное тестирование, первая мысль обычно такая: «Сейчас я напишу сценарий, запущу кучу виртуальных пользователей — и вот она, настоящая нагрузка!». Но очень быстро приходит понимание: без подготовленных данных результаты будут далеки от реальности.

Здесь на сцену выходит сидинг (от англ. seeding). Это понятие часто вызывает вопросы у начинающих инженеров по тестированию производительности: «Что это за зверь такой и зачем он нужен?». На самом деле, сидинг — один из тех невидимых, но критически важных этапов подготовки, от которого напрямую зависит качество и честность ваших нагрузочных тестов.

В этой статье мы разберёмся:

• что такое сидинг и почему без него нагрузочное тестирование часто "врет";

• какие бывают подходы к подготовке данных;

• почему правильный выбор метода сидинга может сэкономить вам часы (а иногда и дни) отладки;

• и что делать, чтобы ваши сценарии выглядели как реальная работа пользователей, а не как набор искусственных действий.

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

В предыдущей части мы рассмотрели, чего хочет бизнес: продукт с высокой ценностью и низкими затратами на разработку. На этот раз мы посмотрим на ситуацию под немного другим углом: как бизнес получает то, чего он хочет?

Привет, меня зовут Андрей и я автоматизатор (остальные в кругу хлопают в знак сочувствия) в hh.ru. В статье расскажу, как мы ввели карантин автотестов, повысив стабильность релизов и скорость доставки.

Автор: Ханиша Арора (Hanisha Arora)
Оригинал статьи
Перевод: Ольга Алифанова

Вы — начинающий тестировщик? Работать над приложением в команде из пяти и более разработчиков может показаться надёжным способом создать продукт без багов. Но правда в том, что количество разработчиков в проекте никоим образом не влияет на итоговое число ошибок.
Как бы ни был опытен разработчик — баги всё равно случаются. Не существует такого понятия, как «идеальный продукт».

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

Не все стратегии охоты на баги требуют прокачки технических навыков (хотя развитие в этой области, безусловно, должно быть вашей целью). Иногда даже простые приёмы, которые могут показаться лайфхаками, способны значительно повысить вашу эффективность при поиске багов.

Вот несколько таких техник, которые, по моему опыту, приносят хорошие результаты.

Автор: Никита Филонов
Оригинальная публикация

Вступление

В нагрузочном тестировании есть один коварный момент, который встречается даже у опытных команд: берут «красивый» сценарий (например, тысячу виртуальных пользователей), запускают его, получают кучу графиков — и считают задачу выполненной. Звучит солидно, но толку от этого примерно как от стрельбы из лука с закрытыми глазами: попасть можно, но это больше про удачу, чем про инженерный подход.

Правильный профиль нагрузки — это не просто цифра в настройках. Это ответ сразу на три вопроса:

• Что мы нагружаем (какие сервисы или сценарии),

• Как мы нагружаем (параметры, последовательность, интенсивность),

• Почему именно так (данные, прогнозы или требования).

Цель этой статьи — дать практические рекомендации, которые помогут правильно выбрать профиль нагрузки и сделать тестирование осмысленным и полезным, а не просто «запуском ради отчётности».

Игнорировать эти вопросы — значит рисковать превратить тест в дорогую демонстрацию красивых графиков без реальной пользы.

Автор: Эди Стоукс, Рабай’а Браун (Ady Stokes, Rabi'a Brown)
Оригинал статьи
Перевод: Ольга Алифанова

Синие экраны — это только начало

Пока большая часть мира восстанавливалась от «чёрного лебедя» — масштабного сбоя, связанного с CrowdStrike и Azure, — команда Ministry of Testing решила поделиться несколькими лёгкими и забавными историями о том, как любимые устройства (и маломощные рабочие ноутбуки) умирали или просто притворялись мёртвыми.

Примечание: некоторые из вас, возможно, никогда не видели печально известный "синий экран смерти" Windows, который мы здесь будем иногда называть BSoD (Blue Screen of Death). Читайте дальше, чтобы узнать подробности.

Задача любого тестировщика — проверять продукт на соответствие установленным требованиям и своевременно отлавливать любые баги и ошибки. В идеальных условиях или небольших проектах эта схема работает безотказно. Но в ситуациях, когда над продуктом работает несколько команд разработки, в релизы попадает по 30–70 задач, а обновления выкатываются каждую неделю, фокуса тестировщиков может просто не хватить. В таких условиях не обойтись без Quality Gates.

Меня зовут Юлия Садовникова. Я старший специалист по тестированию в команде Core Android компании ОК. В этой статье я расскажу о Quality Gates в ОК и о том, как QA может не просто тестировать, а реально влиять на проект и процессы.