Home

Оригинал статьи: http://www.testingexcellence.com/bad-requirements-software-testers-nightmare/

Автор: Намита Коли Арора (Namita Kohli Arora)

Перевод: Ольга Алифанова

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

"Плохие требования" – довольно широкое понятие. К примеру, это могут быть:

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

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

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

• Используйте шаблоны и HTML-макеты. Шаблоны и макеты могут послужить альтернативой спецификации. Используйте их как визуальное представление того, что ожидается от тестируемого приложения. Рабочий макет может также помочь понять развитие базовых сценариев. Если ваши макеты статичны, попробуйте построить из них сценарий пользователя. Не забудьте подтвердить свое понимание работы системы, посоветовавшись с командой разработки и бизнесом.

• Обсуждения, переписка, встречи. Если требования неполны, информация, полученная путем переговоров и встреч, поможет вам заполнить нужные пустоты. Тестировщики должны проактивно участвовать в таких видах деятельности – это хорошая платформа для того, чтобы задать нужные вопросы. Не забудьте письменно зафиксировать результаты таких встреч. IBM’s Rational, Atlassian’s Confluence и другие аналогичные инструменты помогут вам создать репозиторий для такой информации.

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

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

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

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

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