Автоматизация всё ещё остаётся сложным и затратным процессом. Часто на это уходит много времени QA-автоматизаторов и нередко самих разработчиков на проекте. Но все эти расходы можно сократить, если подойти к внедрению автотестов с умом.
В статье поделюсь нашим опытом внедрения автотестов в проекте. На наш взгляд, представленная информация немного интереснее чтения сухой документации, полезность и полноту которой мы и не пытаемся заменить.
Спойлер: мы сами не ожидали, что получится настолько эффективно, хотя, конечно, не обошлось без трудностей.
Оговоримся сразу — наш опыт больше применим для продуктовых компаний. При этом для команд проектной разработки тоже не составит труда показать заказчику всю эффективность и выгоду внедрения автоматизации процесса тестирования и, соответственно, применить на проекте. По опыту скажу, что в среднем целесообразность применения автоматизации наступает на проектах, время разработки которых превышает минимум 1 год, хотя не обходится и без исключений, связанных в первую очередь с инициативами как команд, так и заказчиков.
Также мы не преследуем цель охватить максимальное количество нюансов и настроек, а покажем небольшие самые первые шаги, которые помогут максимально быстро стартануть процесс автоматизации и не допустить первоначальных сложностей.
Кроме того, мы не сторонники того, чтобы заменять автотестами ручное тестирование. В статье хотим показать, что автоматизация может оказаться довольно простым шагом, продвигающим ваш проект вперёд.
Итак, давайте начнем уже!
Почему мы выбрали JavaScript
Нас никто не ограничивал в выборе, поэтому исходили из простой логики — чем легче язык программирования (дальше ЯП), тем проще должен был получиться результат. Поэтому из топ-3 наиболее популярных ЯП — Java, Python и JavaScript — мы остановились на JavaScript из-за простоты и наиболее низкого порога входа для начинающего специалиста. Кроме того, выбор был сделан в пользу JavaScript еще и потому, что вся фронтенд часть написана на нем и предполагалось, что ребята-фронтендеры смогут помочь выстроить правильную архитектуру автоматизации в компании в целом.
Также мы сравнивали работу PHP и JS с нашими фреймворками — JS показывает лучшие результаты по скорости работы с простыми операциями. А это критически важно для большой системы и большого количества тестов.
Какие тесты начали автоматизировать и почему
Процесс автоматизации мы начали именно с интеграционных API-тестов. Исторически проект разрастался в функционале без сопутствующих unit и компонентных тестов. Чтобы не нарушать нить построения внутренней архитектуры и методологии, было принято решение начать именно с той ступени тестирования, с которой начинается зона ответственности тестировщиков. Постарались сделать именно так, чтобы не отвлекать разработчиков на написание тестов, а наоборот упростить процесс разработки и помочь команде поддерживать максимальное качество на проекте.
Немного о фреймворке тестирования
Первое что мы сделали — это выбрали фреймворк. Выбирали между фреймворками JEST, Mocha и другими. Выбор пал на JEST — как самый быстрый из всех.
JEST делает быстрым сочетание нескольких факторов:
“test”: “jest”
},
it("Тест 1.1", function() {
expect(1 + 1).toBe(2)
})
})
• Запускаем наш с вами первый тест
npm test
Это было слишком просто, скажете вы! Да, так и есть. Писать API-автотесты на JavaScript + Jest — это просто!
Для автотестов на стороне клиента существуют разные request-библиотеки. Мы у себя используем библиотеку supertest (более подробнее тут: https://www.npmjs.com/package/supertest)
const request = require('supertest')
const agent = request('https://reqres.in/api')
describe("Тест 2 - ну что-нибудь посложнее", function() {
it("Тест 2.1", function(done) {
agent
.get('/user')
.expect('Content-Type', /json/)
.expect(200, done)
})
})
Дальше были проверены не только get-запросы, но и post/put, а также циклы и прочие особенности.
Вроде бы все неплохо, но не хватало вспомогательных функций. Мы хотели видеть, на какой строчке упал автотест. Для этого использовали
expect(res.statusCode).toEqual(400))
Дальше захотели узнать, какой был запрос отправлен и для этого изучили reject, составив при этом такое условие:
if (err) {
reject(`\r\nОшибка: ${err.stack.replace(/[\"\\]/g, '')}\r\n\r\nДанные:
${JSON.stringify(res, null, 2).replace(/[\"\\]/g, '')}`)
} else {
resolve(res)
}
Дальше, конечно же, захотели отчёты в Allure и собственных метриках. Всю информацию записывали в xml-файл и собирали с помощью jest-allure.На этом интересные моменты не закончились, и мы научились работать с авторизацией в нашей системе и шифрованием.
В заключительной части — мультиплатформенный запуск (Win, Linux, Mac) и запуск тестов на разных окружениях (local/office/stage/prod). Также нам удалось покрыть ещё и межсервисные API, и, вуаля на каждый сервис было написано еще около 300 тестов.
Что в итоге?
Подведу итоги за полгода работы одного тестировщика, выделенного на каждом проекте для автоматизации:
Можно заметить, что 1189 тестов проводится всего за 3,5 минуты на одном проекте и 508 тестов за 1 минуту на другом! Мы считаем, что это отличный результат, учитывая, что раньше эти процессы выполнялись вручную целой командой тестирования минимум 1 день.
За полгода добились стабильности в Pipeline, создали утренние и вечерние прогоны автотестов на разных окружениях, а также написали собственные дашборды качества автоматизации тестирования на проектах. Это небольшой срок от момента старта до реализации.
Стоит упомянуть также о том, что мы не рассчитывали ROI перед внедрением автоматизации в проект, хотя информации о том, как считать этот показатель много в виде отдельных статей и других источниках. Понимаем, что это не было правильным решением и лучше бы предварительно посчитать стоимость, однако автоматизация, тем не менее, оказалась выгодным вложением усилий и ресурсов.
Что в планах?
Уже положено начало покрытия проекта E2E тестами. Также поставили себе цель — время выполнения любых тестов не должно превышать 15-18 минут. Это позволит быстро проверять любой сценарий и сделать первый шаг к непрерывной выкладке фич. Ещё один показатель, которого хотим добиться — время на реализацию автотеста не должно превышать 3 рабочих дней, тем самым все новые фичи на проекте при повторных проверках будут автоматизированы, исключая при этом «человеческий фактор».
habr.com
В статье поделюсь нашим опытом внедрения автотестов в проекте. На наш взгляд, представленная информация немного интереснее чтения сухой документации, полезность и полноту которой мы и не пытаемся заменить.
Спойлер: мы сами не ожидали, что получится настолько эффективно, хотя, конечно, не обошлось без трудностей.
Оговоримся сразу — наш опыт больше применим для продуктовых компаний. При этом для команд проектной разработки тоже не составит труда показать заказчику всю эффективность и выгоду внедрения автоматизации процесса тестирования и, соответственно, применить на проекте. По опыту скажу, что в среднем целесообразность применения автоматизации наступает на проектах, время разработки которых превышает минимум 1 год, хотя не обходится и без исключений, связанных в первую очередь с инициативами как команд, так и заказчиков.
Также мы не преследуем цель охватить максимальное количество нюансов и настроек, а покажем небольшие самые первые шаги, которые помогут максимально быстро стартануть процесс автоматизации и не допустить первоначальных сложностей.
Кроме того, мы не сторонники того, чтобы заменять автотестами ручное тестирование. В статье хотим показать, что автоматизация может оказаться довольно простым шагом, продвигающим ваш проект вперёд.
Итак, давайте начнем уже!
Почему мы выбрали JavaScript
Нас никто не ограничивал в выборе, поэтому исходили из простой логики — чем легче язык программирования (дальше ЯП), тем проще должен был получиться результат. Поэтому из топ-3 наиболее популярных ЯП — Java, Python и JavaScript — мы остановились на JavaScript из-за простоты и наиболее низкого порога входа для начинающего специалиста. Кроме того, выбор был сделан в пользу JavaScript еще и потому, что вся фронтенд часть написана на нем и предполагалось, что ребята-фронтендеры смогут помочь выстроить правильную архитектуру автоматизации в компании в целом.
Также мы сравнивали работу PHP и JS с нашими фреймворками — JS показывает лучшие результаты по скорости работы с простыми операциями. А это критически важно для большой системы и большого количества тестов.
Какие тесты начали автоматизировать и почему
Процесс автоматизации мы начали именно с интеграционных API-тестов. Исторически проект разрастался в функционале без сопутствующих unit и компонентных тестов. Чтобы не нарушать нить построения внутренней архитектуры и методологии, было принято решение начать именно с той ступени тестирования, с которой начинается зона ответственности тестировщиков. Постарались сделать именно так, чтобы не отвлекать разработчиков на написание тестов, а наоборот упростить процесс разработки и помочь команде поддерживать максимальное качество на проекте.
Немного о фреймворке тестирования
Первое что мы сделали — это выбрали фреймворк. Выбирали между фреймворками JEST, Mocha и другими. Выбор пал на JEST — как самый быстрый из всех.
JEST делает быстрым сочетание нескольких факторов:
- распараллеливание
- запуск медленных тестов, что гарантирует, что все ядра процессора используются максимально
- использование кеширования преобразований
- устанавливаем node.js
- устанавливаем любой редактор кода (изначально мы использовали VS Code)
- создаем папку с проектом и создаем package.json (для подключения библиотек)
npm init -y - подключаем сам фреймворк JEST
/npm i jest --save-dev - настраиваем в файле package.json запуск Jest через команду “test”
“test”: “jest”
},
- И вот настал момент попробовать создать первый простейший тест – убедимся, что 1+1 = 2
touch first.test.js - Воспользуемся встроенной функцией expect (подробнее тут: https://jestjs.io/docs/en/expect)
it("Тест 1.1", function() {
expect(1 + 1).toBe(2)
})
})
• Запускаем наш с вами первый тест
npm test
Это было слишком просто, скажете вы! Да, так и есть. Писать API-автотесты на JavaScript + Jest — это просто!
Для автотестов на стороне клиента существуют разные request-библиотеки. Мы у себя используем библиотеку supertest (более подробнее тут: https://www.npmjs.com/package/supertest)
- Подключим ее и посмотрим какие возможности она дает
npm install --save-dev supertest - Прежде чем экспериментировать с нашими серверами, мы нашли в Интернете бесплатные и открытые API (мы пробовали на https://reqres.in/)
const request = require('supertest')
const agent = request('https://reqres.in/api')
describe("Тест 2 - ну что-нибудь посложнее", function() {
it("Тест 2.1", function(done) {
agent
.get('/user')
.expect('Content-Type', /json/)
.expect(200, done)
})
})
Дальше были проверены не только get-запросы, но и post/put, а также циклы и прочие особенности.
Вроде бы все неплохо, но не хватало вспомогательных функций. Мы хотели видеть, на какой строчке упал автотест. Для этого использовали
expect(res.statusCode).toEqual(400))
Дальше захотели узнать, какой был запрос отправлен и для этого изучили reject, составив при этом такое условие:
if (err) {
reject(`\r\nОшибка: ${err.stack.replace(/[\"\\]/g, '')}\r\n\r\nДанные:
${JSON.stringify(res, null, 2).replace(/[\"\\]/g, '')}`)
} else {
resolve(res)
}
Дальше, конечно же, захотели отчёты в Allure и собственных метриках. Всю информацию записывали в xml-файл и собирали с помощью jest-allure.На этом интересные моменты не закончились, и мы научились работать с авторизацией в нашей системе и шифрованием.
В заключительной части — мультиплатформенный запуск (Win, Linux, Mac) и запуск тестов на разных окружениях (local/office/stage/prod). Также нам удалось покрыть ещё и межсервисные API, и, вуаля на каждый сервис было написано еще около 300 тестов.
Что в итоге?
Подведу итоги за полгода работы одного тестировщика, выделенного на каждом проекте для автоматизации:
- стабильные и быстрые тесты
- настроили pipeline в gitlab и автоматические запуски тестов
- настроили автоматический запуск на окружениях office/stage/prod разные тестовые наборы
- настроили бота, который автоматически информирует в общий канал с автотестами об успешности/неуспешности запусков
Можно заметить, что 1189 тестов проводится всего за 3,5 минуты на одном проекте и 508 тестов за 1 минуту на другом! Мы считаем, что это отличный результат, учитывая, что раньше эти процессы выполнялись вручную целой командой тестирования минимум 1 день.
- автоматически собираем coverage автотестов на проектах
За полгода добились стабильности в Pipeline, создали утренние и вечерние прогоны автотестов на разных окружениях, а также написали собственные дашборды качества автоматизации тестирования на проектах. Это небольшой срок от момента старта до реализации.
Стоит упомянуть также о том, что мы не рассчитывали ROI перед внедрением автоматизации в проект, хотя информации о том, как считать этот показатель много в виде отдельных статей и других источниках. Понимаем, что это не было правильным решением и лучше бы предварительно посчитать стоимость, однако автоматизация, тем не менее, оказалась выгодным вложением усилий и ресурсов.
Что в планах?
Уже положено начало покрытия проекта E2E тестами. Также поставили себе цель — время выполнения любых тестов не должно превышать 15-18 минут. Это позволит быстро проверять любой сценарий и сделать первый шаг к непрерывной выкладке фич. Ещё один показатель, которого хотим добиться — время на реализацию автотеста не должно превышать 3 рабочих дней, тем самым все новые фичи на проекте при повторных проверках будут автоматизированы, исключая при этом «человеческий фактор».
Изи-пизи автотесты на JavaScript
Автоматизация всё ещё остаётся сложным и затратным процессом. Часто на это уходит много времени QA-автоматизаторов и нередко самих разработчиков на проекте. Но все эти расходы можно сократить, если...
habr.com