Pull to refresh
14
Karma
0
Rating
Антон Нечеухин @Antnch

QA

  • Followers 11
  • Following

Роль QA Lead в продуктовой компании: особенности и зоны ответственности

Miro corporate blog IT systems testing *Web services testing *Mobile applications testing *Development Management *

QA Lead в Miro отвечает за стратегию качества большой части продукта, реализацию крупных инженерных инициатив и развитие QA-инженеров.

Я как Head of QA расскажу о зонах ответственности QA лида, но прежде кратко расскажу о наших структуре разработки и процессе обеспечения качества, потому что это даёт понимание основных принципов работы.

Читать далее
Total votes 9: ↑9 and ↓0 +9
Views 7.5K
Comments 0

QA process at Miro

Miro corporate blog IT systems testing *Web services testing *Mobile applications testing *Development Management *
We have been working on our current QA process for about two years, and we still keep improving it. This process may seem obvious, but when we started to implement it in a new team that consisted entirely of new developers, we realized that it was difficult to do right away. Many people are used to working differently and need to make a lot of changes at once to switch, which is difficult. At the same time, it is ill-advised to implement this process in parts, because it can negatively affect the quality.

What do we do? We need to do preliminary preparation for each block of the development process: task decomposition, evaluation and planning, development itself, investigative testing, and release. This preparation does not consist of simply throwing old parts out of the process but of their adequate replacement, which increases quality.

In this article, I will talk in detail about our testing process at each stage of creating a new feature and also about the introduced changes that have increased the quality and speed of development.

image
Read more →
Total votes 1: ↑1 and ↓0 +1
Views 1.5K
Comments 0

QA-процесс в Miro: отказ от водопада и ручного тестирования, передача ответственности за качество всей команде

Miro corporate blog IT systems testing *Web services testing *Mobile applications testing *Development Management *
Наш текущий QA-процесс мы прорабатывали порядка двух лет и он продолжает активно развиваться. Он может казаться очевидным, но когда мы начали внедрять его в новой команде, которая полностью состояла из новых разработчиков, то поняли, что сразу внедрить его сложно. Многие привыкли работать иначе и для переключения им требуется сделать единовременно много изменений — это сложно. Однако внедрять такой процесс частями тоже нельзя, потому что это может негативно сказаться на качестве.

Что делать? Нужна предварительная подготовка по каждому из блоков процесса разработки: декомпозиция задачи, оценка и планирование, непосредственно разработка, исследовательское тестирование, релиз. Подготовка заключается не в простом выбрасывании старых частей из процесса, а в их адекватной замене, которая даёт прирост в качестве.

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


Читать дальше →
Total votes 16: ↑16 and ↓0 +16
Views 16K
Comments 14

Managing hundreds of servers for load testing: autoscaling, custom monitoring, DevOps culture

Miro corporate blog IT systems testing *Amazon Web Services *Web services testing *DevOps *
In the previous article, I talked about our load testing infrastructure. On average, we use about 100 servers to create a load, about 150 servers to run our service. All these servers need to be created, configured, started, deleted. To do this, we use the same tools as in the production environment to reduce the amount of manual work:

  • Terraform scripts for creating and deleting a test environment;
  • Ansible scripts for configuring, updating, starting servers;
  • In-house Python scripts for dynamic scaling, depending on the load.

Thanks to the Terraform and Ansible scripts, all operations ranging from creating instances to starting servers are performed with only six commands:

#launch the required instances in the AWS console
ansible-playbook deploy-config.yml #update servers versions
ansible-playbook start-application.yml #start our app on these servers
ansible-playbook update-test-scenario.yml --ask-vault-pass #update the JMeter test scenario if it was changed
infrastructure-aws-cluster/jmeter_clients:~# terraform apply #create JMeter servers for creating the load
playbook start-jmeter-server-cluster.yml #start the JMeter cluster
ansible-playbook start-stress-test.yml #start the test

Read more →
Total votes 1: ↑1 and ↓0 +1
Views 918
Comments 0

Reliable load testing with regards to unexpected nuances

