Стала известна программа конференции Heisenbug 2023 Spring. Конференция пройдет 11-12 апреля (онлайн) и 16-17 апреля (Москва + онлайн), и теперь на ее сайте уже опубликованы описания большинства докладов (возможны небольшие дополнения). Приведем здесь названия блоков программы и примеры некоторых тем из этих блоков:

— Инструменты и фреймворки: упрощение работы с помощью консоли DevTools, использование Allure-Go и Playwright, сравнение ChatGPT со статическим анализатором.

— Мобильное тестирование: тестирование производительности и UI, работа с приложениями на Flutter, фермы устройств, Marathon test runner.

— Нагрузочное тестирование: и о самой нагрузке, и правильной интерпретации полученных результатов, и о дальнейших шагах.

— Тестирование UI: использование Android UI-автотестов на игровых десктопах, UI-тесты для постоянно меняющихся страниц, практики хороших UI-тестов

— Прочее: безопасность (специфические атаки на интернет-банкинг), best practices (как сделать тесты переиспользуемее), а также немного космонавтики (астроном Владимир Сурдин расскажет о тестировании марсоходов).

Если захотелось узнать о любой теме подробнее или приобрести билет, все это можно сделать на сайте. Напомним, что для наших читателей есть промокод SOFTWARETESTING со скидкой на персональные билеты. А еще, кроме Heisenbug, в апреле-мае пройдет ряд других конференций от JUG Ru Group. Можно приобрести единый билет-абонемент Full Pass, и промокод распространяется на него тоже.

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

Ранее я писала, как убедиться, что вы действительно нашли баг, прежде чем его заводить; как исследовать баг; и как написать баг-репорт, когда баг исследован. Но я никогда не писала о том, как добиться, чтобы баг исправили. Даже если вы зарепортили тщательно детализированный и внятно описанный баг, разработчик или команда все же могут решить, что он не достоин исправления. В этой статье мы разберем пять вещей, которые можно предпринять, чтобы помочь багу исчезнуть.

Оригинальная публикация

Как быть тестировщику, если на проекте нет аналитика и спецификации? Маша Кузнецова, младший QA-инженер red_mad_robot, рассказывает о трёх возможных вариантах действия — осторожном, умеренно рискованном и максимально упоротом. Будет особенно полезно QA начального и среднего уровня — чтобы не растеряться, попав в похожую ситуацию.

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

"К коду тестов нужно относиться так же, как и к коду продукта".

Недели не проходит, чтобы кто-нибудь об этом не заявил в докладе, статье, посте на LinkedIn.

Я согласен. Вы должны обращаться с кодом тестов так же, как и с кодом продукта. Проблема тут в том, что просто заявить "вы должны" недостаточно, чтобы это магическим образом произошло за одну ночь. К сожалению, я крайне редко вижу, чтобы сказавший это человек поделился практически применимыми советами, как же обращаться с кодом тестов аналогично коду продукта.

Автор оригинала: David Tzemach

Митап пройдет на сайте IT_One — 14 марта в 18:00.

Спикеры IT_One расскажут об автоматизации тестирования: от построения стратегии до выбора инструментов и пошагового плана внедрения автотестов.

В программе:

— Алексей Антонов, «Стратегия автоматизации тестирования и надо ли писать код?».

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

— Сергей Аккуратов, «Как минимизировать риски при внедрении автоматизации тестирования? Строим пошаговый план».

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

Вы сможете задать вопросы спикерам и подискутировать с другими участниками. Авторы четырех лучших вопросов получат футболки. Также разыграем комплект мерча от IT_One среди тех, кто пройдет опрос и оставит отзыв о митапе. Опрос отправим на почту всем участникам после окончания митапа.

Участие бесплатное. Достаточно зарегистрироваться: https://it-one.jugru.org/

Автор: Ли Хокинс (Lee Hawkins)
Оригинал статьи
Перевод: Ольга Алифанова

Конфликт, возникающий при рассказе о проблемах исследовательского тестирования

Мы, как тестировщики, хотим найти и описать то, что, с нашей точки зрения, является важной проблемой. Эти проблемы могут угрожать ценности тестируемого продукта. Заинтересованные лица могут не особенно стремиться знать о них, потому что выявление таких проблем может порушить существующее расписание и привести к трудным разговорам с менеджером проекта. Некоторые разработчики могут воспринять это, как личный выпад – особенно если мы сообщаем о проблемах в терминах области кода, которая их, возможно, вызвала, не говоря о том, как эти проблемы угрожают ценности продукта.

Автор: Алексей Никитин, Visiology CEO, https://www.linkedin.com/in/alexey-nikitin-5aa09869/

Технологии Agile, Scrum и CI/CD становятся общепринятой нормой, и нам уже кажется, что новые релизы всегда можно выпускать постоянно, практически непрерывно. Технически, сейчас действительно есть реальная возможность выкатывать обновления каждый день, а некоторые разработчики готовы релизиться каждый час — для web- и мобильных приложений это совершенно нормально. При такой частоте возникает вопрос: на сколько хорошо должна быть отлажена система автоматизированного тестирования? Цена ошибки в таком релизном цикле невысока, а компания получает возможность переложить финальное тестирование на плечи своих клиентов. Если у кого-то что-то пошло не так, можно моментально выпустить исправление. Но возможен ли такой подход в разработке корпоративной BI-системы? Об этом и поговорим сегодня.