Home

Автор: Джеймс Бах (James Bach)
Оригинал статьи: https://www.satisfice.com/blog/archives/5290
Перевод: Ольга Алифанова

Рим был построен не за один день, но хватило всего шести дней, чтобы он по случайности сгорел дотла в 64 году нашей эры. Он был заново отстроен с учетом пожарной безопасности. А когда в 1903 году при пожаре в театре "Ирокез" в Чикаго погибло 502 человека, уже в 1904 году нормы пожарной безопасности повысились. Пожар на фабрике "Трайангл" в Нью-Йорке (146 погибших) привел к основанию Нью-Йоркского Бюро пожарной безопасности, а Национальная Ассоциация Пожарной Безопасности сейчас поддерживает несколько сотен различных норм и требований – и многие из них появились вследствие особо трагичных пожаров. Люди учатся на трагедиях.

Опубликован очередной выпуск рассылки за вторую половину июля.

В выпуске собраны ссылки на новые статьи, слайдкасты, отобраны самые интересные публикации в ленте блогов и темы на форуме.

Содержание рассылки доступно по ссылке.

Подписаться на рассылку

Вы тест-менеджер, ведущий тестировщик или только планируете ими стать?

Значит, вам должны быть знакомы такие ситуации:

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

> Узнали в чём-то свою команду?

> Устали ломать голову и искать теоретическое решение?

> Хочется реальной практики: с кейсами, инструментами и отработкой в деловых играх?

Двухдневный интенсив от Натальи Руколь и Анастасии Смирновой
«Позитивное управление тест-командой»
пройдет 29-30 августа в Санкт-Петербурге
и 16-17 сентября в Киеве.

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи: http://thethinkingtester.blogspot.com/2018/09/usability-and-accessibility-testing.html
Перевод: Ольга Алифанова

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

В конце марта в питерском офисе Wrike прошел Allure server meetup. В несколько часов удалось поместить концентрированную информацию по новому инструменту Allure server, по современным практикам работы с тестовой документацией и автотестами и по интересному опыту взаимодействия тестирования компании Wrike и нового вендора на рынке TMS систем.

Антон Башкиров (Wrike QA Lead) рассказал про концепцию и сам продукт Allure server, про то как наши потребности в быстрой и дешевой тестовой документации и централизованной работе с ней срастались и взаимно проникали с идеями команды qameta.io. Обрисовал дальнейшие наши планы по работе с Allure server.

Иван Варивода (Wrike QA automation) осветил очень важную для нас историю тестового карантина, позволяющего поставить на поток вывод из запусков, починку и возвращение стабилизированных автотестов. Опять же, это решение, построенное сначала отдельно от Allure server, и интегрированное в эту систему в коллаборации с разработчиками.

Для тех, кто не смог прийти, под катом публикуем видеозаписи докладов.

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

В прошлый раз я отвечал своей клиентке, тестировщице, работающей в организации, одержимой тест-кейсами. Назовем ее Фрида. У нее были другие вопросы насчет того, как отвечать своим тест-менеджерам.

Что, если они захотят, чтобы другой человек прогнал мои тесты, если я недоступна?

- Ваши тесты, или ваше тестирование? – спросил я.

- Насколько я понимаю, мои тесты. Я несогласна с этим, но пытаюсь посмотреть на вопрос с их точки зрения, - ответила Фрида.

Автор оригинала: Hillel Wayne

Оригинальная публикация
Перевод статьи

Должен признаться: я читаю ACM Magazine. Это делает меня «ботаником» даже по меркам программистов. Среди прочего, я узнал из этого журнала о «метаморфическом тестировании». Раньше я никогда о нём не слышал, как и все люди, которых я спрашивал. Но научная литература по этой теме на удивление объёмна: есть множество невероятно успешных примеров её применения в совершенно разных областях исследований. Так почему же мы не слышали о нём раньше? Существует только одна статья для людей вне научных кругов. Пусть теперь их будет две.

Автор: Энди Найт (Andy Knight)
Оригинал статьи
Перевод: Ольга Алифанова

Люди довольно серьезно настроены в отношении BDD. Я часто слышу, скажем, такие мнения:

"Зачем мне использовать BDD-фреймворк вместо традиционного – например, JUnit, NUnit, pytest? Дополнительный уровень шагов Gherkin мешает коду автоматизации, и вместо него я могу напрямую писать код для этих шагов. BDD-фреймворки требуют кучу лишней работы, а толку от этого никакого. Моя команда все равно не пользуется практиками разработки через реализацию поведения".

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