#регрессионное_тестирование — Public Fediverse posts

Разбираемся в многообразии видов тестирования

Когда начинаешь погружаться в тестирование, создается ощущение, что видов этого самого тестирования десятки, если не сотни, и все они постоянно используются в реальной работе. Из-за этого у многих возникает ложное ощущение, что для работы тестировщиком нужно разбираться во всех этих подходах и уметь применять каждый из них. Но более чем за шесть лет работы в тестировании я понял одну вещь: теория этой работы сильно отличается от практики. Чаще всего используется ограниченный набор видов тестирования, которые закрывают большую часть задач. Причем это не абстрактные академические термины, а конкретные подходы и практики, с которыми вы сталкиваетесь почти каждый день. В этой статье рассмотрим пять видов тестирования, которые применяются чаще всего. Заодно разберем, как они выглядят в реальной работе, когда используются и какие ошибки чаще всего с ними связаны.

https://habr.com/ru/companies/selectel/articles/1034602/

#selectel #тестирование #qa #регрессионное_тестирование #smokeтестирование #исследовательское_тестирование #тестирование_на_проде #теория_тестирования #для_начинающих

Разбираемся в многообразии видов тестирования

Когда начинаешь погружаться в тестирование, создается ощущение, что видов этого самого тестирования десятки, если не сотни, и все они постоянно используются в реальной работе. Из-за этого у многих возникает ложное ощущение, что для работы тестировщиком нужно разбираться во всех этих подходах и уметь применять каждый из них. Но более чем за шесть лет работы в тестировании я понял одну вещь: теория этой работы сильно отличается от практики. Чаще всего используется ограниченный набор видов тестирования, которые закрывают большую часть задач. Причем это не абстрактные академические термины, а конкретные подходы и практики, с которыми вы сталкиваетесь почти каждый день. В этой статье рассмотрим пять видов тестирования, которые применяются чаще всего. Заодно разберем, как они выглядят в реальной работе, когда используются и какие ошибки чаще всего с ними связаны.

https://habr.com/ru/companies/selectel/articles/1034602/

#selectel #тестирование #qa #регрессионное_тестирование #smokeтестирование #исследовательское_тестирование #тестирование_на_проде #теория_тестирования #для_начинающих

Разбираемся в многообразии видов тестирования

Когда начинаешь погружаться в тестирование, создается ощущение, что видов этого самого тестирования десятки, если не сотни, и все они постоянно используются в реальной работе. Из-за этого у многих возникает ложное ощущение, что для работы тестировщиком нужно разбираться во всех этих подходах и уметь применять каждый из них. Но более чем за шесть лет работы в тестировании я понял одну вещь: теория этой работы сильно отличается от практики. Чаще всего используется ограниченный набор видов тестирования, которые закрывают большую часть задач. Причем это не абстрактные академические термины, а конкретные подходы и практики, с которыми вы сталкиваетесь почти каждый день. В этой статье рассмотрим пять видов тестирования, которые применяются чаще всего. Заодно разберем, как они выглядят в реальной работе, когда используются и какие ошибки чаще всего с ними связаны.

https://habr.com/ru/companies/selectel/articles/1034602/

#selectel #тестирование #qa #регрессионное_тестирование #smokeтестирование #исследовательское_тестирование #тестирование_на_проде #теория_тестирования #для_начинающих

Разбираемся в многообразии видов тестирования

Когда начинаешь погружаться в тестирование, создается ощущение, что видов этого самого тестирования десятки, если не сотни, и все они постоянно используются в реальной работе. Из-за этого у многих возникает ложное ощущение, что для работы тестировщиком нужно разбираться во всех этих подходах и уметь применять каждый из них. Но более чем за шесть лет работы в тестировании я понял одну вещь: теория этой работы сильно отличается от практики. Чаще всего используется ограниченный набор видов тестирования, которые закрывают большую часть задач. Причем это не абстрактные академические термины, а конкретные подходы и практики, с которыми вы сталкиваетесь почти каждый день. В этой статье рассмотрим пять видов тестирования, которые применяются чаще всего. Заодно разберем, как они выглядят в реальной работе, когда используются и какие ошибки чаще всего с ними связаны.

https://habr.com/ru/companies/selectel/articles/1034602/

#selectel #тестирование #qa #регрессионное_тестирование #smokeтестирование #исследовательское_тестирование #тестирование_на_проде #теория_тестирования #для_начинающих

Без рук: автоматизируем нагрузочное тестирование изменений в CI

Нагрузочное тестирование — одна из самых избегаемых тем, когда речь заходит о контроле качества ПО. Корпорации, конечно, не обходят его стороной, но если говорить о продуктах меньшего масштаба, то нагрузочное тестирование часто пропускается. Команда (и, в целом, справедливо) полагает, что продукт справится с нагрузкой — на малых объёмах это обычно прокатывает. А потом внезапно наступает день, когда пользователей стало больше, а система не готова. Почему команды не тащат нагрузку в релизный цикл? Потому что это чаще всего просто не окупается: нужно выбрать движок, описать сценарий, гонять тесты вручную или тратить время на создание собственной обвязки для встраивания в CI, придумать критерии качества и анализировать результаты. Всё это занимает значительное время, а на короткой дистанции часто оказывается оверинжинирингом. Но если формирование требований упростить концептуально невозможно, то всё остальное вполне можно собрать в переиспользуемый инструмент, позволяющий командам легко интегрировать нагрузочное тестирование и регрессионный анализ в свой процесс доставки. В CI/CD мы хотели простую штуку: на каждый PR запускать короткий перф‑смоук и получать ответ уровня «PASS / WARNING / DEGRADATION», а не 15 минут медитировать над CSV и тратить ценное время на анализ, который, вероятно, не пригодится в ближайшей перспективе. Посмотрим, к чему мы в итоге пришли.

