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

Автоматизированное тестирование – это практика, которая сейчас, мягко говоря, на слуху. Специалисты по автоматизированному тестированию востребованы на рынке труда и могут рассчитывать на хороший доход. Тем временем, автоматизированное тестирование является одним из ярчайших примеров DevOps-практик (помните, мы уже упоминали в первом тексте, что хотя DevOps и является относительно новым подходом к разработке, инструменты тут часто используются более-менее привычные, поэтому DevOps не требует специалистов нового типа). Оно позволяет здорово ускорить время прохождения программой пути от кода на компьютере разработчика до любимой игрушки на устройстве довольного пользователя. Вполне вероятно, в разработке вашего продукта оно уже применяется. Если нет, то это повод задуматься о том, насколько эффективно используются ресурсы проекта.

Программное обеспечение тестируется на каждом этапе жизненного цикла. И разработчиками на предмет работоспособности кода, и QA-специалистами на все на свете. И даже каждый раз, когда пользователь запускает приложение – можно сказать, что он тестирует его, потому что в результате взаимодействия могут вылезти баги (правда не всегда о негативных результатах его «теста» можно узнать, если не использовать инструменты для мониторинга). Тестирование повсюду, и это огромный кусок работы, который можно делать быстрее и с меньшими затратами.

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

В частности, такие опции предоставляют «облачные» платформы, тот же Microsoft Azure, а точнее Visual Studio Team Services, в котором есть встроенные инструменты для проведения автотестов. Также сюда интегрированы популярные сервисы для автотеста, которые не являются разработкой Microsoft, такие как Selenium и практически любой фреймворк для тестирования, который вы могли использовать до этого.

Но прежде чем рубить с плеча и после прочтения первой половины статьи бежать автоматизировать все, что плохо лежит, подумайте о своем проекте и решите, подходит ли ему автоматизация процессов тестирования.

Как и любая другая автоматизация, создание автотестов требует времени специалистов, которые в этом смыслят. Поскольку оплата труда автоматизаторов выше, чем у «ручных» тестировщиков, не исключено, что кто-то из QA-команды вашего проекта уже тихо мечтает освоить более прибыльные инструменты и грызет гранит науки по ночам. Возможно, и ваши разработчики волшебным образом замотивируются на написание автотестов – их может убедить тот факт, что лучше один раз написать автотест, чем каждый раз сталкиваться с чужими ошибками и раз за разом их исправлять.

Время и деньги – это, по сути, одно и то же, когда речь заходит о бизнесе. Помимо времени специалиста, который, если не привлекать со стороны, будет оторван от других задач на проекте, само написание требует времени. Стоит быть реалистом и понимать, что нет 100%-гарантии, что автотесты сразу же будут такими, которые действительно освободят руки команды для других, более интеллектуальных и творческих задач. В идеале так и должно получиться, но всегда остается вероятность, что автоматизация тестирования, если тесты никудышные, приведет к тому, что проект будет «съедать» больше ресурсов. Если получится так, то это верный признак того, что что-то не то происходит у вас с автоматизацией на проекте.

Автоматизированное тестирование – отличный инструмент для проверки кода, но никудышний, когда требуется «простое человеческое участие», например, тестирование пользовательского интерфейса. У «робота» нет чувства прекрасного (и все нынешние истории вокруг нейронных сетей в очередной раз это подтверждают), он не сможет заметить по ходу, что где-то верстка съехала на один пиксель, а где-то сочетание цвета кнопочки и надписи на ней – просто вырвиглазные. Но такие вещи тоже надо кому-то когда-то подмечать – и этим «кем-то» по-прежнему останется QA-специалист, который проверяет ПО вручную. Даже если программа справится тестами кода, кому-то надо будет после протестировать пользовательский интерфейс или провести системное тестирование – это явно слишком сложные задачи для программы.

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

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

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

Во-вторых, если у человека есть график работы, то программа не возмутится, что вы заставляете ее выходить «на смену» по ночам. Поэтому если все прочие процессы на проекте автоматизированы и интегрированы в единую среду, то можно, например, собирать билды по ночам и автоматически запускать автотесты по расписанию. В «облачных» платформах, таких как Microsoft Azure, а точнее Visual Studio Team Services, интегрированы инструменты для автотестов, и даже их запуск можно автоматизировать и проделывать не то что в три клика – а один раз за проект после недолгих настроек. Это шикарная возможность сэкономить время на разработку и введение продукта в эксплуатацию.

В-третьих, алгоритмам, в отличие от людей, не свойственно ошибаться из-за обусловленной каким-то мимолетным моментом невнимательности или «перегорать» от большого количества рутины. Человеку – свойственно.

Таким образом, в идеальном мире DevOps, где команда работает в единой среде и автоматизирует рутину на проекте, тестирование происходит таким образом: для проекта по максимуму пишутся автотесты. После прохождения этих тестов и исправления всех багов ПО попадает к тестировщикам. И оттуда, только после разрешения живого специалиста, ответственного за QA, – на продакшн. В автоматизированное тестирование придется основательно вложиться вначале проекта. Но оно позволит произвести проверку качества приложения более дотошно и быстро, быстрее обнаружить и исправить баги.

А ведь чем дальше ошибка от этапа написания кода, тем дороже обходится ее устранение. Соответственно, чем раньше она будет найдена и исправлена, тем в меньшую сумму выльется проект. И тем счастливее будут пользователи, которым не придется иметь с ней дело. А не это ли мечта всех, кто создает приложения?