Топ-5 типов замечаний при тестировании системы. Разбираем объективные причины и даём примеры

Вряд ли в мире был хоть один случай тестирования системы без замечаний. Среди них, как и среди требований, попадаются замечания-дичь, но мы разберём объективные и наиболее часто возникающие: их виды, причины и даже примеры из замечаний к тестированию ECM-системы. Спасибо за предоставленный материал ИТ-компании Акелон, чьи аналитики слона съели на этой теме и поделились выдержками из своей Базы знаний.

Дефект – невыполнение требования, связанного с предназначенным использованием и зафиксированного в следующих источниках: документация на систему, проектные решения, тех. проекты, проект тестирования, а также общепринятые документы (например, правила русского языка). К описанию дефектов по программным продуктам могут относиться: нелогичности и несоответствия стандартам, ошибки выполнения команд; по документам – неточности в технологических документах, их несоответствие реальным процессам, ошибки и опечатки и так далее.
Пожелание – предложение об осуществлении чего-либо относительно продукта. Пожелания, как правило, бывают связаны с расширением функциональности элемента, оптимизацией его работы и использования, дополнительным контролем некорректных действий пользователя и т.д. Например, наличие нового типа документа, многоадресные служебные записки.
Новая фича – крупная разработка/кардинальное преобразование в существующих продуктах, которая не является улучшением или пожеланием по развитию существующей функциональности. Например, чат-боты, новый модуль «Закупки», интеллектуальная обработка документов и так далее.

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

ПРИМЕР некорректного требования
Требование: «Специалист должен иметь возможность фильтровать список входящих документов по полю Подписал со стороны корреспондента». В результате разработали фильтрацию по полю Адресат.
В техпроекте написано: «Добавить поле в справочник <наименование справочника>, с возможностью выбора записи из справочника Сотрудники, а в результате разработали обычное текстовое поле / не добавили новое поле / поле недоступно для редактирования и так далее.

2. Некорректно зафиксированное требование. Это тот случай, когда некорректно сформулировано или некачественно проработано требование, либо в процессе появились дополнительные пожелания к продукту и требования неполные (не выявили при проектировании, осознали необходимость на этапе разработки или тестирования); есть ещё противоречащие требования.

ПРИМЕР
Первоначальное требование: сотрудники должны загружаться в систему при интеграции с HR-системой.
В карточке записи справочника Сотрудники должно быть предусмотрено обязательное поле Непосредственный руководитель. Дефект требования в том, что, при попытке заполнить непосредственного руководителя сотрудник может быть еще не загружен из HR-системы, в связи с этим будут возникать ошибки интеграции. Правильнее было сделать поле Непосредственный руководитель необязательным, либо заполнять его после первичной загрузки (поэтапный запуск сеанса интеграции).

3. Некорректное проектирование. Это дефекты, которые могли появиться по причине некачественного проектирования при разработке проектных решений, системных анализов, а также при разработке техпроекта модификаций/интеграции.

ПРИМЕР
В проектных решениях консультант описал бизнес - процесс «Работа с договорными документами» следующим образом: «... После смены состояния документа на Утвержден происходит сеанс интеграции с учетной системой. Передаются следующие данные о договоре: Рег.№, Контрагент, Подписант…». Ошибка в том, что в учетную систему должна попадать информация о договоре в случае, если состояние документа изменяется на Действующий, то есть документ зарегистрирован и подписан с обеих сторон.

4. Наведенные дефекты. Проявляется, когда исправлен один дефект, после чего возникли дефекты в связанных элементах разработки.

ПРИМЕР
Удалили поле Уполномоченное лицо в карточке документа, в результате регламент согласования отрабатывает некорректно, так как в этапе Согласование с уполномоченным лицом исполнитель вычисляется из данного поля.

5. Несоответствие общепринятым нормам. Когда разработка или настройка не соответствует требованиям законодательства, правилам русского языка, нормативным документам, положениям об ЭДО и так далее.

ПРИМЕР
Разработано новое решение, которое включает в себя заключение трудовых договоров. Согласно требованиям проекта ФЗ об участии в эксперименте минтруда система должна поддерживать выгрузку трудовых договоров в необходимом формате. При разработке данное требование не было учтено, выгрузка не была реализована, что противоречит требованиям ФЗ.

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

Топ-5 типов замечаний при тестировании системы. Разбираем объективные причины и даём примеры

Топ-5 типов замечаний при тестировании системы. Разбираем объективные причины и даём примеры

Для начала определимся в какой форме может быть высказано замечание:

Мы выделили пять основных причин для подобного рода замечаний