https://habr.com/ru/articles/1033590/

#нагрузочное_тестирование #регрессионное_тестирование #locust #devops #locomotive #python #github_actions #performance_testing #cicd #производительность

Без рук: автоматизируем нагрузочное тестирование изменений в CI

Нагрузочное тестирование — одна из самых избегаемых тем, когда речь заходит о контроле качества ПО. Корпорации, конечно, не обходят его стороной, но если говорить о продуктах меньшего масштаба, то нагрузочное тестирование часто пропускается. Команда (и, в целом, справедливо) полагает, что продукт справится с нагрузкой — на малых объёмах это обычно прокатывает. А потом внезапно наступает день, когда пользователей стало больше, а система не готова. Почему команды не тащат нагрузку в релизный цикл? Потому что это чаще всего просто не окупается: нужно выбрать движок, описать сценарий, гонять тесты вручную или тратить время на создание собственной обвязки для встраивания в CI, придумать критерии качества и анализировать результаты. Всё это занимает значительное время, а на короткой дистанции часто оказывается оверинжинирингом. Но если формирование требований упростить концептуально невозможно, то всё остальное вполне можно собрать в переиспользуемый инструмент, позволяющий командам легко интегрировать нагрузочное тестирование и регрессионный анализ в свой процесс доставки. В CI/CD мы хотели простую штуку: на каждый PR запускать короткий перф‑смоук и получать ответ уровня «PASS / WARNING / DEGRADATION», а не 15 минут медитировать над CSV и тратить ценное время на анализ, который, вероятно, не пригодится в ближайшей перспективе. Посмотрим, к чему мы в итоге пришли.

https://habr.com/ru/articles/1033590/

#нагрузочное_тестирование #регрессионное_тестирование #locust #devops #locomotive #python #github_actions #performance_testing #cicd #производительность

Без рук: автоматизируем нагрузочное тестирование изменений в CI

Нагрузочное тестирование — одна из самых избегаемых тем, когда речь заходит о контроле качества ПО. Корпорации, конечно, не обходят его стороной, но если говорить о продуктах меньшего масштаба, то нагрузочное тестирование часто пропускается. Команда (и, в целом, справедливо) полагает, что продукт справится с нагрузкой — на малых объёмах это обычно прокатывает. А потом внезапно наступает день, когда пользователей стало больше, а система не готова. Почему команды не тащат нагрузку в релизный цикл? Потому что это чаще всего просто не окупается: нужно выбрать движок, описать сценарий, гонять тесты вручную или тратить время на создание собственной обвязки для встраивания в CI, придумать критерии качества и анализировать результаты. Всё это занимает значительное время, а на короткой дистанции часто оказывается оверинжинирингом. Но если формирование требований упростить концептуально невозможно, то всё остальное вполне можно собрать в переиспользуемый инструмент, позволяющий командам легко интегрировать нагрузочное тестирование и регрессионный анализ в свой процесс доставки. В CI/CD мы хотели простую штуку: на каждый PR запускать короткий перф‑смоук и получать ответ уровня «PASS / WARNING / DEGRADATION», а не 15 минут медитировать над CSV и тратить ценное время на анализ, который, вероятно, не пригодится в ближайшей перспективе. Посмотрим, к чему мы в итоге пришли.

https://habr.com/ru/articles/1033590/

#нагрузочное_тестирование #регрессионное_тестирование #locust #devops #locomotive #python #github_actions #performance_testing #cicd #производительность

Без рук: автоматизируем нагрузочное тестирование изменений в CI

Нагрузочное тестирование — одна из самых избегаемых тем, когда речь заходит о контроле качества ПО. Корпорации, конечно, не обходят его стороной, но если говорить о продуктах меньшего масштаба, то нагрузочное тестирование часто пропускается. Команда (и, в целом, справедливо) полагает, что продукт справится с нагрузкой — на малых объёмах это обычно прокатывает. А потом внезапно наступает день, когда пользователей стало больше, а система не готова. Почему команды не тащат нагрузку в релизный цикл? Потому что это чаще всего просто не окупается: нужно выбрать движок, описать сценарий, гонять тесты вручную или тратить время на создание собственной обвязки для встраивания в CI, придумать критерии качества и анализировать результаты. Всё это занимает значительное время, а на короткой дистанции часто оказывается оверинжинирингом. Но если формирование требований упростить концептуально невозможно, то всё остальное вполне можно собрать в переиспользуемый инструмент, позволяющий командам легко интегрировать нагрузочное тестирование и регрессионный анализ в свой процесс доставки. В CI/CD мы хотели простую штуку: на каждый PR запускать короткий перф‑смоук и получать ответ уровня «PASS / WARNING / DEGRADATION», а не 15 минут медитировать над CSV и тратить ценное время на анализ, который, вероятно, не пригодится в ближайшей перспективе. Посмотрим, к чему мы в итоге пришли.

