Особенности тестирования программных продуктов для органов местного самоуправления

Аватар пользователя Александрова Нина
Александрова Нина

Тестирование является важной частью процесса разработки программного обеспечения (далее — ПО) и представляет собой исследование с целью получения информации о качестве ПО.

Основными показателями качества ПО являются:

  • функциональность (functionality);
  • надежность (realibility);
  • удобство (usability);
  • эффективность (efficiency);
  • сопровождаемость (maitainnability);
  • переносимость (portability).

Институт Территориального Планирования «Град» ориентирован на разработку как настольных, так и веб-приложений, включая различные сервисы, что, безусловно, оказывает влияние на выбор подходов к тестированию.

Основные виды тестирования, применяемые в ИТП «Град»:

  • Функциональное  (проверка поведения и функций системы, т.е. того, что система может выполнять, какие задачи решать);
  • Регрессионное  (повторное прохождение уже выполненных ранее тестов, а также выполнение  проверки для целей исключения попадания регрессионных ошибок в очередную версию в результате слияния кода);
  • Интеграционное (объединение отдельных программных модулей и их тестирование в группе);
  • Нагрузочное (определение или сбор показателей производительности и времени отклика программно-технической системы в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к системе).

При тестировании ПО применяется преимущественно ручное тестирование,  однако следует отметить, что при необходимости и/или возможности процесс тестирования автоматизируется.

В ИТП «ГРАД» большое внимание уделяется повышению квалификации сотрудников. Систематически проводится  обучение, курсы, участие в профессиональных конференциях, в том числе, и международного уровня.

В качестве основного инструмента по управлению процессом тестирования используется система TestLink — продукт с открытым кодом (Open Source), что позволяет адаптировать его под текущие нужды.

Функционал TestLinkа позволяет осуществлять:

  • Ведение функциональных требований;
  • Ведение тестов с привязкой к требованиям и версионности;
  • Создание тестовых наборов/Планов тестирования;
  • Подготовку отчётности: прогресс выполнения, результаты прохождения тестов и т.д.;
  • Контроль за выполнением плана и оперативное перераспределение задач в случае необходимости;
  • Ведение истории прохождения тестов.

Также данный инструмент используется в ИТП «Град» для обучения новых сотрудников, что  позволяет получить специалистам базовые знания и навыки, а так же обеспечивает более оперативное их включение в работу.  Подробные сценарии использования функций системы позволяют снизить фактическое участие кураторов в процессе обучения.

В любой деятельности есть как положительные факторы, так и отрицательные — те, которые тормозят процесс, увеличивают риски, сказываются на итоговом результате.

В тестировании программного обеспечения для органов, уполномоченных в сфере архитектуры и градостроительства, самыми распространенными и весомыми являются следующие проблемы:

  • Низкое качество данных: некорректная геометрия, неполнота атрибутивной информации, рассогласованность и т.д. Это острая проблема для всей градостроительной отрасли.
  • Проблемы с разночтениями в законах и утвержденных регламентах. Различие в структуре органов исполнительной власти субъектов РФ и различные полномочия, которыми наделяют их региональные законы, обуславливают необходимость формирования индивидуальных регламентов. Заказчики по-разному трактуют не только законы, но и регламенты, принятые  органами государственной власти и органами местного самоуправления, соответственно, нет возможности протестировать «Идеальную цепочку», так как её не существует.
  • Ограниченные сроки тестовой эксплуатации. Конечный пользователь только на последних этапах работ (перед сдачей контракта) начинает знакомиться и использовать приложение. Соответственно, на завершающий этап проекта ложится большой объем переработок ранее стабилизированного функционала и изменений метаданных. Это, в свою очередь, повышает риски возникновения дефектов и дестабилизирует приложение.
  • Отсутствие обратной связи от Заказчика. Очень важно СВОЕВРЕМЕННО и в ПОНЯТНОЙ форме получать замечания от Заказчика.  Для обратной связи специалистами группы тестирования разработан шаблон, который заполняется на стороне Заказчика (как правило — администратором). В шаблоне описываются проблемы и шаги воспроизведения ошибок, замечаний. Данный формат коммуникации  обеспечивает контроль существующих проблем и планирование их устранения.
  • Отсутствие на стороне Заказчика ответственного за ведение системы специалиста с администраторским уровнем знаний системы.
  • «Необходимость» экстренного добавления новой функции, что требует глобального рефакторинга кода и, в итоге, приводит к критичным багам на стороне Заказчика.

Для снижения рисков выдачи релизов с большим количеством дефектов в ИТП «Град» применяется модель, описанная ниже.

Релиз (жарг. от англ. release — выпуск) — выпуск окончательной версии программы — готового для использования продукта.

Основные шаги для подготовки идеального релиза:

  1. Сверка готовности функционала согласно Плану Релизов (перечень новых и изменённых функций, которые должны работать в новой версии приложения);
  2. Функциональное тестирование Feature и Change Request;
  3. Выведение релизной ветки;
  4. Проверка инсталляторов на соответствие комплектации системы;
  5. Прохождение полного набора регрессионных тестов и закрытие исправленных ошибок;
  6. Подготовка отчёта о тестировании;
  7. Выведение ветки master и сборка инсталляторов;
  8. Размещение инсталляторов, отчётов о тестировании и документации на выделенный ресурс.

Графически процесс подготовки идеального релиза представлен на рисунке ниже.

Несмотря на то, что процесс состоит из 8 шагов, — это трудоемкая работа. В случае, если сработали риски добавления нового функционала, то модель выглядит следующим образом:

Красным показана зона высокого риска обнаружения ошибок на стороне Заказчика. Чем ближе к сроку выдачи происходит заливка нового функционала, тем выше вероятность попадания ошибок на сторону Заказчика. Аналогичная ситуация с исправлением ошибок, которые требуют детального анализа и затрагивают разные части кода.

Единственный вариант выдачи релиза без рисков — это повторный регресс красной зоны, соответственно, растягивание сроков, что часто является недопустимым.

Для минимизации этих рисков необходимо переносить реализацию новых функций и исправление некритичных ошибок  в план следующего релиза.

Если же необходима демонстрация нового функционала без установки сборки на пользовательские места, то для этих целей из релиза выводится отдельная ветка prototype и в неё добавляют новую функцию. На данной ветке проводится только функциональное тестирование новой функции!

 В целом процесс обеспечения качества ПО — это процесс, в котором непосредственное участие принимают все специалисты, начиная от тестировщиков, аналитиков, разработчиков… и заканчивая Заказчиком.

Как известно, нет предела совершенству и нет приложений без ошибок — но это цель, к которой мы стремимся!

Комментарии

Отправить комментарий

Содержимое этого поля является приватным и не будет отображаться публично.
АНТИСПАМ
Этот вопрос задается для того, чтобы выяснить, являетесь ли вы человеком или представляете из себя автоматическую спам-рассылку.
X
Вы можете войти с зарегистрированным именем пользователя или вашим e-mail адресом.
Пароль чувствителен к регистру.
Загрузка