Представим, что вы начинающий тестировщик. Первый день работы, вас знакомят с командой, показывают рабочее место. Вы загружаете свой компьютер и видите программное обеспечение, которое нужно тестировать. Сопровождение этого ПО - это набор требований, которые помогут вам в вашей задаче.
Для тестировщиков существует система, в которой требования классифицируются по тому, как они должны тестироваться. Есть три категории: явные, неявные и скрытые требования.
Явные требования: все, что вы написали. Наш первый тип требований - это явные требования. Это самый простой тип для тестирования. Явные требования чаще всего встречаются в документах, переданных заинтересованными сторонами команде разработчиков. Они могут принимать форму сложной спецификации дизайна, набора критериев приёма или описание каркаса ПО.
Если ПО является тем же, что и описано в явных требованиях, это великолепно. Но что делать в случаях, если нет полной спецификации? Как узнать, что-то является багом или нет?
Первое, что нужно помнить - даже в тех случаях, когда нет явного проектного документа, всегда найдутся явные требования. Их можно искать в сообщениях конечным пользователям о том, какие функции будет исполнять данный продукт. Их обычно можно найти в документации пользователя или в маркетинговых материалах.
Второе, о чем следует помнить – явные требования это еще не все.
Существуют неявные требования: все, что ожидают ваши клиенты. Неявные требования - это второй тип. Это все то, что ожидают пользователи и что не было прописано в явных требованиях. Примеры включают производительность, удобство использования, доступность и безопасность.
Рассмотрим облачный продукт хранения, который позволяет хранить ваши файлы в Интернете. Продукт получает новое явное требование: пользователи должны иметь доступ к частному контенту других пользователей через URL, используя кнопку совместного доступа. Однако при тестировании обнаруживается, что, изменяя значение в сгенерированном URL-адресе, другие пользователи могут просматривать весь доступ к частному контенту пользователя. Это нарушает неявное требование, чтобы только общий контент был доступен другим пользователям, что приводило к ошибке.
Неявные требования иногда называются «нефункциональными». Разумеется, можно охватить бизнес-ожидания по любой из этих «нефункциональных» областей, и в этот момент их можно рассматривать как явные требования.
Но еще есть третий тип: Скрытые требования: все, что будет приятным сюрпризом для клиента.
Скрытые требования представляют собой функции, которые пользователи не ожидают увидеть в используемом продукте, основываясь на своем предыдущем опыте, но при их наличии данное ПО будет выигрывать в сравнении с конкурентами. Пример: система интернет-банкинга имеет анимированный переход, при переводе денег между аккаунтами. Пользователь не ожидал этого, но это поможет ему понять, что перевод был осуществлён успешно, и это круто выглядит, поэтому пользователь в восторге. Другим примером может быть облачная синхронизация в играх : когда видеоигры начали разрешать пользователям доступ к сохраненным файлам игры на любом компьютере, пользователи были удивлены и восхищены этой функцией.
Некоторые веб-сайты будут автоматически заполнять ваше имя пользователя при входе в систему. Некоторые из них не будут. Это пример скрытого требования, которое со временем становится неявным требованием.
Тестирование трех типов требований Зачем делить требования таким образом? Это хороший способ взглянуть на программное обеспечение с разных сторон.
Явные, неявные и скрытые требования тестируются различными способами. Давайте рассмотрим каждый из них по очереди.
Тестирование явных требований. Всякий раз, когда вы сравниваете программное обеспечение с какой-либо письменной документацией, вы тестируете явные требования. Помните, однако, что явное требование обычно подразумевает один или несколько негативных тест-кейсов, которые также должны выполняться.
Когда программное обеспечение не соответствует явному требованию, сначала проверьте,что нужно менять - ПО или документацию. Это может быть либо один вариант, либо сразу оба. Если программное обеспечение достигает стадии тестирования без соответствия его явным требованиям, стоит сделать шаг назад и изучить процесс разработки. Проверка явных требований должна выполняться разработчиком, написавшим код, в идеале путем создания набора автоматических проверок, демонстрирующих, что эти требования выполнены.
Тестирование неявных требований. Это немного сложнее, как в плане обнаружения ошибок, так и в написании отчета об ошибках. Но это тестирование также предоставляет возможность тестировщику помочь в развитии проекта.
Чтобы проверить неявные требования, тестер должен стать экспертом в проблемных аспектах клиента и в технологии, которую ПО использует для решения этих проблем. Использование юзабилити-тестирования может помочь в этом деле.
Когда программное обеспечение не соответствует неявному требованию, отчет об этом сбое также должен содержать объяснение, почему клиент ожидает, что программное обеспечение будет вести себя по-разному.
Тестирование скрытых требований. Тестирование для скрытых требований является самым сложным из всех, потому что невозможно догадаться, каковы эти требования, пока вы не освоите ПО. Чтобы проверить эти требования, тестеры должны глубоко понимать предпочтения клиента, но при этом помнить, что они сами не являются клиентом.
Методы исследований UX могут помочь улучшить ваше понимание этого. Узнайте, как клиенты фактически используют программное обеспечение и используйте эту информацию для разработки сценариев для выявления скрытых требований. Помните также, что конечные пользователи не всегда знают все возможности используемого продукта и могут попросту не пользоваться некоторыми функциями.
Когда программное обеспечение не соответствует скрытому требованию, это представляет собой возможность улучшить продукт. Но это также допускает возможную дополнительную незапланированную работу. Команда с нефиксированным механизмом для внедрения новых скрытых требований создаст более удовлетворительный продукт и получит больше довольных клиентов.
Тестирование - это больше, чем проверка явных требований. Возможно, заманчиво видеть работу по тестированию как сравнение между спецификацией и фактическим ПО. Однако хороший тестировщик - это тестировщик, который глубоко понимает те неявные и скрытые требования и знает, как их тестировать. Плюс, это намного интереснее и совершенно не делает работу тестера рутинным занятием.
2 августа/2018