https://habr.com/ru/articles/1033590/

#нагрузочное_тестирование #регрессионное_тестирование #locust #devops #locomotive #python #github_actions #performance_testing #cicd #производительность

Философия автотестов: управление, поддержка и флаки

Привет, меня зовут Смирнов Владимир, и я отвечаю за тестирование торгового бэкенда в EXANTE. Разработка кипит, регрессионные наборы автотестов растут - всё это сопровождается хаосом и различиями тестовых окружений, из-за чего неизбежно растёт и число нестабильных падений (ака флаки), за завесой которых могут теряться реальные проблемы. Как мы регулярно поддерживаем автотесты в приемлемом состоянии и стараемся не тратить на это слишком много времени? Об этом и поговорим.

https://habr.com/ru/articles/1032868/

#Тестирование #Разработка #Флакитесты #Регрессионное_тестирование #Тестовое_окружение #Управление_разработкой #Сервисные_тесты #Микросервисы #Обслуживание_тестсьюта

Философия автотестов: управление, поддержка и флаки

Привет, меня зовут Смирнов Владимир, и я отвечаю за тестирование торгового бэкенда в EXANTE. Разработка кипит, регрессионные наборы автотестов растут - всё это сопровождается хаосом и различиями тестовых окружений, из-за чего неизбежно растёт и число нестабильных падений (ака флаки), за завесой которых могут теряться реальные проблемы. Как мы регулярно поддерживаем автотесты в приемлемом состоянии и стараемся не тратить на это слишком много времени? Об этом и поговорим.

https://habr.com/ru/articles/1032868/

#Тестирование #Разработка #Флакитесты #Регрессионное_тестирование #Тестовое_окружение #Управление_разработкой #Сервисные_тесты #Микросервисы #Обслуживание_тестсьюта

Философия автотестов: управление, поддержка и флаки

Привет, меня зовут Смирнов Владимир, и я отвечаю за тестирование торгового бэкенда в EXANTE. Разработка кипит, регрессионные наборы автотестов растут - всё это сопровождается хаосом и различиями тестовых окружений, из-за чего неизбежно растёт и число нестабильных падений (ака флаки), за завесой которых могут теряться реальные проблемы. Как мы регулярно поддерживаем автотесты в приемлемом состоянии и стараемся не тратить на это слишком много времени? Об этом и поговорим.

https://habr.com/ru/articles/1032868/

#Тестирование #Разработка #Флакитесты #Регрессионное_тестирование #Тестовое_окружение #Управление_разработкой #Сервисные_тесты #Микросервисы #Обслуживание_тестсьюта

Философия автотестов: управление, поддержка и флаки

Привет, меня зовут Смирнов Владимир, и я отвечаю за тестирование торгового бэкенда в EXANTE. Разработка кипит, регрессионные наборы автотестов растут - всё это сопровождается хаосом и различиями тестовых окружений, из-за чего неизбежно растёт и число нестабильных падений (ака флаки), за завесой которых могут теряться реальные проблемы. Как мы регулярно поддерживаем автотесты в приемлемом состоянии и стараемся не тратить на это слишком много времени? Об этом и поговорим.

https://habr.com/ru/articles/1032868/

#Тестирование #Разработка #Флакитесты #Регрессионное_тестирование #Тестовое_окружение #Управление_разработкой #Сервисные_тесты #Микросервисы #Обслуживание_тестсьюта

Пара детективов с поиском багов в мобильных приложениях банков

Пока оперативка дорожает из-за LLM, в банках очень много ручного тестирования. Покрытие автотестами не очень высокое, потому что их тоже надо писать с AI, а ИБ закономерно запрещает доступ к внешним облачным моделям. Мы не можем просто взять закрытый код банка и скормить его публичной нейросети. По большей части на ручные тесты уезжают сверка логики процесса (end-to-end-сценарии) и тесты UI. Я работаю в команде Centicore, но мы сидим на стороне клиента — крупного банка — и занимаемся разработкой в его закрытой среде. То есть мы наёмная команда на продукте заказчика. Сейчас я хочу рассказать про несколько довольно странных багов из разных приложений. В силу тех самых требований ИБ я даже названий банка и проектов раскрыть не могу, но в деталях покажу, какие бывают приколы. Например, когда вы пересаживаете приложения с айфона на планшет.

https://habr.com/ru/companies/centicore_group/articles/1022782/

#ручное_тестирование #банковское_приложение #регрессионное_тестирование #pushуведомления #UIтестирование #endtoend_сценарии #IOS #Android #баги

Пара детективов с поиском багов в мобильных приложениях банков

