Автор: Рикард Эдгрен (Rikard Edgren)
Оригинал
Перевод: Ольга Алифанова

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

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

Автор: Ричард Брэдшоу (Richard Bradshaw) и Сара Дири (Sarah Deery)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

Автор: Рикард Эдгрен (Rikard Edgren)
Оригинал
Перевод: Ольга Алифанова

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

Автор: Рикард Эдгрен (Rikard Edgren)
Оригинал
Перевод: Ольга Алифанова

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

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

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

Автор: Рикард Эдгрен (Rikard Edgren)
Оригинал
Перевод: Ольга Алифанова

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

Это общие характеристики, служащие богатым источником триггеров для идей по тестированию любого приложения. Некоторые из них вам не подходят, некоторые легко удовлетворить, а некоторые очень важны и сложны. См. материал для печати на следующих страницах для подробного списка вдохновляющих концепций в областях Возможностей, Надежности, Удобства использования, Харизмы, Безопасности, Производительности, IT-руемости, Совместимости, Поддерживаемости, Тестируемости, Ремонтопригодности, Портируемости. Никаких чисел к этим описаниям не дается, метрики опасны, так как скрывают то, что на самом деле важно.

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

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

Автор: Рикард Эдгрен (Rikard Edgren)
Оригинал
Перевод: Ольга Алифанова

Аналитическая ^[1]часть тест-дизайна отвечает на вопрос, что нам надо протестировать. Это включает идентификацию и изучение различных информационных источников, а также искусство выяснения, что важно или может быть важным.

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

Автор: Назина Ольга

Что такое предварительные шаги тест-кейса

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

Предварительные шаги — это все то, что поможет нам пройти тест-кейс, но прямого отношения к текущему тесту не имеет. Например, регистрация.

Автор: Рикард Эдгрен (Rikard Edgren)
Оригинал
Перевод: Ольга Алифанова

Часть 1
Часть 2

Мы рекомендуем постоянно собирать идеи для тестов из разнообразных информационных источников.

Посмотрите на нижеуказанные моменты, и подумайте о ценностях, рисках, возможностях; найдите возможность быстро покрыть значимые вещи.

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

Практическая тестируемость продукта – это то, насколько легко его тестировать определенному тестировщику, который следует определенному тест-процессу в заданном контексте. Практическая тестируемость – функция пяти других "тестируемостей" – проектной, ценностной, субъективной, внутренней, и эпистемологической (также известной, как "разрыв риска"). Как и в случае с качеством в целом, тестируемость – пластичная, многомерная концепция, которую невозможно внятно выразить при помощи одной метрики. Однако проблемы тестируемости и эвристики для ее улучшения вывести можно.

Автор: Кассандра Ланг (Cassandra H. Leung)
Оригинал статьи
Перевод: Ольга Алифанова

Это третья часть мини-цикла статей "Тестирование в реальной жизни", нацеленного на то, чтобы поделиться практическим опытом тестирования на основании реальных примеров. Этот цикл зародился из наблюдения, что множество ресурсов, с которыми я сталкивалась, концентрируются в основном на теории, а информации о том, как это реально делается или как к этому приступать, немного. Информация, которой я делюсь в этом мини-цикле, основана на моем недавнем опыте – я помогала в первичном тестировании мобильного приложения.

В этой статьей я опишу интересные баги, которые я нашла, тестируя довольно скучную штуку – экранную клавиатуру.

Часто ли вы задумываетесь о тестировании методов ввода? Клавиатура, мышь, тач-скрин, загрузка, камера, или что угодно иное – все это методы ввода, а ввод - важная часть практически всех приложений. Так как экранная клавиатура обычно рассматривается как часть устройства (к примеру, смартфона или планшета), или даже как отдельное приложение – вы, возможно, не планируете тестировать ее в ходе проверки использующего такую клавиатуру приложения. Однако я неоднократно обнаруживала, что тестировать экранную клавиатуру в приложении надо так, как будто бы она неотъемлемая часть вашего продукта. Неважно, как вы это назовете – интеграционным тестированием или каким-то иным. Важно, что пользователи заметят, если клавиатура криво работает с вашим приложением, и все нежелательные варианты поведения могут повлиять на их решение пользоваться приложением впредь.