Слить часы тестировщика на этапе разработки проекта — проще простого. Для этого нужно после каждого рывка (спринта) предоставлять сборку (билд), не обозначая те части проекта, которые еще не готовы. Тестировщик начнёт проверять, не зная, что готово, а что нет. В ответ получите много сообщений об ошибках. Правда часть этих ошибок, на самом деле, — не ошибки. Разработчики ещё не дошли до этой части проекта.
Как этого избежать?
Подсказка пришла во время чтения книги Владимира Завертайлова «Настольная книга project-менеджера»
Для программистов, если они не шарлатаны, уже привычно работать итерациями. Какая-то функция на экране готова. Какая-то — нет. В новых версиях в каждый спринт, добавляется что-то новенькое. Но в целом можно уже посмотреть, как ведет себя продукт. Чтобы не возникало вопросов, что уже готово, а что — нет, рекомендую использовать метод красной рамки.
Автор предлагает создать новый стиль, который применяется к элементам интерфейса, которые ещё не готовы:
Суть в том, что прописывается специальный стиль (например.todo), выводящий тонкую красную рамку вокруг нужного нам элемента. Этот стиль присваивается тем компонентам интерфейса — кнопкам, полям, формам и т. д. — которые отражаются на экране, но еще не реализованы в коде. Таким образом наглядно видно, что в данный момент готово, а что — нет.
На демонстрации клиенту не нужно напоминать: «Это ещё не сделано... сюда не смотрим...»
Почему это работает?
Во-первых, красная рамка сразу привлекает внимание. Это мета-сообщение, смысл которого — это ещё не готово, нет смысла тратить время.
Во-вторых, сокращает время на тестирование. Зашли, проверили то, что доступно. Команда знает, на каких элементах сосредоточиться.
В ближайшем проекте планирую внедрить этот метод. Ожидания, что это сократит время, затрачиваемое на тестирование функционала, который еще не доделан. Это поможет разграничить баги от того, что ещё не сделали. Сосредоточиться на том, что нужно проверять.
Итак, выводы:
— метод красной рамки даёт заказчику возможность увидеть, что готово, что нет. Экономим время на объяснениях вроде «сюда смотрите, сюда — нет, потому что ещё не готово».
— тестировщики не тратят время на проверку не сделанного функционала, они его сразу замечают благодаря красной рамки.
— легче контролировать процесс разработки итерациями, видно — совпадает ли план и фактическая реализация функционала.
***
Если вы только начинаете свой первый виар-проект, то рекомендую прочитать подборку «Создавая свой проект» на этом канале. В нём я собираю инструментарий, которым регулярно пользуюсь сам при ведении проектов.
Также, подписывайтесь на телеграмм-канал Запуск виар-проектов, если вам удобно следить за обновлениями в этой социальной сети.