Как изменить методологию разработки и исключить дефекты в коде
Срок реализации – от двух месяцев
Задачи
- Повысить качество поставляемого на продакшн кода
- Получить возможность объективного контроля стабильности системы
Стэк
любой
Решение
Полный контроль поведения системы
Существует распространенное убеждение, что невозможно протестировать систему на 100 процентов. На практике такое осуществить действительно очень сложно. Но если изменить привычное представление о цикле разработки и применить специализированные средства, то есть все шансы опровергнуть этот миф.
Мы расскажем об этом на примере одной из систем менеджмента тестирования (TMS) - Enterprise Architect от Spark Systems. Работа с этой программой подразумевает наличие достаточного уровня компетенций, в том числе и у менеджеров проекта. В этом приложении есть доступ к описанию структуры проектируемой системы, и всех возможных моделей ее поведения. Проджект менеджер описывает критерии и добавляет компоненты, которые должны с ними работать. Например, классы в Java коде, и какие-то таблицы из БД. Оформляет задачу, и отдает разработчику. Разработчик при получении задачи в этой же среде сразу видит диаграмму, где визуально показаны связи зависимостей от критериев. Тем самым, сводится к минимуму шанс что-то упустить при написании кода.
Тестировщику остается только проверить корректность соблюдения условий к описанному результату. В рамках проекта это может быть даже несколько тысяч различных комбинаций условий к зависимостям. На каждую связь надо написать свой тест-кейс, и таким образом, мы покроем 100% системы. Не спорим, что это трудоемкий процесс. Однако в перспективе никогда не придется возвращаться к старым участкам продукта. Регрессионное тестирование теперь будет проводится всегда и в автоматическом режиме. С логированием результатов и подтверждением со скриншотами. И, наконец-то, можно максимально вести кейсы, и забыть об исторически сложившейся практике использования Excel.
Применение такой контурной системы тестирования очень удобно для менеджеров проекта, как ответственных за финальный результат. Проджект открывает одну вкладку и видит в процентном соотношении, сколько тестов вообще есть, сколько кода покрыто тестами. Сколько тестов и с каким результатом проходит в данный момент времени? А также ключевой показатель - какой процент стабильности системы.
Например, мы наблюдаем 96% стабильности системы. Ретроспектива - в прошлый релиз было 90% стабильности, а в этот повыше - можно похвалить членов команды. Если результат, наоборот, снизился - значит, надо где-то догонять. Либо описываемые критерии не соответствуют реальной картине, либо разработчики стали неверно понимать задачи.
Любой участник процесса может оценить проект в реальном времени, и личную вовлеченность в него себя или своих коллег. Повторимся, что это достаточно нетривиальный подход к разработке системы. Однако он оправдывает вложенные силы тем, что даёт очень высокие результаты по качеству выпускаемого продукта.
Кроме Enterprise Architect есть и другие варианты TMS. Например, это Test Rail. Она позволяет удобно вести свои сценарии, несмотря на свой преклонный возраст. Есть и более современная платформа Test IT. Она новая, с очень продуманным интерфейсом и функционалом, полностью локализована. Но придется убедить стейкхолдеров в ее необходимости, поскольку и цена у нее довольно высока.