Пока оперативка дорожает из-за LLM, в банках очень много ручного тестирования. Покрытие автотестами не очень высокое, потому что их тоже надо писать с AI, а ИБ закономерно запрещает доступ к внешним облачным моделям. Мы не можем просто взять закрытый код банка и скормить его публичной нейросети. По большей части на ручные тесты уезжают сверка логики процесса (end-to-end-сценарии) и тесты UI. Я работаю в команде Centicore, но мы сидим на стороне клиента — крупного банка — и занимаемся разработкой в его закрытой среде. То есть мы наёмная команда на продукте заказчика. Сейчас я хочу рассказать про несколько довольно странных багов из разных приложений. В силу тех самых требований ИБ я даже названий банка и проектов раскрыть не могу, но в деталях покажу, какие бывают приколы. Например, когда вы пересаживаете приложения с айфона на планшет.

https://habr.com/ru/companies/centicore_group/articles/1022782/

#ручное_тестирование #банковское_приложение #регрессионное_тестирование #pushуведомления #UIтестирование #endtoend_сценарии #IOS #Android #баги

Пара детективов с поиском багов в мобильных приложениях банков

Пока оперативка дорожает из-за LLM, в банках очень много ручного тестирования. Покрытие автотестами не очень высокое, потому что их тоже надо писать с AI, а ИБ закономерно запрещает доступ к внешним облачным моделям. Мы не можем просто взять закрытый код банка и скормить его публичной нейросети. По большей части на ручные тесты уезжают сверка логики процесса (end-to-end-сценарии) и тесты UI. Я работаю в команде Centicore, но мы сидим на стороне клиента — крупного банка — и занимаемся разработкой в его закрытой среде. То есть мы наёмная команда на продукте заказчика. Сейчас я хочу рассказать про несколько довольно странных багов из разных приложений. В силу тех самых требований ИБ я даже названий банка и проектов раскрыть не могу, но в деталях покажу, какие бывают приколы. Например, когда вы пересаживаете приложения с айфона на планшет.

https://habr.com/ru/companies/centicore_group/articles/1022782/

#ручное_тестирование #банковское_приложение #регрессионное_тестирование #pushуведомления #UIтестирование #endtoend_сценарии #IOS #Android #баги

Пара детективов с поиском багов в мобильных приложениях банков

Пока оперативка дорожает из-за LLM, в банках очень много ручного тестирования. Покрытие автотестами не очень высокое, потому что их тоже надо писать с AI, а ИБ закономерно запрещает доступ к внешним облачным моделям. Мы не можем просто взять закрытый код банка и скормить его публичной нейросети. По большей части на ручные тесты уезжают сверка логики процесса (end-to-end-сценарии) и тесты UI. Я работаю в команде Centicore, но мы сидим на стороне клиента — крупного банка — и занимаемся разработкой в его закрытой среде. То есть мы наёмная команда на продукте заказчика. Сейчас я хочу рассказать про несколько довольно странных багов из разных приложений. В силу тех самых требований ИБ я даже названий банка и проектов раскрыть не могу, но в деталях покажу, какие бывают приколы. Например, когда вы пересаживаете приложения с айфона на планшет.

https://habr.com/ru/companies/centicore_group/articles/1022782/

#ручное_тестирование #банковское_приложение #регрессионное_тестирование #pushуведомления #UIтестирование #endtoend_сценарии #IOS #Android #баги

От макета до пострелиза: путь новых сервисов глазами QA

Всем привет! Я Лина, инженер по обеспечению качества в Команде Контента и Трафика в Банки.ру. Я хочу рассказать, как мы работали над обновлением сложного сервиса – Народными рейтингами. В этой статье представлен каждый шаг от макетов до пострелизного теста: со своими заметками, выводами и, конечно, примерами конкретных багов, которые попадались во время работы над новыми Народными рейтингами и редизайном НРСК.

https://habr.com/ru/companies/banki/articles/1017660/

#тестирование_редизайна #QA_параллельная_разработка #тестирование_фронтенда_и_бэкенда #тесткейсы_для_QA #тестирование_на_моках #подключение_верстки_к_API #порядок_тестирования_задач #тестирование_дизайнмакетов #регрессионное_тестирование #баги_при_интеграции_фронт_бэк

Покрытие регресса автотестами: практический опыт внедрения E2E

По мере роста продукта регрессионное тестирование быстро становится узким местом: количество сценариев растет, время проверки увеличивается, а цена ошибки перед релизом становится выше. В нашем случае переход к E2E-автотестам стал способом ускорить регресс и основой стабильных, предсказуемых релизов. В статье делимся тем, как мы выстроили покрытие регресса автотестами и встроили его в рабочие процессы команды. Немного о проекте Проект представляет собой распределенную систему, состоящую из двух web-порталов на React, порядка двадцати микросервисов на .NET и нескольких интеграций со сторонними системами. Все компоненты участвуют в одном сквозном бизнес-процессе, а релизы выходят регулярно — в среднем раз в две недели. QA-инженер подключился к проекту уже после начала активной разработки. В этот момент мы осознанно отказались от наращивания объемной ручной тестовой документации и сделали ставку на E2E-автотесты. Почему Е2Е? Поддержание ручного регресса в актуальном состоянии задача важная для стабильного развития, но требует существенных затрат времени, вычитки и сверки с обновлениями. Часть кейсов теряют ценность, нужно время на их обнаружение. E2E-автотесты, напротив, становятся частью системы: они запускаются регулярно, отражают реальное состояние продукта и дают оперативный и понятный сигнал о готовности к релизу. Для нас автотесты стали стратегическим инструментом. Они заменили собой классический ручной регресс и со временем начали выполнять роль индикатора качества — как для команды разработки, так и для менеджмента и заказчиков.

