Интересуетесь бизнес-анализом в ИТ? Приглашаю Вас ознакомиться с моей книгой "Профессия "бизнес-аналитик". Краткое пособие для начинающих" , которая вышла в издательстве "Олимп-Бизнес": https://taplink.cc/vdm_mrnv .
Из предыдущих статей на тему бизнес-анализа в ИТ мы знаем, что бизнес-аналитик (БА) может принимать участие в процессе тестирования ПО. Как правило, это участие выражается в содействии бизнес-аналитика при подготовке сценариев тестирования. Это логично: БА больше других участников проектной команды общается с бизнес-заказчиком и может посмотреть на программный продукт глазами конечного пользователя. Таким образом БА помогает тестировщикам оценить наиболее вероятные действия пользователя в Системе и риски возникновения ошибок. Кроме того, БА, понимая специфику работы Заказчика, может выдвигать свои предложения по пользовательскому интерфейсу и изменению бизнес-логики системы.
Но что, если в команде нет специально выделенного инженера по тестированию? Более того, что если вся команда проекта, это разработчик, аналитик и РП? Это значит, что функцию тестирования аналитику и разработчику придётся делить между собой. Далее мы обсудим, какую часть тестирования бизнес-аналитик может взять на себя.
СЭД - кровеносная система компании
Один из вариантов, когда на проект не назначен инженер по тестированию - это если речь идёт не о разработке "с нуля", а о настройке и (или) доработке стороннего коммерческого продукта: т.н. коробочного решения или "коробки".
Сторонняя компания-разработчик уделяет много времени тестированию своего коробочного продукта, прежде чем выпустить его на рынок и предложить другим организациям. Кроме того, разработчики "коробки" ограничивают возможности других программистов в части настройки и доработки их продукта. Исходный код коммерческих продуктов зачастую закрыт. Поэтому вероятность критических ошибок, спрятавшихся в глубине программного кода, у коммерческих продуктов ниже, чем у проектов, которые пишутся "с нуля". Тем не менее, даже при настройке процессов штатными средствами системы, без тестирования не обойтись.
Типичный пример "коробки" - система электронного документооборота (СЭД). СЭД, без преувеличения, можно назвать кровеносной системой современной компании. Вместо кислорода и питательных веществ СЭД переносит информацию, обеспечивающую жизнедеятельность организации: служебные записки, приказы, договоры и всевозможные заявки на получение внутренних сервисов. О последних мы сегодня и поговорим подробнее.
Процесс "Оформление командировки"
В качестве условного примера рассмотрим реализацию в СЭД процесса по оформлению командировок.
Ключевых действующих лиц в процессе трое:
- Инициатор. Сотрудник, которые собирается в командировку;
- Руководитель Инициатора. Начальник группы или отдела, который должен дать "добро" на отъезд своего сотрудника;
- Офис-менеджер. Специалист, обеспечивающий оформление командировки: утверждение Приказа на командировку, покупку билетов, бронирование гостиницы и т.п.
Вкратце, суть процесса такова. Инициатор заходит в систему и создаёт Заявку на командировку. Заполнив Заявку Инициатор направляет её на согласование Руководителю. Если с Заявкой всё в порядке - руководитель ставит положительную резолюцию в Системе и Заявка отправляется в работу Офис-менеджеру. Офис-менеджер проверяет Заявку и исполняет её: оформляет Приказ на командировку, на основе которого начислят командировочные, покупает билеты, бронирует гостиницу и т.д. После отправки Инициатору всех необходимых документов Офис-менеджер закрывает Заявку как исполненную.
Конечно, и Руководитель Инициатора и Офис-менеджер имеют право вернуть Заявку на доработку Инициатору, каждый на своём этапе.
Кроме того, в организации могут быть сотрудники, для которых командировка - стандартная часть рабочего процесса. Постоянное согласование командировок с руководителем в таком случае не требуется. Таким сотрудникам назначаются особые права в Системе: их Заявки поступают сразу на исполнение Офис-менеджеру.
В нашем условном примере мы исходим из того, что БА подготовил на этапе обследования ряд артефактов: карту бизнес-процесса, атрибутный состав Заявки, описание пользовательских сценариев и диаграмму состояний (статусов). На основе этих документов разработчик и создал прототип, который нам необходимо протестировать.
Как будем тестировать. Диаграмма состояний
Особый интерес для нас представляет диаграмма состояний, она же диаграмма статусов. Эта диаграмма описывает жизненный цикл Заявки в Системе. Иными словами: какие статусы принимает Заявка, в каком порядке и при каких условиях.
В овалах указаны статусы, которые может принимать Заявка. Стрелки используются для обозначения последовательности присвоения статусов и условий, при которых происходит смена статуса. В построении диаграммы состояний БА очень помогает карта бизнес-процесса.
По сути, работа пользователей в Системе сводится к тому, чтобы провести Заявку по определённой последовательности статусов и выполнить соответствующие этим статусам действия.
БА не обладает глубокими техническими компетенциями и не смотрит вглубь Системы. БА не работает с кодом и редко соприкасается с базами данных и архитектурными вопросами. Поэтому участие БА в тестировании сводится к тому, чтобы поработать с прототипом в роли конечного пользователя и оценить, сможет ли Заказчик решить свою бизнес-задачу при помощи Системы.
Диаграмма состояний - очень полезный инструмент для того, чтобы сделать подобное пользовательское тестирование более упорядоченным и осмысленным. Ведь нам предстоит совершать действия, обеспечивающие переход из одного статуса в другой. Базовые тестовые сценарии можно отмечать непосредственно на диаграмме или фиксировать в отдельной таблице.
Вот сценарий, где Инициатор создал Заявку, но закрыл её без сохранения. А вот сценарий, когда Руководитель согласовал Заявку, а Офис-менеджер нет. И т.д. Важно охватить все возможные варианты, потому что ошибка может возникнуть в самом неожиданном месте. Например, при особой комбинации статусов: в одной последовательности шагов всё будет в порядке, а в другой - критический баг.
Глядя на диаграмму состояний выявлять ключевые сценарии и цепочки статусов проще: меньше вероятность пропустить тот или иной статус и комбинацию действий.
Конечно, БА для такого тестирования понадобится 4 учётных записи в системе:
- Инициатор. Стандартная учётка для выполнения основных действий пользователя;
- Инициатор. Привилегированная учётка для проверки сценариев с отсутствием обязательного согласования Заявки Руководителем;
- Руководитель Инициатора. Для согласования Заявок или отправки Заявок на доработку;
- Офис-менеджер. Для исполнения Заявок или отправки Заявок на доработку.
Можно ещё немного углубиться и тестировать не только законченные сценарии из 3-5 статусов, доводящих Заявку до некого логического завершения, но и все возможные пары статусов. Т.е. мы проверяем исключительно то, что Заявка корректно переходит из статуса "Новая" в статус "Согласование Руководителем" или из статуса "На исполнении" в статус "На доработку".
В таком формате мы можем перейти на следующий уровень тестирования. Допустим, вы выделили все возможные пары статусов и проверили, что переход по ним осуществляется корректно. Значит всё, за качество продукта можно быть спокойным? А вот и нет! Самое время начать задаваться вопросом: "Позволяет ли Система пользователю совершить действия, которые не предусмотрены основными сценариями?". Например, у нас не предполагается переход из статуса "Новая" в статус "На исполнении" для Инициатора со стандартными правами. А вдруг система позволяет так сделать? Если да - это баг!
Все допустимые пары статусов определяются на основе той же диаграммы состояний. Для этого нужно найти все стрелки, которые выходят из интересующего вас статуса и записать, куда они ведут. Кстати, таким образом вы можете обнаружить, что в системе нет какой-либо пары статусов, которая нужна Заказчику.
Также БА может провести простейшее тестирование пользовательского интерфейса. Например, попытаться заполнить поле "Телефон" буквами или спецсимволами. Или оставить обязательные поля незаполненными и попытаться отправить заявку на согласование и т.п. Если что-то подобное удалось - это баг. В общем, на этапе простейшего тестирования интерфейса бизнес-аналитик примеряет на себя роль неадекватного пользователя и старается устроить в системе хаос и дестрой :)
Итак, основные формы тестирования для БА таковы:
- Тестирование ключевых пользовательских сценариев, в т.ч. с разными комбинациями заполнения полей. Например, в одном случае оформляется Заявка с просьбой приобрести авиабилеты, а в другом активируется атрибут о том, что билеты Инициатор купит сам. Ориентиром для БА на этом этапе служит диаграмма состояний. Также на этом этапе БА могут сильно пригодиться пользовательские сценарии (use cases), которые он написал на этапе обследования.
- Тестирование всех возможных пар статусов. Для определения всех возможных пар статусов также используется диаграмма состояний;
- Попытки выйти за пределы изначально установленной бизнес-логики системы: например, перейти из статуса "Оформлена" в статус "На доработку". Как мы видим по диаграмме состояний, такой возможности быть не должно;
- Режим "неадекватного пользователя": пишем буквы в полях для цифр и т.п.
Подводим итоги
Важно понимать, что пользовательское тестирование со стороны БА не обеспечивает того же уровня качества продукта, который был бы при участии профессионального тестировщика. БА может выявить баг, но вряд ли скажет его причину. Если проблема в методе обращения к базе данных, то в нашем примере это сможет выявить только разработчик.
Тем не менее, подобное тестирование на стороне БА - это своеобразный гигиенический минимум. Если тестирование не пройдено - нет никакого смысла демонстрировать прототип Заказчику: кого интересуют Системы, которые не отрабатывают даже базовые сценарии?
Описанный выше подход к базовому пользовательскому тестированию можно применять к любой системе, предполагающей обработку заявок и имеющей статусную модель: BPM, ECM, CRM и т.д.
Помимо шлифовки бизнес-логики Системы пользовательское тестирование на стороне БА поможет:
- Выявить недостатки в оформлении интерфейсов;
- Получить пользовательский опыт и оценить, насколько удобно пользоваться Системой;
- Ответить на вопрос, решает ли Система задачи бизнес-заказчика;
Поэтому результатом тестирования на стороне БА могут быть в т.ч. пожелания по размещению и оформлению элементов интерфейса.
В завершение пару слов о тест-кейсах. Если предполагается, что БА будет проводить несколько итераций пользовательского тестирования, все основные сценарии лучше записать. Это позволит лишний раз не придумывать и не вспоминать сценарии тестирования. Также БА нужно быть готовым к тому, чтобы чётко и последовательно расписать для разработчика порядок действий, приводящих к ошибке. По этой теме рекомендую прочитать книгу книгу Романа Савина "Тестирование dot com". В ней описаны основы основ тестирования ПО, в т.ч. написание тест-кейсов и баг-репортов.
Спасибо за внимание!
