Home

Опубликован выпуск рассылки за начало июkя.

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

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

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

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

Меня часто спрашивают об идеальном соотношении разработчиков и тестировщиков. Я всегда отвечаю, что это зависит от контекста. Хорошее соотношение тестировщиков и разработчиков определяется рядом факторов. Тут надо подумать о том, работаете ли вы с последней технологией или с давно существующим продуктом, о таланте и опыте членов команды, и об ожидаемом ритме релизов. На самом деле сработать могут самые разнообразные соотношения, но у каждого есть достоинства и недостатки. Разберем несколько примеров.

Автор: Анастасия Макеева
Оригинальная публикация

Автор: Филип Рик (Filip Hric)
Оригинал статьи
Перевод: Ольга Алифанова

Если вы используете Cypress, то, возможно, знакомы с цепочками команд. Так ли это? Я вижу, что многие пользователи Cypress знают об этом, но иногда не улавливают их внутреннюю логику.

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

Автор: Денис Бесков

Введение

Требования к качеству, несмотря на свой небольшой размер, очень сильно влияют на реализуемость всей совокупности требований, на трудоёмкость, длительность и стоимость реализации, а следовательно окупаемость инвестиций в разработку и в целом возможную успешность проекта.

Это та причина, по которой многие подрядчики стараются избегать таких требований, как огня, что перекладывает риски во времени на более поздние этапы и на заказчика.

Но в мире честных, открытых отношений выгоднее заранее обсудить эти аспекты, чем потом с удивлением спорить при сдаче, что система тормозит, в ТЗ про это ничего не сказано, «вы же профессионалы» и всё такое.

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

При этом остаётся прагматический вопрос — а что именно писать в требования, чтобы они были полезными, измеримыми, реализуемыми?

С точки зрения системной инженерии, требования к качеству программной системы являются разновидностью системных ограничений (constraints) и в этом они отличаются от требований к способностям (capabilities) системы, в мире ИТ обычно называемых «функциональными».

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

Давайте попробуем сделать это хотя бы ремеслом.

Автор: Джеймс Бах (James Bach)
Оригинал статьи
Перевод: Ольга Алифанова

Этот вопрос возник в ходе недавнего онлайн-тренинга Rapid Sofware Testing Explored. Донатас сказал "Предположим, мы нашли проблему в приложении или самом процессе разработки. Однако она не получает должного, с нашей точки зрения, внимания. Как убедить остальных? Что рекомендуется для взаимодействия с разработчиками, менеджерами и продакт-оунерами в этом случае?"

Это одна из больших проблем  0в тестировании. Как тестировщик, вы находите проблемы. Однако, если ваши клиенты не согласны с вами  в определении проблемы, вас не будут расценивать, как значимого члена команды. Вы станете печальным привидением, слоняющимся по чердаку.

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

Бытует мнение, что простейший путь к IT лежит через тестирование. Мол, знать ничего не нужно, уметь и подавно, достаточно желания и готовности не сильно щуриться от боли и слёз, когда тебе прилетает очередной набор тест-кейсов для регрессионного тестирования.

Отчасти это даже правда, но, скорее, для ситуации, которая была на рынке лет 10 назад. Сейчас же всё обстоит несколько иначе. Причин для этого масса, и они самые разные. Если отметить ключевые, то, пожалуй, это:

Возросшие требования к тестировщикам, их знаниям и квалификации, так как всё чаще решаются задачи чуть сложнее, чем «клик-клик — и в продакшен». Работа тестировщиков становится всё более «инженерной», требует технической подкованности, специфических знаний, навыков и компетенций. Тестировщики всё чаще становится QA-инженерами (кто в теме, тот понимает разницу).

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

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

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

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

На экране настроек этой функции для администратора в правом верхнем углу есть кнопки "Сохранить" и "Отмена". Эти кнопки не привязаны ни к каким клавишам. Пользователь должен или кликнуть на них мышкой, или перейти на них табуляцией и нажать Enter.