Home

Автор: Юлия Нечаева

Часто задают вопрос: как быть с тем, что программисты не любят тестировщиков, считают их работу второстепенной, пишут неряшливо – «все равно ведь проверят» либо мстят за каждый найденный баг и пытаются не признавать их за баги.
Или наоборот, программисты жалуются, что тестировщики злорадствуют, найдя баг, и считают личным достижением, если программист наделал много ошибок.

Cтандартные в таких случаях советы: объясняйте, мирите, аргументируйте, — выглядят, как будто перед программистами оправдывают существование тестировщиков. Постфактум решать такую проблему (а это очень критичная проблема) очень трудно. Нужно закладывать правильную атмосферу при построении команды и носить это правильное отношение к работе за собой из команды в команду, из компании в компанию.

4 июня AgileDays отправился в путешествие на Урал, а точнее в Екатеринбург!

Конференция прошла в Новотеле при количестве 180 участников из различных городов: Челябинск, Михайловск, Магнитогорск, Москва, Санкт-Петербург, Оренбург, ну и собственно из Екатеринбурга. Компании были представлены разные: Naumen, Восточный ветер, СКБ Контур, Меткомбанк, Максимал, Яндекс и многие другие.

На конференции была комфортная, уютная и непринужденная атмосфера. Многие участники пришли на конференцию узнать, что же такое все-таки Agile, поговорить с теми, кто уже использует методологию. Всем участники могли познакомиться друг с другом, поделиться опытом, рассказать о своих проблемах внедрения Agile/Scrum и том, как они решались.

Началась подготовка к конференции SQA Days 8, которая пройдет в Санкт-Петербурге поздней осенью. Точные даты и место проведения пока уточняются. А тем временем сообщество тестировщиков Санкт-Петербурга, выступающее в роли со-организаторов, уже призывает добровольцев, желающих помочь в проведении конференции. Во-первых, добровольцы требуются в качестве ведущих секций и для работы на стойке регистрации. Во-вторых, самая разная помощь может потребоваться в процессе подготовки конференции. Подробнее узнать о том, какие обязанности будут возложены на волонтеров, и оставить заявку на волонтерство, можно на сайте сообщества тестировщиков Санкт-Петербурга.

Один из самых увлекательных докладов на прошедшей конференции SQA Days 7 -- рассказ Юли Нечаевой о тестировании игр. Чем занимаются тестировщики в компаниях, производящих компьютерные игры? Действительно ли они играют на работе? Да, играют, конечно. Но каково это, проходить по сотне раз одни и те же предписанные сценарии? Чем ещё они занимаются? Что лучше -- нанимать тестировщика и учить играть, или нанимать игрока и учить тестировать? Что можно автоматизировать, а что приходится тестировать вручную? Конечно, за сорок минут невозможно раскрыть все секреты тестирования игр, но Юля постаралась выделить самые главные особенности.

19 мая по инициативе Ростислава Яворского (Microsoft Research) и сообщества Гуру на Урале состоялся онлайн-семинар, на котором  Алексей Баранцев выступил с докладом на тему "Обзор методов анализа программ". Семинар нацелен главным образом на студентов и аспирантов.

Доступна запись семинара (~2 часа) и слайды.

Аннотация:

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

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

Автор: Gojko Adzic
Перевод: Дмитрий Дудников по заказу Software-Testing.RU
Оригинальная публикация

Я сейчас пишу новую книгу и в связи с этим опрашиваю множество команд, внедривших приемочное тестирование. Большинство из уже опрошенных не в одном, так в другом месте наступали на грабли при автоматизации тестирования пользовательского интерфейса (UI). Пообщавшись несколько недель назад на Agile Acceptance Testing Days в Бельгии с некоторыми участниками, которые как раз опасно приблизились к тому месту, где спрятаны грабли, я хочу представить вашему вниманию хорошие, на мой взгляд, подходы к автоматизации UI-тестирования.

Некоторое время назад я уже высказывался против автоматизации тестирования пользовательского интерфейса, поэтому не буду повторяться. Однако многие из команд, с которыми я общался, судя по всему, предпочитают автоматизацию именно на этом уровне, или думают, что для подтверждения требуемой бизнес-функциональности необходимо тестирование на этом уровне. Почти все эти команды через 6-9 месяцев после первых попыток автоматизации обнаруживали, что цена поддержки UI-тестов больше, чем получаемая от них выгода. Многие в этот момент забрасывали свои тесты и благополучно теряли вложенные в них усилия. Если вам все-таки необходимо выполнить автоматизацию UI-тестов (в чем я сильно сомневаюсь), то ниже вы найдете рекомендации, как сделать так, чтобы в дальнейшем цена их поддержки не оказалась слишком высокой.