Глава 3. Проект по автоматизации процесса тестирования

3.1 Цели проекта

Целью проекта является оптимизация работы службы технической поддержки. Рассмотрим основные направления, с помощью которых мы можем повысить эффективность работы службы:

Рисунок 3.1 - Цели проекта

Таблица 3.1 - Подцели проекта

Критерий	W	Действия
		Увеличение количества обнаруженных ошибок	Снижение затрат и времени на тестирование
Получение прибыли	0,6	0,3	0,7
Снижение издержек	0,4	0,4	0,6
	1	Эффект
		0,34	0,66

Таблица 3.2 - Увеличение количества обнаруженных ошибок

Критерий	W	Действия
		Привлечение более квалифицированных специалистов	Увеличение времени на тестирование
Время	0,4	0,4	0,6
Эффект	0,6	0,5	0,5
	1	Эффект
		0,46	0,54

Таблица 3.3 – Снижение затрат и времени на тестирование

Критерий	W	Действия
		Автоматизация процесса тестирования	Усовершенствование процесса ручного тестирования
Время	0,4	0,4	0,6
Эффект	0,6	0,7	0,3
	1	Эффект
		0,58	0,42

Рисунок 3.2 – Подсчет важности целей проекта

1. 0,34*0,46=0,1564 (4)

2. 0,34*0,54=0,1836 (3)

3. 0,66*0,58=0,3828 (1)

4. 0,66*0,42=0,2772 (2)

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

3.2 Оптимизация бизнес-процесса

Процесс тестирования ПО является частью процесса разработки (см. рисунок 3.3.).

Рисунок 3.3 – Процесс тестирования МИС

На данный момент прогон сценариев производится вручную: специалист отдела техподдержки проверяет функционал МИС, руководствуясь заранее написанными сценариями – test case. Эти сценарии подробно описывают, какой результат следует ожидать от правильно работающей системы при определенных манипуляциях. При обнаружении несоответствий сотрудник регистрирует найденную ошибку, которая в свою очередь уходит в отдел разработки для исправления. Когда все ошибки исправлены, происходит повторное тестирование и при положительном результате релиз готов к выпуску. (рисунок 3.4).

Рисунок 3.4 – Модель «as is» – тестирование МИС

При внедрении проекта каждый test case превращается в интеграционный тест, который в автоматическом режиме производит прогон сценариев, тем самым значительно сокращая время на тестирование и упрощая работу специалистов службы техподдержки. Результатом прогона теста может быть положительный «зеленый» или ошибочный «красный» цвет (рисунок 3.5).

Рисунок 3.5 - Модель «to be» – тестирование МИС

Автоматизированное тестирование подразумевает использование такого языка написания тестов, как Gherkin. Он позволяет покрыть весь необходимый функционал тестируемого продукта.

Естественный язык тяжело интерпретировать, используя программные алгоритмы, поэтому его искусственно ограничивают в рамках написания пользовательских историй. Для этого чаще всего используется конструкция «Допустим – Если – То» (Given - When – Then). Шаблон описывает начальные условия, действия пользователя и конечный результат. Пример:

Допустим, что сотрудник Иванов зарабатывает 400р. в час.

Если Иванов работает 40 часов в неделю,

То Иванов будет получать 64000р. в месяц.

В качестве примера также можно привести следующий сценарий:

Необходимо проверить работу фильтров для поиска пациента из базы данных. В ручном режиме специалист должен собственноручно ввести данные в поле «Номер полиса» и нажать кнопку «Найти». Результатом будет запись, содержащая информацию о пациенте.

Рисунок 3.6 – Интерфейс МИС «Медик +»

При использовании Gherkin тест, выполняющий те же действия, будет выглядеть следующим образом:

Если в области фильтров введу в поле «Номер полиса» значение «123456»

И в области фильтров выполню команду «Найти»

То система выведет перечень найденных записей