Home

Автор: Маарет Пюхяярве (MaaretPyhäjärvi)
Оригинал статьи
Перевод: Ольга Алифанова

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

"Если единственный известный вам инструмент – это молоток, все становится похожим на гвоздь".

Мы можем добавить следствие, развеивающие иллюзии исследовательского тестирования:

"Не то чтобы все было похожим на гвоздь, но мы способны замечать только гвозди".

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

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

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

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

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

• Изменение: начиная с базовой черты, на которой код работал, я часто получаю в тестирование то, что находится на уровне код-коммита в ствол (или то, что вот-вот отправится в ствол).
• Стори: начиная с предположительно вертикального среза фичи, юзер-стори. По моему опыту, люди плохо работают в команде с разработкой, основанной на стори, и эта абстракция редко доступна, даже если о ней часто говорят как об уровне старта для Agile-команд.
• Фича: начиная с ценности в глазах пользователей, чтобы все мы воодушевились идеей внедрения новой функциональности.

Для эвристики воспоминания на уровне стори мне очень нравится то, что предложила Анна-Мария Шарре. В то же самое время я редко вижу разработку на основе стори – ценными в моем контексте считаются бэклоги (фичи и возможности), а стори-формат не считается важным.

Воспоминания на уровне изменений

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

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

Иногда это случается при пулл-запросе – кто-то вносит изменения и просит разрешения залить их в ствол.

Иногда это происходит, когда видишь, что пулл-запрос одобрен и доступен в тест-окружении.

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

Что я тут вспоминаю:

• Намерение: что должно было измениться?
• Масштаб: насколько изменился код? Концентрированно или рассеянно?
• Отпечаток: чье это изменение, чем знаменит автор?
• Работа: как мне увидеть изменение в деле?
• Вокруг: как мне убедиться, что другие потенциально связанные вещи все еще работают?
• Обучение: где мы можем найти информацию об этом? Документация, доменный анализ, контакты с заказчиком.
• Архитектура: что эта фича значит для нас, что меняется, что добавляется, что остается.
• Функциональность: что она делает, в чем ее ценность? Как можно отслеживать ценность?
• Парафункциональность: не просто работает, но как работает – удобство использования, доступность, безопасность, надежность, производительность…
• Данные: какая информация сохраняется временно, постоянно, и где. Как мы создаем нужное нам в терминах данных?
• Окружение: на что она полагается? Как можно рассмотреть это по частям и где?
• Заинтересованные лица: люди, чье мнение важно. Не только пользователи и заказчики, но и служба поддержки, технические писатели, бизнес-менеджмент.
• Жизненный цикл: фичи связаны с процессами во времени. Не однократно, а множество раз.
• Интеграции: другие вещи, на которые мы опираемся.

Воспоминания на уровне фичи

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

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

Иногда это происходит при парной работе – мы генерируем идеи, что бы мы хотели протестировать.

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

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

Обсудить в форуме