Начну с того, что не стану открывать для кого-то «Америку», а хочу поделиться собственным опытом и лайфхаками для тех, кто желает что-то изменить в своей работе, но так еще и не определился с подходом к тестированию и/или технологиями.
Отдел QA, как правило, нагружен постоянно: «контроль качества» в разных формах нужен it-подразделениям на протяжении всего этапа разработки программного продукта, от получения требований до финального релиза. Работы очень много, без ее автоматизации трудно обойтись.
Знаете, за что я люблю работу в QA? Мы – «универсальные солдаты», которые задействованы во всех аспектах работы над проектом, а поэтому нам нужна широчайшая квалификация в разных вопросах. Это чертовски круто, но очень непросто!
Большинство воспринимают QA-отдел как последний фронтир, отделяющий процессы разработки от точки «в продакшн», но это не совсем так. Наше участие необходимо на протяжении всей работы над проектом, причем всем отделам компании. Наши «внутренние заказчики»: разработчики, DevOps- и дата-инженеры, аналитики, специалисты по ML (machine learning) & CV (computer vision).
Что нужно для стабильной работы отделам? Запросы бывают самые разные. Команда аналитиков должна быть уверена, что данные «витрин», из которых в последствии строятся аналитические отчеты, достаточно точны. Дата-инженеры ожидают, что механизмы загрузки данных работают корректно, для этого механизмы должны быть протестированы. Разработчики хотят, чтобы все баги были обнаружены на ранних стадиях. Специалисты по ML и CV рассчитывают получить для построения моделей обучения данные эталонного качества. DevOps -инженерам нужна функциональность системно проверенная, чтобы в последствии не делать одну и ту же работу многократно, выполняя «откаты» неработающих модулей…
Специалист в направлении автоматизации должен обладать широким кругозором знаний в области разработки, при написании корректных автоматизированных проверок, администрировании — при самостоятельной настройке тестового окружения, аналитики — при написании планов тестирования. Набор необходимых знаний и умений постоянно расширяется! Например, недавно нам стали обязательно нужны навыки, характерные для специалиста по «большим данным» – возникают задачи контроля качества данных – и знание AI-инструментов, без которых с BigData не справишься.
Как видите работы у QA-отдела всегда очень много! Поэтому нам нужны инструменты, чтобы автоматизировать все, что только можно автоматизировать. Как это выглядит на практике, сейчас и поговорим на одном из примеров.
«Семь дюжин зайцев не заменят лошадь»!
Сформировать команду тестирования можно несколькими способами:
На мой взгляд, допустимы оба способа. Благодаря первому можно сразу получить прирост в качестве продукта, однако процесс реализации QA, у развивающегося продукта, с каждым днем становится все сложнее и занимает больше времени: все больше появляется задач, для решения которых нужен прогон тест-кейсов в течение нескольких часов или даже дней. Сложность процессов растет лавинообразно, некоторые виды тестирования выполнять «руками» оказывается или нецелесообразно, или практически не предоставляется возможным. Поэтому, как вы уже догадались, был выбран второй способ.
Итак, мы приходим к необходимости уметь автоматизировать тестирование. Как обычно бывает, при автоматизации нужно некоторое время на создание алгоритмов и их реализацию «в коде», но – «лучше день потерять, а потом за пять минут долететь», как было сказано в известном фильме. Правильный код всегда работает быстрее «мануальных» проверок, при этом не устает, не спит и не теряет фокус внимания, поэтому качество контроля остается на высоком уровне.
Что нужно для быстрого создания кода? Умение писать автономные фреймворки. Тут нужен хороший инструментарий, достаточно гибкий, знакомый и при этом универсальный по отношению к технологиям разрабатываемого продукта, а технологий может быть много, ох как много!
Что «под капотом» у фреймворка?
Теоретически «фреймворк» – программная платформа, на которой можно построить единый инструмент. В нашем случае это инструмент, способный тестировать различные виды систем управления баз данных, способный на функциональное, интеграционное и пользовательское тестирование, умеющий создавать нагрузки для приложений и, разумеется, умеющий строить отчеты по завершении процессов проверки (куда же без отчетов сегодня!).
Современный фреймворк должен состоять из набора элементов, включающего в себя как универсальные, так и специализированные инструменты. Поэтому наш фреймворк состоит из следующих технологий.
Python – язык программирования общего назначения, на котором можно реализовать любые задачи тестирования. Язык очень гибкий, хорошо интегрируемый, для нас также важно, что к нему есть много разных прикладных библиотек и его знают много разработчиков. Это почти как эсперанто, только Python.
Pytest – специализированная среда тестирования, основанная все на том же Python, которую применяют для написания и выполнения тестовых скриптов. Мы используем Pytest в качестве системы для запуска тестов, генерации тестовых коллекций, проверки входных и выходных данных, диагностики тестов и построения отчетов о тестировании. Pytest мы выбрали исходя из преимуществ, важных для наших задач, этот инструмент позволяет запускать параллельные тесты, имеет средства гибкого управления подмножеством тестов непосредственно во время их работы, получил мощный набор декораторов для реализации логики формирования тестовых систем и т.д. При этом синтаксис прост, а инструмент полностью бесплатен.
SQL – по понятной причине выбран в качестве языка для взаимодействия с реляционными базами данных.
Selenium webdriver – инструмент для автоматизации действий браузера, который используем по прямому назначению.
Bash – специализированный командный интерпретатор, на котором пишем сценарии для конвейера сборки, тестирования и разворачивания программного продукта на тестовом контуре.
GitLab – инструмент для CI/CD-процессов и управления репозиториями кода для Git.
Jmeter – отличный инструмент для реализации нагрузочного тестирования, который мы использовали некоторое время. Но мы заменили его собственной самописной библиотекой на основе requests и multiprocessing.
«Лучше один раз увидеть…»
Рассмотрим несколько небольших примеров. В них будут некоторые базовые, но вполне рабочие компоненты автоматизированного тестирования, которые так или иначе участвуют в текущем процессе проверок.
Пример использования нативного коннектора к СУБД ClickHouse при помощи Python:
Теперь данную функцию можно использовать для взаимодействия с базой, отправляя в нее скрипт проверки.
Скрипт SQL проверки:
Функция GREATER в данном случае вернет 0 (при неудаче) или 1 (при успехе), а в зависимости от результата далее можно производить нужное действие.
Пример функционального тестирования и тестирования UI при помощи Selenium:
В следующем примере мы запускаем проверку тестовой web-страницы в фоновом режиме. Сначала проверим статус ответа страницы на http-запрос, затем UI-контент на странице, потом – успешность авторизации пользователя.
Пример сценария конвейера в gitlab-ci:
Вот так выглядит прохождение всего этапа сборки, тестирования и деплоя приложения:
Как видите, все просто! Конечно, это малая доля того, что умеет фреймворк, но примеры показывают, насколько легко применять инструменты, они очень гибки и их легко освоить.
В заключении
Итак, нам удалось построить фреймворк автоматизации, который может осуществить любые виды проверок и который при помощи git submodule add -b можно «прикрутить» к любому проекту. Рутинные, долгие и считавшиеся «ручными» процессы тестирования мы автоматизируем этим же фреймворком. Для простоты взаимодействия наладили систему, отправляющую уведомления и отчеты о результатах тестирования на корпоративную почту и в популярные мессенджеры всем заинтересованным лицам, что позволяет контролировать процессы и, что важно, оперативно реагировать на возникающие инциденты.
При этом мы только в начале пути! Функциональные возможности постоянно расширяются, у нас еще много наработок и идей, о которых я расскажу в других постах. Искренне надеюсь, что рассказ окажется полезным, поможет в выборе технологий для автоматизации QA и/или в выборе пути для развития.
Виталий Филаретов,
руководитель отдела контроля качества департамента управления данными компании Uma.Tech
Отдел QA, как правило, нагружен постоянно: «контроль качества» в разных формах нужен it-подразделениям на протяжении всего этапа разработки программного продукта, от получения требований до финального релиза. Работы очень много, без ее автоматизации трудно обойтись.
Знаете, за что я люблю работу в QA? Мы – «универсальные солдаты», которые задействованы во всех аспектах работы над проектом, а поэтому нам нужна широчайшая квалификация в разных вопросах. Это чертовски круто, но очень непросто!
Большинство воспринимают QA-отдел как последний фронтир, отделяющий процессы разработки от точки «в продакшн», но это не совсем так. Наше участие необходимо на протяжении всей работы над проектом, причем всем отделам компании. Наши «внутренние заказчики»: разработчики, DevOps- и дата-инженеры, аналитики, специалисты по ML (machine learning) & CV (computer vision).
Что нужно для стабильной работы отделам? Запросы бывают самые разные. Команда аналитиков должна быть уверена, что данные «витрин», из которых в последствии строятся аналитические отчеты, достаточно точны. Дата-инженеры ожидают, что механизмы загрузки данных работают корректно, для этого механизмы должны быть протестированы. Разработчики хотят, чтобы все баги были обнаружены на ранних стадиях. Специалисты по ML и CV рассчитывают получить для построения моделей обучения данные эталонного качества. DevOps -инженерам нужна функциональность системно проверенная, чтобы в последствии не делать одну и ту же работу многократно, выполняя «откаты» неработающих модулей…
Специалист в направлении автоматизации должен обладать широким кругозором знаний в области разработки, при написании корректных автоматизированных проверок, администрировании — при самостоятельной настройке тестового окружения, аналитики — при написании планов тестирования. Набор необходимых знаний и умений постоянно расширяется! Например, недавно нам стали обязательно нужны навыки, характерные для специалиста по «большим данным» – возникают задачи контроля качества данных – и знание AI-инструментов, без которых с BigData не справишься.
Как видите работы у QA-отдела всегда очень много! Поэтому нам нужны инструменты, чтобы автоматизировать все, что только можно автоматизировать. Как это выглядит на практике, сейчас и поговорим на одном из примеров.
«Семь дюжин зайцев не заменят лошадь»!
Сформировать команду тестирования можно несколькими способами:
- Нанять большое количество «мануальных» специалистов, чтобы они вручную проводили тестирование, тем самым обеспечивая QA.
- Нанять компактную команду автоматизаторов, которая создаст для проекта необходимый набор автоматизированных тестов. Разнообразные виды тестов будут выполняться машинами, заказанное количество проверок будет выполнено, по итогам нужные отчеты оформлены – и все это с минимальным участием человека.
На мой взгляд, допустимы оба способа. Благодаря первому можно сразу получить прирост в качестве продукта, однако процесс реализации QA, у развивающегося продукта, с каждым днем становится все сложнее и занимает больше времени: все больше появляется задач, для решения которых нужен прогон тест-кейсов в течение нескольких часов или даже дней. Сложность процессов растет лавинообразно, некоторые виды тестирования выполнять «руками» оказывается или нецелесообразно, или практически не предоставляется возможным. Поэтому, как вы уже догадались, был выбран второй способ.
Итак, мы приходим к необходимости уметь автоматизировать тестирование. Как обычно бывает, при автоматизации нужно некоторое время на создание алгоритмов и их реализацию «в коде», но – «лучше день потерять, а потом за пять минут долететь», как было сказано в известном фильме. Правильный код всегда работает быстрее «мануальных» проверок, при этом не устает, не спит и не теряет фокус внимания, поэтому качество контроля остается на высоком уровне.
Что нужно для быстрого создания кода? Умение писать автономные фреймворки. Тут нужен хороший инструментарий, достаточно гибкий, знакомый и при этом универсальный по отношению к технологиям разрабатываемого продукта, а технологий может быть много, ох как много!
Что «под капотом» у фреймворка?
Теоретически «фреймворк» – программная платформа, на которой можно построить единый инструмент. В нашем случае это инструмент, способный тестировать различные виды систем управления баз данных, способный на функциональное, интеграционное и пользовательское тестирование, умеющий создавать нагрузки для приложений и, разумеется, умеющий строить отчеты по завершении процессов проверки (куда же без отчетов сегодня!).
Современный фреймворк должен состоять из набора элементов, включающего в себя как универсальные, так и специализированные инструменты. Поэтому наш фреймворк состоит из следующих технологий.
Python – язык программирования общего назначения, на котором можно реализовать любые задачи тестирования. Язык очень гибкий, хорошо интегрируемый, для нас также важно, что к нему есть много разных прикладных библиотек и его знают много разработчиков. Это почти как эсперанто, только Python.
Pytest – специализированная среда тестирования, основанная все на том же Python, которую применяют для написания и выполнения тестовых скриптов. Мы используем Pytest в качестве системы для запуска тестов, генерации тестовых коллекций, проверки входных и выходных данных, диагностики тестов и построения отчетов о тестировании. Pytest мы выбрали исходя из преимуществ, важных для наших задач, этот инструмент позволяет запускать параллельные тесты, имеет средства гибкого управления подмножеством тестов непосредственно во время их работы, получил мощный набор декораторов для реализации логики формирования тестовых систем и т.д. При этом синтаксис прост, а инструмент полностью бесплатен.
SQL – по понятной причине выбран в качестве языка для взаимодействия с реляционными базами данных.
Selenium webdriver – инструмент для автоматизации действий браузера, который используем по прямому назначению.
Bash – специализированный командный интерпретатор, на котором пишем сценарии для конвейера сборки, тестирования и разворачивания программного продукта на тестовом контуре.
GitLab – инструмент для CI/CD-процессов и управления репозиториями кода для Git.
Jmeter – отличный инструмент для реализации нагрузочного тестирования, который мы использовали некоторое время. Но мы заменили его собственной самописной библиотекой на основе requests и multiprocessing.
«Лучше один раз увидеть…»
Рассмотрим несколько небольших примеров. В них будут некоторые базовые, но вполне рабочие компоненты автоматизированного тестирования, которые так или иначе участвуют в текущем процессе проверок.
Пример использования нативного коннектора к СУБД ClickHouse при помощи Python:
from clickhouse_driver.client import Client
def clickhouse_connection():
client = Client(
host=os.environ['DB_HOST'],
user=os.environ['DB_USERNAME'],
password=os.environ['DB_PASSWORD'],
database=os.environ['DB_NAME']
)
return clientТеперь данную функцию можно использовать для взаимодействия с базой, отправляя в нее скрипт проверки.
Скрипт SQL проверки:
SELECT greater(
(SELECT toInt32(count(*)) as yesterday_count
FROM test_table
WHERE toDate(date) = toDate(now()) - 1),
(SELECT toInt32(avg(counter)) as avg_count
FROM
(SELECT toDate(date) as date_add, count(*) as counter
FROM test_table
WHERE date_add < toDate(now()) - 1
GROUP BY toDate(date)
)))
Функция GREATER в данном случае вернет 0 (при неудаче) или 1 (при успехе), а в зависимости от результата далее можно производить нужное действие.
Пример функционального тестирования и тестирования UI при помощи Selenium:
class UiElements:
url = 'test'
def get_webdriver(self):
options = webdriver.FirefoxOptions()
options.headless = True
driver = webdriver.Firefox(
executable_path=os.environ['GECKO_PATH'],
options=options
)
return driver
def admin_login(self):
try:
driver = self.get_webdriver()
driver.get(self.url)
username = driver.find_element_by_id('id_username')
password = driver.find_element_by_id('id_password')
username.send_keys('test_name')
password.send_keys('test_password')
driver.find_element_by_xpath('//input[@type="submit" and @value="Log in"]').click()
return driver
except Exception as err:
raise err
class TestUI(UiElements):
test_url = UiElements.url
def test_response_status(self):
response = requests.get(self.test_url)
assert response.status_code == 200, 'response status code != 200'
def test_admin_login(self):
driver = UiElements().admin_login()
driver.quit()
В следующем примере мы запускаем проверку тестовой web-страницы в фоновом режиме. Сначала проверим статус ответа страницы на http-запрос, затем UI-контент на странице, потом – успешность авторизации пользователя.
Пример сценария конвейера в gitlab-ci:
run_prepare_data:
stage: test_app
image: [имя тестового контейнера]
when: manual
allow_failure: false
only:
- test
environment:
name: $CI_COMMIT_REF_NAME
script:
- pytest -vls run_django_task.py
- pytest -vls check_django_task.py
test_recommendation_app:
stage: test_app
image: [имя тестового контейнера]
only:
- test
environment:
name: $CI_COMMIT_REF_NAME
script:
- pytest -vls test_recommendation.py
test_recommendation_facade:
stage: test_app
image: [имя тестового контейнера]
only:
- test
environment:
name: $CI_COMMIT_REF_NAME
script:
- pytest -vls test_facade.py
perfomance_recommendation_test:
stage: perfomance_test_app
image: [имя тестового контейнера]
needs: [test_recommendation_app]
only:
- test
environment:
name: $CI_COMMIT_REF_NAME
script:
- pytest -vls load_testing.py
Вот так выглядит прохождение всего этапа сборки, тестирования и деплоя приложения:
Как видите, все просто! Конечно, это малая доля того, что умеет фреймворк, но примеры показывают, насколько легко применять инструменты, они очень гибки и их легко освоить.
В заключении
Итак, нам удалось построить фреймворк автоматизации, который может осуществить любые виды проверок и который при помощи git submodule add -b можно «прикрутить» к любому проекту. Рутинные, долгие и считавшиеся «ручными» процессы тестирования мы автоматизируем этим же фреймворком. Для простоты взаимодействия наладили систему, отправляющую уведомления и отчеты о результатах тестирования на корпоративную почту и в популярные мессенджеры всем заинтересованным лицам, что позволяет контролировать процессы и, что важно, оперативно реагировать на возникающие инциденты.
При этом мы только в начале пути! Функциональные возможности постоянно расширяются, у нас еще много наработок и идей, о которых я расскажу в других постах. Искренне надеюсь, что рассказ окажется полезным, поможет в выборе технологий для автоматизации QA и/или в выборе пути для развития.
Виталий Филаретов,
руководитель отдела контроля качества департамента управления данными компании Uma.Tech