https://habr.com/ru/articles/1003428/

#автотесты #e2e_тестирование #регрессионное_тестирование #cypress #typescript

Тест-менеджмент по agile: работающая документация

В крупных проектах управлять качеством вручную — весьма нетривиальная задача: объем требований и фичей, уточнений и доработок, баков и фиксов растет нелинейно, а риски — экспоненциально. В таких условиях необходимо структурировать процесс обеспечения качества (QA), чтобы предотвратить эффект «снежного кома», который может «завалить» тестировщиков — сначала фрустрацией от рутины, а потом недовольством заказчика.

https://habr.com/ru/companies/cinimex/articles/978492/

#jira #confluence #тестменеджемент #тестирование #qa_strategy #test_management_system #управление_качеством #визуализация #регрессионное_тестирование

Тест-менеджмент по agile: работающая документация

В крупных проектах управлять качеством вручную — весьма нетривиальная задача: объем требований и фичей, уточнений и доработок, баков и фиксов растет нелинейно, а риски — экспоненциально. В таких условиях необходимо структурировать процесс обеспечения качества (QA), чтобы предотвратить эффект «снежного кома», который может «завалить» тестировщиков — сначала фрустрацией от рутины, а потом недовольством заказчика.

https://habr.com/ru/companies/cinimex/articles/978492/

#jira #confluence #тестменеджемент #тестирование #qa_strategy #test_management_system #управление_качеством #визуализация #регрессионное_тестирование

Тест-менеджмент по agile: работающая документация

В крупных проектах управлять качеством вручную — весьма нетривиальная задача: объем требований и фичей, уточнений и доработок, баков и фиксов растет нелинейно, а риски — экспоненциально. В таких условиях необходимо структурировать процесс обеспечения качества (QA), чтобы предотвратить эффект «снежного кома», который может «завалить» тестировщиков — сначала фрустрацией от рутины, а потом недовольством заказчика.

https://habr.com/ru/companies/cinimex/articles/978492/

#jira #confluence #тестменеджемент #тестирование #qa_strategy #test_management_system #управление_качеством #визуализация #регрессионное_тестирование

Тестирование без тонны кейсов: свобода, автотесты и наша экспертиза

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

https://habr.com/ru/companies/k2tech/articles/971204/

#тестирование #тестрейсы #тесткейсы_для_автоматизации #автоматизация #облачные_сервисы #облачная_инфраструктура #ручное_тестирование #регрессионное_тестирование #регрессия

Теория тестирования ПО простыми словами: от основ до практики

Тестирование — это не просто поиск ошибок. Это способ убедиться, что продукт действительно работает так, как должен, и делает жизнь пользователей проще, а не сложнее. Хорошее тестирование начинается задолго до первого нажатия кнопки “Run tests” — с понимания логики продукта, требований и рисков.

https://habr.com/ru/articles/960202/

#тестирование_по #регрессионное_тестирование #санитарное_тестирование #виды_тестирования #тестплан #тесткейс #пирамида_тестирования

Теория тестирования ПО простыми словами: от основ до практики

Тестирование — это не просто поиск ошибок. Это способ убедиться, что продукт действительно работает так, как должен, и делает жизнь пользователей проще, а не сложнее. Хорошее тестирование начинается задолго до первого нажатия кнопки “Run tests” — с понимания логики продукта, требований и рисков.

https://habr.com/ru/articles/960202/

#тестирование_по #регрессионное_тестирование #санитарное_тестирование #виды_тестирования #тестплан #тесткейс #пирамида_тестирования

Теория тестирования ПО простыми словами: от основ до практики

Тестирование — это не просто поиск ошибок. Это способ убедиться, что продукт действительно работает так, как должен, и делает жизнь пользователей проще, а не сложнее. Хорошее тестирование начинается задолго до первого нажатия кнопки “Run tests” — с понимания логики продукта, требований и рисков.

https://habr.com/ru/articles/960202/

#тестирование_по #регрессионное_тестирование #санитарное_тестирование #виды_тестирования #тестплан #тесткейс #пирамида_тестирования

Теория тестирования ПО простыми словами: от основ до практики

Тестирование — это не просто поиск ошибок. Это способ убедиться, что продукт действительно работает так, как должен, и делает жизнь пользователей проще, а не сложнее. Хорошее тестирование начинается задолго до первого нажатия кнопки “Run tests” — с понимания логики продукта, требований и рисков.

https://habr.com/ru/articles/960202/

#тестирование_по #регрессионное_тестирование #санитарное_тестирование #виды_тестирования #тестплан #тесткейс #пирамида_тестирования

Регрессионное тестирование: взгляд изнутри от лидера команды

