2020

Как тестировать функционал?

И сразу о главном: самая распространенная ошибка – тестировать весь функционал сразу!

Во-первых, сразу большой объем сложно проверить и проще упустить детали.

Во-вторых, велика вероятность, что что-то окажется не таким, как вы видели в своей голове.

Ну и, в-третьих, многие ошибки как раз и могут оказаться тем самым фундаментом. И на этой ошибке будет построен весь сервис. Понимаете, чем это грозит?

Как проверять частям, ведь есть же поговорка «Дураку пол дела не показывают»?

Не забывайте, что проект не должен создаваться в полной изоляции несколько месяцев, а должен быть разбит на смысловые и функциональные части, которые и следует тестировать по готовности. Напоминаем, что есть скрам — методология разработки. А есть спринт – 2 недельные задачи. Идеальный вариант как раз и состоит в том, чтобы тестировать функционал после завершения каждого спринта.

Итак делу. Как тестировать?

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

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

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

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

Дать задачу, понятную к выполнению (корректные входные-выходные данные) — уже половина успеха!

Рассмотрим пример.

По итогам спринта необходимо было реализовать на сайте корзину.

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

Можете ли вы, как пользователь, протестировать функционал и объяснить, что хотели бы изменить? Конечно!

Другой пример.

Бот для регистрации водителей в Я.Такси

Вход – ФИО, город, водительские права.

Выход – оформленные по стандарту регистрационные данные водителя и правильное распределение нужному куратору в нужный город.

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

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

Итак, выводы:

— Тестировать функционал нужно обязательно!

— Делать это нужно регулярно, проверяя отдельные функциональные «куски».

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

— Давайте разработчикам полную и подробную обратную связь.

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

0 Комментариев

Ваш комментарий