Прекратите писать пошаговые тест-кейсы!

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

Прежде всего, нам нужно понять преимущества написания формальных тестов. Ниже - мои мысли. Можете ли вы придумать какие-нибудь другие?

1. В команду приходит новый член - формальные тест кейсы могут помочь им быстро познакомиться с продуктом.
2. Другие члены команды понимают, что было протестировано.

Карты функций

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

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

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

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

Ценность

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

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

Найдите время на этапе проектирования и освободите свое время для размышлений / вопросов, тогда в долгосрочной перспективе вы сэкономите компании много времени на устранение образовавшегося технического долга.

Тест кейсы не признак качества

• Вы работаете параллельно с членами команды?
• Работаете ли вы вместе, чтобы определить тесты, в которых вам нужно проверить редкие кейсы или влияние регрессии?
• Вы делитесь исследовательскими заметками со своей командой?
• Ваша команда разбирается в тестировании?

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

Накладные расходы на техническое обслуживание

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

Есть и другие вещи, которые вы можете сделать, например, использовать BDD/Cucumber или автоматизировать на ходу - может быть, у вас есть еще какие-то идеи?

Переведено командой QApedia. Еще больше переведенных статей вы найдете на нашем телеграм-канале.