Miro corporate blog IT systems testing *System Analysis and Design *Web services testing *Product Management *
We thought about building the infrastructure for large load tests a year ago when we reached the mark of 12,000 simultaneously active online users. In three months, we made the first version of the test, which showed us the limits of the service.

The irony is that simultaneously with the launch of the test, we reached the limits on the production server, resulting in two-hour service downtime. This further encouraged us to move from making occasional tests to establishing an effective load testing infrastructure. By infrastructure, I mean all tools for working with load testing: tools for launching the test (manual and automatic), the cluster that creates the load, a production-like cluster, metrics and reporting services, scaling services, and the code to manage it all.

image

Simplified, this is what our structure looks like: a collection of different servers that somehow interact with each other, each server performing specific tasks. It seemed that to build the load testing infrastructure, it was enough for us to make this diagram, take account of all interactions, and start creating test cases for each block one by one.

This approach is right, but it would have taken many months, which was not suitable for us because of our rapid growth — over the past twelve months, we have grown from 12,000 to 100,000 simultaneously active online users. Also, we didn’t know how our service infrastructure would respond to the increased load: which blocks would become the bottleneck, and which would scale linearly?
Read more →
Total votes 4: ↑4 and ↓0 +4
Views 928
Comments 0

Управление сотнями серверов для нагрузочного теста: автомасштабирование, кастомный мониторинг, DevOps культура

Miro corporate blog IT systems testing *Web services testing *DevOps *
В прошлой статье я рассказал про нашу инфраструктуру большого нагрузочного теста. В среднем мы создаём порядка 100 серверов для подачи нагрузки и порядка 150 серверов для работы нашего сервиса. Все эти сервера нужно создавать, удалять, конфигурировать и запускать. Мы используем для этого те же инструменты, что и на проде, чтобы уменьшить количество ручной работы:

  • Для создания и удаления тестового окружения — Terraform скрипты;
  • Для конфигурирования, обновления и запуска — Ansible скрипты;
  • Для динамического масштабирования в зависимости от нагрузки — самописные Python-скрипты.

Благодаря скриптам Terraform и Ansible, все операции от создания инстансов до запуска сервера выполняются всего шестью командами:

#запускаем нужные инстансы в консоли aws
ansible-playbook deploy-config.yml  #обновляем версии серверов
ansible-playbook start-application.yml  #запускаем наше приложение на этих серверах
ansible-playbook update-test-scenario.yml --ask-vault-pass #обновляем Jmeter сценарий, если в нём были изменения
infrastructure-aws-cluster/jmeter_clients:~# terraform apply #создаем jmeter сервера для подачи нагрузки
ansible-playbook start-jmeter-server-cluster.yml #запускаем jmeter кластер
ansible-playbook start-stress-test.yml #запускаем тест

Читать дальше →
Total votes 4: ↑4 and ↓0 +4
Views 5.7K
Comments 0

Достоверный нагрузочный тест с учётом непредвиденных нюансов

Miro corporate blog IT systems testing *System Analysis and Design *Web services testing *Product Management *
Мы задумались о построении инфраструктуры больших нагрузочных тестов год назад, когда достигли отметки в 12K онлайн-пользователей, работающих в нашем сервисе одновременно. За 3 месяца мы сделали первую версию теста, которая показала лимиты сервиса.

Ирония судьбы в том, что одновременно с запуском теста мы достигли лимитов на проде, в результате чего сервис упал на 2 часа. Это дополнительно стимулировало нас начать двигаться от проведения тестов от случая к случаю к созданию эффективной нагрузочной инфраструктуры. Под инфраструктурой я подразумеваю все инструменты для работы с нагрузкой: инструменты для запуска и автозапуска, кластер для подачи нагрузки, кластер, аналогичный проду, сервисы для сбора метрик и для подготовки отчётов, код для управления всем этим и сервисы для масштабирования.


Читать дальше →
Total votes 10: ↑10 and ↓0 +10
Views 6.8K
Comments 2

Information

Rating
Does not participate
Works in
Date of birth
Registered
Activity