Многие разработчики и начинающие тестировщики считают регрессионное тестирование рутинной и скучной работой. Максим Атлашкин, руководитель отдела регрессионного тестирования РСХБ-Интех, готов развеять этот миф. Из интервью вы узнаете, как за 2,5 года пройти путь от джуна до лида регрессионного тестирования. Максим расскажет реальные истории о спасении релизов благодаря тестированию и поделится инсайдами о процессах тестирования в крупном банковском IT-проекте. Максим, как ты пришёл в сферу тестирования? Пришел в тестирование 20-м году из сопровождения первой линии другого банка, где во время процесса перехода на новую систему ДБО (другими словами клиент-банк) мой отдел начал изучать систему раньше пользователей и находил ошибки. Делали мы это исследовательским путем, ошибки записывали по шагам и передавали письмом (багтрекера для сопровождения не было) в отдел разработки. Мне этот процесс понравился, особенно когда была обратная связь и ошибки действительно исправляли, и нужно было сделать ретест. Тогда-то и начал интересоваться тестированием в целом, искал информацию в интернете по типу «Как тестировать», прошел несколько бесплатных курсов и решил, что нужно профессионально идти в тестирование, параллельно продолжая изучать эту сферу. Что тебя вдохновило заняться именно регрессионным тестированием? Цели идти именно в регрессионное не было. У меня не было опыта, и я не до конца понимал, как это работает на тот момент. Я оказался в РСХБ-Интех и изначально попал в команду регресса ДБО для юридических лиц. Только месяц-два изучил, как и что тут работает, как пришла пора «распиливать» монолит на микросервисы, появились продуктовые команды разработки, и колесо фортуны закинуло меня в одну из них, да еще и с очень критичным продуктом платежей и переводов. Там я на практике познакомился с большим количеством инструментов (Postman, Swagger, BrowserStack, DBeaver, Fiddler и др.). Впервые поработал в гибкой методологии agile, ранее был знаком только с waterfall-ом. Моему счастью не было предела. Шутка =)

https://habr.com/ru/companies/rshb/articles/911580/

#тестирование #регрессионное_тестирование

Тестирование без инцидентов в проде. Утопия или реальность?

Всем привет! Я старший специалист по тестированию в ITFB Group. Сегодня хочу поделиться с вами практическим опытом нашей команды — как нам удалось достичь нулевого количества инцидентов в продакшене за отчётный период. Это не теория, а реальная история из проекта крупного банка, где мы внедрили систему процессов, позволившую минимизировать риски. Если вам интересен практический подход к предотвращению сбоев, давайте разберём его вместе.

https://habr.com/ru/companies/itfb/articles/911760/

#itfb #тестирование #регрессионное_тестирование #qa #agile #инцидентменеджмент #автоматизация_тестирования #разработка_по #разработка_приложений

Реестр систем ДОМ.РФ – «единое поле координат» для управления ИТ и синхронизации с командами

Привет, Хабр! Эта статья про то, как команда корпоративной архитектуры ДОМ.РФ выстраивала управление ИТ на основе единого реестра автоматизированных систем. В ней мы поделимся опытом, как и почему и пришли к этому решению, а также расскажем про плюсы и минусы данного подхода. Предыстория Для начала объясним, что из себя представляет группа ДОМ.РФ и её ИТ-ландшафт. Группа компаний ДОМ.РФ реализует нацпроекты в области жилищного строительства с 1997 года и развивает цифровизацию российской строительной отрасли и банковской сферы. В группу входит множество направлений – от собственного банка до лифтостроительного завода. Все направления имеют ИТ-составляющую и свои оцифрованные процессы.

https://habr.com/ru/companies/domrf/articles/901434/

#тестирование #нагрузочное_тестирование #боты #тестировщик #регрессионное_тестирование #тестирование_производительности

День Сурка QA: как не застрять в цикле рутинных задач

Статья для начинающих QA посвящена распространенной проблеме рутинных задач в тестировании (дейли, отчеты, анализ требований, регресс, воспроизведение багов, подготовка данных, коммуникация). Автор с юмором описывает эти ситуации и предлагает практические решения, подкрепленные ссылками на книги по управлению проектами и тестированию. Советы включают автоматизацию, оптимизацию процессов, развитие, делегирование и поиск смысла в работе.

https://habr.com/ru/articles/900660/

#Рутина #Задачи_QA #регрессионное_тестирование #багтрекинг #коммуникация #автоматизация #автоматизация_рутины #автоматизация_тестирования

QA. Расшиваем бутылочное горлышко регресса

Всем привет! Я Лид тестирования в одной из компаний и поделюсь своей историей решения проблемы, когда регрессионное тестирование становится бутылочным горлышком всего процесса. Предыстория. В этом году направление получило взрывной рост и количество команд утроилось (стало 15 команд), а количество QA‑ специалистов стало превышать 20+ человек. Довольно быстро выявились следующие проблемы...

https://habr.com/ru/articles/871694/

#регрессионное_тестирование #qa_management #qa_lead

Точная оценка задач QA: возможно ли это?

