К написанию этого поста меня подтолкнуло прочтение книги Continuous Delivery из серии The Addison Wesley. Рекомендую в оригинале, русский перевод лично мне не понравился. Перед нами задача — автоматизация процесса тестирования в текущем проекте.

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

Когда изучаешь этот процесс самостоятельно, кажется что у тебя есть очень много препятствий. С чего вообще начать и что вообще делать, как будут тесты гоняться и кто будет знать об этом. Но когда у тебя есть опыт, можно отделить зерна от плевел и действовать быстро и эффективно. Хотя насколько быстро это получится зависит не только от человека который занимается тестированием, но и от команды разработки.

Давайте определимся каким нам видится автоматизированное тестирование. Очень хорошо иметь автотесты, но поверьте мне никто не будет их запускать вручную, лень рано или поздно пересилит вас и тесты будут казаться обузой. Поэтому нужно чтобы тесты запускались на каждое изменение разработчика или по расписанию автоматически. Также нужно предоставлять исчерпывающий результат прогона тестов, в удобном виде. Это самые начальные требования и в то же время самые нужные.

По книге, есть 2 основы без которых автоматизация процесса тестирования невозможна:

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

Система контроля версий

Для любого проекта это очень логичный и правильный подход к разработке. Ваш код должен храниться в надежном месте, и разрабатывать его вместе должно быть удобно.  Очень часто бывает так что в проекте используется система контроля версий, но тестировщики не всегда имеют к ней доступ. Это в корне не верно, поэтому настаивайте на том чтобы вам создали аккаунт и открыли полный доступ к хранилищу кода. Возможно вы не до конца понимаете как используются эта система, но Git настолько прост, что для начального понимания вам хватит одного дня практики. Лично мне приходилось плотно работать только с Git и Github/Bitbucket, поэтому я не берусь говорить про другие системы контроля версий, например svn или mercurial, возможно они сложны. Хороших мануалов тоже очень много, и в то же время не забывайте что у вас есть коллеги, которые с радостью вам помогут. Git на самом деле сложен, а не прост, но понимание сложных вещей придет позже, они не критичны на этом этапе.

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

Сервер Contiunous Integration

Теперь когда ваш код централизовано хранится в системе контроля версий вам остается только развернуть сервер CI. Вам предстоит добиться у руководства выделенного сервера и выбрать один из вариантов Continuous Integration. Здесь я отдаю предпочтение TeamCity или Jenkins. С мануалами по установке проблем быть не должно. Далее вы подключаете CI к хранилищу. Теперь CI сам будет знать есть ли у вас новые изменения. Теперь у вас есть возможность получать любые изменения из хранилища кода, разворачивать их и запускать тесты, генерировать отчеты.

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

Что дальше

Дальше нужно решить как будут автоматизироваться тесты. Это решение нужно принимать вместе с командой разработки. Тесты должны писаться не только тестировщиками, но и разработчиками (например юнит-тесты). К слову, бывают такие процессы разработки когда тесты пишут даже заказчики. Определитесь с фреймворком, а возможно это будет что-то свое внутри компании и приступайте к автоматизации самых критичных сценариев регресса. По мере разработки тестов вы столкнетесь с новыми челленджами, для меня например таким было тестирование доставки писем. Как ускорить тесты, как запускать их параллельно, как запускать тесты в разных браузерах, в нужной последовательности и так далее. Затем присмотритесь пристальнее к CI, это не просто сервер для прогона тестов, система очень функциональна и предоставляет еще уйму дополнительных возможностей. Одна из них Continuous Delivery, грубо говоря это автоматизированные релизы, тоже сложный большой процесс который не уложится в одну статью.

Как всегда я буду рад вашим вопросам и комментариям.