 |
2.2 Модель функционирования ключевых процессов тестирования в компании ООО «ВБЦ»
|
|
|
|
2. 2 Модель функционирования ключевых процессов тестирования в компании ООО «ВБЦ»
2. 2. 1 Текстовое и графическое описание процесса
Маркетплейс ВБЦ предоставляет несколько сервисов для взаимодействия поставщиков и клиентов, а именно: VBC pro, Проверка контрагентов, Tenchat и Onado. Ключевым направлением работы является сопровождение участников тендеров, в частности госзаказа через систему VBC pro.
За качество данных сервисов отвечает отдел тестирования. Тестирование – это одна из техник контроля качества (Quality Control), которая включает активности по планированию работ (Test Managment), проектированию тестов (Test Execution), выполнению тестирования и анализ выходных результатов (Test Analysis) [8].
Тестирование программного обеспечения – это проверка соответствия реальных и ожидаемых результатов поведения программы, осуществляемая на конечном наборе тестов, выбранном определенным образом.
Тестировщик – специалист, который занимается тестированием. В его обязанности входит поиск возможных ошибок и сбоев в функционале приложения. Тестировщик моделирует ситуации, вероятные при использовании тестируемого объекта, чтобы потом разработчики могли устранить обнаруженные неполадки [9].
Тестирование является важной частью процесса разработки программных продуктов и входит в число наиболее эффективных способов обеспечения их качества. Под качеством в сфере разработки программного обеспечения подразумевается не только надежность программы, но и удобство пользования.
Работа тестировщика при тестировании программного продукта поделена на несколько этапов: анализ требований, планирование тестирования, разработка тестов, выполнение тестов, оценка результатов тестирования. (Рис. 2. 2):
|
|
|
Рисунок 2. 2 – Этапы тестирования
На этапе анализа требований тестировщик знакомится с ПО. Узнает, для чего оно предназначено. Знакомится с требованиями и вникает в проект. Выполняет тестирование и уточнение требований. После того, как вопросы по требованиям и функциональности ПО решены, происходит переход на этап планирования тестирования.
На этапе планирования тестировщик сфокусирован на вопросах о том, что необходимо тестировать, и какой функциональностью обладает ПО.
Планирование тестирования состоит из:
– создания тест-плана;
– продумывания стратегии тестирования;
– оценки трудозатрат на тестирование;
– прогнозирование сроков и составления графика проведения тестирования;
– оценка рисков;
– определения используемых инструментов.
Следующий этап – разработка тестов (тест-дизайн) в соответствии с определенными ранее критериями качества и целями тестирования ПО.
Проектирование тестов основываются на ТЗ или спецификации от системного аналитика. Для разработки тестов тестировщики используют специальные инструменты Sitechk, TestLink, Jira или пользуются обычным офисными программами как Excel, Word и Mind Map.
Когда тесты готовы, происходит этап выполнения. При выполнении тестов фиксируется версия ПО, на котором проводится тестирование, и результат прохождения теста. Полученные результаты сообщаются остальным членам команды и руководителю проекта. Если тесты провалились, то на их основе регистрируются ошибки в баг-трекере Jira.
При регистрации ошибок в Jira тестировщик указывает устройство, ОС устройства, версию ПО, браузер, описание проблемы, приоритетность, и в какой версии должна быть исправлена ошибка, а также разработчик, который будет исправлять данный дефект программного обеспечения [10].
Далее представлены на рисунке 2. 3 виды тестирования, которые используют специалисты по тестированию, проверяя ПО Маркетплейса ВБЦ.
|
|
|
Рисунок 2. 3 – Классификация видов тестирования
Функциональное тестирование проверяет, правильно ли выполняет ПО функции, описанные в требованиях, а также как выполняется взаимодействие с другими системами. К этому виду тестирования относятся модульное, интеграционное и системное тестирование.
К функциональным видам тестирования относят:
– функциональное тестирование основано на функциях, выполняемых системой;
– тестирование безопасности – проверка ПО на безопасность системы, правильного ограничения возможностей пользователей, защита от хакерских атак. Например, только администратор в системе может выдавать права и заводить новых пользователей. Или проверка на наличие уязвимостей XSS, когда на странице пользовательского интерфейса можно выполнять вредоносные скрипты;
– тестирование взаимодействия. Проверка взаимодействия ПО с различными внешними компонентами и системами.
Нефункциональное тестирование описывает тесты, необходимые для определения характеристик программного обеспечения, которые могут быть измерены различными величинами. В целом это тестирование того, как система работает.
Основные виды нефункционального тестирования:
– нагрузочное тестирование. Определение, как быстро работает ПО под заданной нагрузкой. Например, при тестировании производительности анализируют изменение времени при определенном количестве одновременно работающих пользователей;
– стресс-тестирование. Тестирование, которое позволяет проверить, насколько приложение и система в целом работоспособны в условиях стресса;
– тестирование стабильности и надежности. Проверка работоспособности приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки. При этом на первый план выходит отсутствие утечек памяти, перезапусков серверов под нагрузкой и другие аспекты, влияющие именно на стабильность работы;
– объемное тестирование. Оценка производительности при увеличении объемов данных в базе данных приложения. При этом измеряется время выполнения выбранных операций и количество пользователей, одновременно работающих с приложением;
|
|
|
– инсталляционное тестирование. Тестирование установки ПО, направленное на проверку успешной инсталляции и настройки, а также обновления и удаления ПО;
– юзабилити-тестирование. Оценка ПО с точки зрения удобства использования, изучения и освоения, понятности и привлекательности для пользователей в контексте заданных условий [11];
– конфигурационное тестирование. Специальный вид тестирования, направленный на проверку работы программного обеспечения при различных конфигурациях системы (заявленных платформах, поддерживаемых драйверах, при различных конфигурациях компьютеров и т. д. ).
После внесения изменений (исправления бага/дефекта) программное обеспечение должно быть протестировано заново для подтверждения, что проблема действительно решена. Ниже перечислены виды тестирования, которые используют тестировщики после установки программного обеспечения:
– дымовое тестирование;
– регрессионное тестирование. Это вид тестирования, направленный на проверку изменений, сделанных в приложении или окружающей среде. Проводится, чтобы подтвердить, что прежняя функциональность работает.
На данный момент в компании ООО «ВБЦ» специалисты отдела качества используют ручное тестирование. Оно проводится без использования дополнительных программных средств, и позволяет проверить программу или сайт с помощью имитации действий пользователя. Тестировщик выступает в качестве конечного пользователя продукта, он следует определенным сценариям (тест-кейсам), параллельно анализируя вывод программы и ее поведение в целом.
Ниже описана система VBC pro и представлены реальные тест-кейсы, по которым тестируют систему QA-специалисты в компании ООО «ВБЦ».
Система освобождает финансовые организации от необходимости в первичном скоринге, а также снимает нагрузку с сотрудников партнера за счет комплексной автоматизированной обработки и передачи заявки клиента в партнерскую финансовую организацию. Система не требует установки на рабочие компьютеры. Весь процесс работы строится посредством взаимодействия web-приложения.
|
|
|
VBC pro состоит из нескольких личных кабинетов, которые необходимы для предоставления услуг маркетплейса.
1 Личный кабинет клиента. Он необходим для подачи заявок клиентом на услуги компании, к примеру, заявка на Банковскую гарантию или Кредит на исполнение контрактов. В личном кабинете находится вся информация и документация о компании клиента.
2 Личный кабинет оператора. В данном кабинете рассматриваются заявки от клиентов на предоставляемые услуги, а одобренные заявки отправляются в банки-партнеры. Оператор проверяет, и, если надо корректирует документы, которые присылают клиенты.
3 Личный кабинет банка. В кабинете находится вся информация об одобренных андеррайтером заявках. Менеджеры банка рассматривают их, и выдают Банковские гарантии и другие услуги.
Также в систему интегрирован бизнес-чат, с помощью которого есть возможность отправлять запросы, документы и предложения, не выходя из системы. Данный бизнес-чат работает между всеми личными кабинетами системы и мобильным приложением Tenchat. Тем самым, значительно сокращает время на оформление заявки и передачу файлов между всеми бизнес-процессами.
Основным процессом деятельности предприятия является оказание финансово – посреднических услуг. Чтобы поподробнее рассмотреть данный процесс, представим его в виде модели «Как есть» или более распространённое название на английском языке «AS-IS» в программном обеспечении Erwin Process Modeler (рисунок 2. 4).
Рисунок 2. 4 – Диаграмма модели «AS-IS»
Входными данными в модели являются заявки тестировщиков в качестве клиентов.
Выходными данными являются:
– оказанная услуга;
– отмененная услуга.
Управлением являются следующие пункты:
– договора с партнерами;
– законодательство РФ;
– процедуры и правила.
В качестве механизмов отражены:
– тестировщик в качестве менеджера;
– тестировщик в качестве андеррайтера.
Для детального изучения бизнес-процессов сделаем декомпозицию диаграммы модели, представленной на рисунке 2. 5.
Рисунок 2. 5 – Декомпозиция диаграммы
На данной диаграмме представлен детализированный бизнес-процесс деятельности компании ООО «ВБЦ».
На первом этапе происходит подача заявки на услугу в личном кабинете клиента, предварительно зарегистрировавшись в нем. Тестировщик в качестве клиент заполняет данные о закупке, далее указывает всю информацию об учредителях и руководителях организации и отправляют заявку на рассмотрение к андеррайтеру (рис. 2. 6).
В таблице 2. 1 представлен тест-кейс «Авторизация клиента», данный тест проверяет возможность авторизации в личном кабинете клиента на официальном сайте.
|
|
|
Таблица 2. 1 – Тест-кейс «Авторизация клиента»
|
Тест-кейс ID: LOG0001 | |||
|
Вход в ЛК Клиента | |||
| № | Процедура | Ожидаемый результат | Статус |
| Открыть сайт: https: //test. vbc. loc/resources/secured/app/entry/login/client | Выполнен вход в ЛК Клиента | Пройден | |
| Выбрать раздел e-mail | Пройден | ||
| Ввести логин (test377@vbc. loc) пароль 123 | Пройден | ||
| Нажать кнопку " Войти" | Пройден | ||
Далее представлен в таблице 2. 2 тест-кейс подачи заявки БГ, этот кейс проверяет работоспособность функционала по подаче заявки в личном кабинете пользователя, работоспособность заполнения форм ввода и отправки заявки к андеррайтеру.
Таблица 2. 2 – Тест-кейс «Подача заявки БГ»
|
Тест-кейс ID: LOG0001 | |||
|
Подача заявки БГ | |||
| № | Процедура | Ожидаемый результат | Статус |
| Выбрать раздел " Продукты Бизнесу" | Открылся выпадающий список с продуктами | Пройден | |
| Выбрать продукт " Банковские Гос. Гарантии" | Открылась таблица с текущими заявками | Пройден | |
| Нажать на вкладку " Новая заявка" | Открылась форма заполнения № Закупки | Пройден | |
| Заполнить № закупки и нажать кнопку " Загрузить" | Открылось модальное с разделом Новая заявка | Пройден | |
| Заполнить формы ввода самма БГ, Окончание действия БГ и тд | Переход в раздел Анкета | Пройден | |
| Нажать кнопку " Далее" | Пройден | ||
| Проверить данные и нажать кнопку " Далее" | Переход в раздел Документы | Пройден | |
| Нажать на кнопку " Запустить проверку" | Заявка отправлена на рассмотрение андеррайтеру | Пройден | |
Рисунок 2. 6 – Блок процесса «Подача заявки»
В блоке «Рассмотрение заявки» (Рис. 2. 7), который будет детализирован дальше, описан процесс рассмотрения заявки андеррайтером.
На данном этапе происходит валидация заявки. Оператор рассматривает заявку и оставляет ее за собой, чтобы в дальнейшем ее качественно проверить и подготовить к оправке в финансовые организации (банки-партнеры). Тестировщик в качестве андеррайтер на этапе скоринга проверяет все предоставленные клиентом документы, заполняет финансовую отчетность и проверяет на стоп-факторы банков.
Однако, при рассмотрении заявки может быть несколько вариантов развития событий:
1) заявка одобряется, то есть андеррайтер готов отправить заявку дальше на рассмотрение в банки для выдачи финансового продукта;
2) по заявке пришила отмена со стороны клиента, то есть клиент отказывается от услуг компании;
3) заявка отказана оператором, то есть андеррайтер не готов предоставить финансовый продукт по определенной причине;
4) заявка возвращена на доработку, то есть в данном случае подразумевается какой-то дозапрос по документам или иной информации.
В случае одобрения, андеррайтер отправляет заявку клиенту на подпись для подтверждения предложения, после чего заявка отправляется в банки.
Рисунок 2. 7 – Блок процесса «Рассмотрение заявки»
Ниже представлены тест – кейсы на проверку вышеописанного функционала. Но прежде тем, как проверить этот функционал рассмотрение заявки необходимо авторизоваться в личном кабинете оператора. (Таб. 2. 3)
Таблица 2. 3 – Тест-кейс «Авторизация оператора»
|
Тест-кейс ID: LOG0002 | |||
|
Вход в ЛК Оператора | |||
| № | Процедура | Ожидаемый результат | Статус |
| Открыть сайт https: //test. vbc. loc/resources/secured/app/entry/login/oper-or-partner | Выполнен вход в ЛК Оператора | Пройден | |
| Выбрать раздел e-mail | Пройден | ||
| Ввести логин (oper@email. ru) пароль 123 | Пройден | ||
| Нажать кнопку " Войти" | Пройден | ||
Таблица 2. 4 – Тест-кейс «Авторизация клиента»
|
Тест-кейс ID: BG0002 | |||
|
Рассмотрение заявки БГ андеррайтером | |||
| № | Процедура | Ожидаемый результат | Статус |
| Нажать на кнопку " В новый кабинет" | Открылся новый кабинет Оператора | Пройден | |
| Выбрать раздел " Банковские Гарантии" -> подраздел " Заявки" | Открылась таблица Банковские гарантии / Заявки | Пройден | |
| Открыть конкретную заявку клиента | Открылась модальное окно с общей информацией о заявке | Пройден | |
| Нажать кнопку " Взять на валидацию" | Открылось модальное с разделом Новая заявка | Пройден | |
| Проверить данные и нажать кнопку " Далее" | Переход в раздел Документы / Анкета | Пройден | |
| Подтвердить и сохранить документы | Переход в раздел Стоп-факторы банков | Пройден | |
| Нажать кнопку " Далее" | Пройден | ||
| Отметить непроставленные стоп-факторы и нажать на кнопку " Сохранить" | Заявка отправлена на рассмотрение андеррайтеру | Пройден | |
| Нажать кнопку " Далее" | Переход в раздел Донесение информации | Пройден | |
| Отметить непроставленные параметры и сохранить данные | Переход в раздел Результаты скоринга | Пройден | |
| Нажать кнопку " Далее" | Пройден | ||
| Выбрать банки, в которые будет отправлена заявка и нажать на кнопку " Отправить" | Заявка отправлена в Банки и Клиенту на подпись | Пройден | |
Исходя из построенных схем можно заметить, что огромное количество времени тестировщик сталкиваемся с функциональным тестированием, которое проверяет, соответствует ли система описанию документации. Данный вид тестирования полезно автоматизировать, так как в дальнейшем их можно использовать для регрессии.
Регрессия, или регрессионное тестирование, следует проводить после каждого обновления системы. Если был добавлен новый функционал, стоит проверить исправность прежнего, верстку, расположение элементов и текстовых полей. Эта работа может стать надоедливой рутиной, если обновления выходят часто. Поэтому данный процесс необходимо автоматизировать.
Ручное тестирование необходимо для того, чтобы выявить и устранить «узкие места», а также снизить количество дефектов, обеспечив стабильность программы. Оценить удобство использования приложения, и своевременно дать фидбек, тем самым получить продукт, удовлетворяющий ожиданиям пользователей.
Однако ручное тестирование имеет недостатки, которые можно исправить, внедрив процесс автоматизированного тестирования:
– человеческий фактор – когда тестировщик проходит кейсы уже «на автомате», он может и не заметить изменений в форме. Автотесты выполняются с большей точностью, так как исключается человеческий фактор;
– трудозатраты и продолжительность. Серия автоматизированных тестов позволяет протестировать программное обеспечение значительно быстрее, а тестовый прогон можно запланировать на любое время и запустить по расписанию, чтобы он выполнялся без участия человека;
– отсутствие возможности моделирования большой нагрузки. При ручном тестировании невозможно смоделировать большое количество пользователей;
– рутинность процесса, особенно при регрессии. Провести серию стандартных автоматических тестов проще, чем протестировать проект вручную после внесения даже небольших изменений;
– вручную провести нагрузочное тестирование можно только после запуска приложения в опытную эксплуатацию. Это риск глобальных поломок и репутационных потерь, если на предприятии работа встанет из-за неисправности системы.
Благодаря автоматизации специалист и команда сможет работать максимально эффективно, так как влияние «человеческого фактора» сокращается и число ошибок тестирования становится минимальным.
При использовании автоматического скрипта машина может исправно и точно повторять одни и те же операции тысячи раз. Она останавливается или фиксируется только в том случае, если тестируемый функционал неверен или не соответствует заданной логике.
Вместо того, чтобы постоянно концентрироваться для обработки и тестирования больших объемов кода, тестировщику достаточно внимательно записать скрипт один раз и учесть возможность изменения интерфейса программы. После записи скрипта требуется лишь небольшой мониторинг – в случае возникновения ошибки и передачи ее программистам для исправления. Освободившееся время можно использовать для проверки других продуктов, написания тестовых сценариев и тест-планов.
Таким образом, автоматизация тестирования позволит:
– улучшить экономические показатели;
– увеличить эффективность работы тестировщика;
– ускорить обработку информации и запуск проекта, продажу программного продукта;
– повысить качество обработки информации и достоверность результатов. Если скрипт дошел до конца, и он корректен – значит, все заложенные в него действия верны;
– сэкономить время при формировании отчетности. Большинство профессиональных систем, применяемых для тестирования, формируют разнообразные отчеты, графики зависимостей и другую необходимую документацию.
Система автоматизации ручного тестирования дает огромное преимущество предприятию перед конкурентами, так как локализует ошибки, верифицирует данные и показывает соответствие конечного продукта заявленным требованиям.
|
|
|