Привет! Меня зовут Роман Фроленков, я являюсь руководителем группы тестирования QA в компании «Комус-Тех». В нашей команде более 10 внутренних QA-специалистов, а также свыше 15 специалистов из аутсорса, которые работают в составе продуктовых команд. В этой статье хочу поделиться опытом нашей команды: с какими проблемами мы столкнулись при оценке задач QA, какие подходы пробовали, и какой метод в итоге стал для нас наиболее эффективным. Сразу уточню : я не претендую на универсальность предложенного метода. Этот подход успешно работает в рамках наших процессов, но это не значит, что он подойдет всем без исключения. Методы я решил подробно не описывать, так как их описание можно легко найти в открытых источниках. В данном материале я сделал акцент на правильное сочетание, своевременность применения и нюансы использования этих подходов. Если вам интересно узнать больше о каждом из упомянутых методов, рекомендую ознакомиться с их описанием в этой статье: TestGrow Работая в QA, я часто сталкивался с проблемой: как объективно оценить трудозатраты на тестирование задач? Не раз замечал, что оценки "на глаз" оказывались неточными. Ведь если заложить слишком много рисков – в продакшен попадут не все задачи, а если их не заложить – есть и вовсе риск не успеть провести полноценный регресс или найти дефекты только за несколько часов до релиза.

https://habr.com/ru/articles/861640/

#тестирование #оценка_задач #qa #qa_процессы #регрессионное_тестирование #декомпозиция_задач #релиз #управление_процессами #qa_lead #оценка_трудозатрат

Точная оценка задач QA: возможно ли это?

Привет! Меня зовут Роман Фроленков, я являюсь руководителем группы тестирования QA в компании «Комус-Тех». В нашей команде более 10 внутренних QA-специалистов, а также свыше 15 специалистов из аутсорса, которые работают в составе продуктовых команд. В этой статье хочу поделиться опытом нашей команды: с какими проблемами мы столкнулись при оценке задач QA, какие подходы пробовали, и какой метод в итоге стал для нас наиболее эффективным. Сразу уточню : я не претендую на универсальность предложенного метода. Этот подход успешно работает в рамках наших процессов, но это не значит, что он подойдет всем без исключения. Методы я решил подробно не описывать, так как их описание можно легко найти в открытых источниках. В данном материале я сделал акцент на правильное сочетание, своевременность применения и нюансы использования этих подходов. Если вам интересно узнать больше о каждом из упомянутых методов, рекомендую ознакомиться с их описанием в этой статье: TestGrow Работая в QA, я часто сталкивался с проблемой: как объективно оценить трудозатраты на тестирование задач? Не раз замечал, что оценки "на глаз" оказывались неточными. Ведь если заложить слишком много рисков – в продакшен попадут не все задачи, а если их не заложить – есть и вовсе риск не успеть провести полноценный регресс или найти дефекты только за несколько часов до релиза.

https://habr.com/ru/articles/861640/

#тестирование #оценка_задач #qa #qa_процессы #регрессионное_тестирование #декомпозиция_задач #релиз #управление_процессами #qa_lead #оценка_трудозатрат

Точная оценка задач QA: возможно ли это?

Привет! Меня зовут Роман Фроленков, я являюсь руководителем группы тестирования QA в компании «Комус-Тех». В нашей команде более 10 внутренних QA-специалистов, а также свыше 15 специалистов из аутсорса, которые работают в составе продуктовых команд. В этой статье хочу поделиться опытом нашей команды: с какими проблемами мы столкнулись при оценке задач QA, какие подходы пробовали, и какой метод в итоге стал для нас наиболее эффективным. Сразу уточню : я не претендую на универсальность предложенного метода. Этот подход успешно работает в рамках наших процессов, но это не значит, что он подойдет всем без исключения. Методы я решил подробно не описывать, так как их описание можно легко найти в открытых источниках. В данном материале я сделал акцент на правильное сочетание, своевременность применения и нюансы использования этих подходов. Если вам интересно узнать больше о каждом из упомянутых методов, рекомендую ознакомиться с их описанием в этой статье: TestGrow Работая в QA, я часто сталкивался с проблемой: как объективно оценить трудозатраты на тестирование задач? Не раз замечал, что оценки "на глаз" оказывались неточными. Ведь если заложить слишком много рисков – в продакшен попадут не все задачи, а если их не заложить – есть и вовсе риск не успеть провести полноценный регресс или найти дефекты только за несколько часов до релиза.

https://habr.com/ru/articles/861640/

#тестирование #оценка_задач #qa #qa_процессы #регрессионное_тестирование #декомпозиция_задач #релиз #управление_процессами #qa_lead #оценка_трудозатрат

Точная оценка задач QA: возможно ли это?

Привет! Меня зовут Роман Фроленков, я являюсь руководителем группы тестирования QA в компании «Комус-Тех». В нашей команде более 10 внутренних QA-специалистов, а также свыше 15 специалистов из аутсорса, которые работают в составе продуктовых команд. В этой статье хочу поделиться опытом нашей команды: с какими проблемами мы столкнулись при оценке задач QA, какие подходы пробовали, и какой метод в итоге стал для нас наиболее эффективным. Сразу уточню : я не претендую на универсальность предложенного метода. Этот подход успешно работает в рамках наших процессов, но это не значит, что он подойдет всем без исключения. Методы я решил подробно не описывать, так как их описание можно легко найти в открытых источниках. В данном материале я сделал акцент на правильное сочетание, своевременность применения и нюансы использования этих подходов. Если вам интересно узнать больше о каждом из упомянутых методов, рекомендую ознакомиться с их описанием в этой статье: TestGrow Работая в QA, я часто сталкивался с проблемой: как объективно оценить трудозатраты на тестирование задач? Не раз замечал, что оценки "на глаз" оказывались неточными. Ведь если заложить слишком много рисков – в продакшен попадут не все задачи, а если их не заложить – есть и вовсе риск не успеть провести полноценный регресс или найти дефекты только за несколько часов до релиза.

https://habr.com/ru/articles/861640/

#тестирование #оценка_задач #qa #qa_процессы #регрессионное_тестирование #декомпозиция_задач #релиз #управление_процессами #qa_lead #оценка_трудозатрат

Подходы к сокращению регрессионного тестирования

Привет, Хабр! Меня зовут Ксения Сергеева, я QA-инженер в компании SM Lab, IT-подразделении Спортмастера. Сейчас работаю с мобильным приложением для продавцов, а за последние несколько лет успела потрудиться на благо финтеха и сервисов топливной компании. И, конечно, на каждом из проектов я сталкивалась с проведением регрессионного тестирования. Что самое креативное в работе QA-инженера? Тестировать новую функциональность. Что самое скучное в работе QA-инженера? Гонять регресс. Здесь со мной могут не согласиться нелюбители писать документацию, но и в таком случае прохождение регресса занимает почетное второе место в списке самых занудных активностей QA. Регрессионное тестирование (от латинского regressio — движение назад) — это совокупность проверок ранее протестированной программы с целью убедиться в том, что внесенные в программу изменения и доработки не привели к появлению дефектов и несоответствий во всех остальных частях программы. А еще регрессу как правило сопутствует куча ограничений. Сдвинулись сроки передачи фичи в тест? Время на регресс уменьшилось. Близится конец периода, а мы не все успеваем? Режем регресс. Коллега ушел на больничный и рук не хватает? Ну, вы понимаете. Плюс, регресс — штука дорогая, ведь в это время команда (особенно QA) не занимается созданием новой ценности для заказчика и пользователя, а перелопачивает старую.

https://habr.com/ru/companies/sportmaster_lab/articles/852200/

#тестирование #qa #тестирование_itсистем #регрессионное_тестирование

Один в поле воин или не воин? Когда ты один тестировщик на 9 разработчиков. Часть 1

У нас было два пакетика травы… 1 product owner, 9 разработчиков, 5 аналитиков и только один тестировщик. Рассказываю о своём опыте тестирования как единственного тестировщика на проекте. И удалось ли мне справится с такой нагрузкой работ.

https://habr.com/ru/articles/841566/

#опыт_работы #тестирование_вебприложений #тестирование_мобильных_приложений #регрессионное_тестирование #тестировщикикотики #тестировщик

Еще раз о регрессе: почему тестирование до сих пор вызывает вопросы?

Писать о регрессе в 2024 году — казалось бы, странная идея: каждый, кто хоть как-то связан с IT-миром, знает, что такое регрессионное тестирование и зачем оно нужно. В каждом курсе, в каждой статье для новичка о нем рассказывается. Вроде бы можно закрыть тему… Но почти каждый раз, когда на собеседовании я задаю вопрос: «Как мне выбрать тесты для регресса?», четкого ответа я не получаю. Это не зависит от уровня тестировщика, его опыта и направления. Из интереса я пристала к разработчикам, аналитикам, менеджерам и архитекторам с этим же вопросом, но получила лишь размытые формулировки и жалобы на то, что мы слишком долго проводим регресс и давно пора все автоматизировать. Такое происходит, потому что с виду простой вопрос содержит множество уровней, о которых обычно нет времени задуматься. Меня зовут Алена Вахтина и я ведущий специалист по тестированию в Лиге Цифровой Экономики. В этой статье постараюсь хотя бы частично рассмотреть такие подводные камни регрессионного тестирования.

https://habr.com/ru/companies/digitalleague/articles/815615/

#тестирование #регрессионное_тестирование #аналитика #регрессионный_анализ #автоматизация_тестирования #регресс

Как защитить PROD от багов и себя от стресса

Сегодня хочу поговорить про баги на ПРОДе и о том как защитить команду от этого, ведь для реализации необходима помощь всей команды в выстраивании процессов разработки ПО. Прекрасное название этой статьи говорит само за себя - если не получается защитить команду от багов, то точно получиться защитить себя от стресса, ведь не все зависит от QA. Важно подсветить, что под багом подразумевается отличие ожидаемого результата от фактического. Мы ожидали, что при нажатии кнопки А будет окно В, но происходит совершенно другое. На схеме выше отображаются риски не только появления бага, но и не предусмотренных ошибок в виде программа не делает лучше, а только затрудняет использование. Первый риск: Идея попадает к аналитику Владелец продукта и аналитик на этапе проектирования тех. требований могут некорректно описать логику нового функционала (флоу). Заказчик имел ввиду одно, а по итогу в спецификациях совершенно другое. Решение данной проблемы может зависеть от правил взаимодействия с заказчиком в вашей команде. Второй риск: разработка по тех. требованиям Frontend и Backend разработчики берут задачи из бэклога в спринт, но в задаче может быть прикреплена устаревшая документация, ее может и вовсе не быть.

https://habr.com/ru/articles/804171/

#баги #тестирование #qa #qa_testing #разработка #testing #регрессионное_тестирование #приемочное_тестирование #процессы_разработки #команда_разработки