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

Тестирование LLM‑фичи: можно ли верить своему eval

Eval показывает 96% качества, тесты проходят, а после релиза LLM‑ассистент допускает критическую ошибку. Проблема может скрываться в самой системе оценки, которая пропускает опасные ответы и создаёт ложное ощущение надёжности. Разбираем семь ошибок тестирования LLM‑функций и способы построить eval, результатам которого действительно можно доверять. Проверить свой eval

https://habr.com/ru/companies/otus/articles/1088876/

#автоматизация_тестирования #регрессионное_тестирование #метрики_качества #тестирование_ии #валидация_моделей #llmasajudge #оценка_качества_llm #тестирование_llm #evalнаборы #достоверность_метрик

Регрессионное тестирование промптов: ИИ-модель в роли читателя пропустила три из четырёх текстов, которые я правил

Я правлю промпты агентов, которые пишут и проверяют тексты. Чтобы правка не сломала то, что раньше работало, я собрал набор примеров с известным ответом и прогнал по нему проверку, где ИИ-модель играет читателя. Сильно правленые тексты она чаще пропускала, чем возвращала. В набор вошли тексты двух видов: одни я потом сильно переписывал руками, другие почти не тронул. Если принять правку промпта по такой проверке, брак уйдёт дальше, а проверка будет гореть зелёным.

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

#python #регрессионное_тестирование #оценка_моделей #llm #промпты #ииагенты #llmasajudge #тестирование_llm #тестирование_ииагентов #тестирование_промптов

Переезд с Leaflet на MapLibre: детектив про один рывок и 251 маршрут, проверенный байт в байт

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

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

#рефакторинг #миграция #webgl #leaflet #регрессионное_тестирование #maplibre

Чему нас научил взаимный перенос тестов между Pii-Mask и его форком

Автор форка Pii-Mask добавил исправления и тесты обработки Word и Excel. На нашей версии 13 его тестов не прошли. Покажу один найденный пропуск и расскажу, как взаимный перенос тестов помог подготовить план исправлений и сохранить улучшения обеих веток.

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

#тестирование #open_source #персональные_данные #регрессионное_тестирование #piimask

Как разработать шаблон дашборда для разных подразделений

В одном из BI-проектов мы собирали управленческую аналитику для крупной образовательной организации. В одном контуре должны были работать данные о контингенте, успеваемости, задолженностях, финансах, нагрузке и других направлениях. Пользователи при этом были совсем разными: руководство смотрело на организацию целиком, учебные подразделения работали со своими процессами, кафедрам была нужна более глубокая детализация, финансовым специалистам - собственные показатели и периоды, а аналитикам - возможность проверить итог до исходных записей. Технически всё это можно было оформить десятками отдельных дашбордов. Взять первый отчёт, скопировать его, заменить заголовок, добавить несколько фильтров и повторить для следующего подразделения. На старте такой путь кажется самым быстрым. Макет уже есть, визуализации работают, пользователю можно довольно скоро показать знакомую картинку. Проблема начинается чуть позже. В одном отчёте меняется формула, а в остальных остаётся старая. Где-то появляется новый фильтр, где-то забывают обновить справочник. Один дашборд показывает данные на текущую дату, другой - на конец закрытого периода. Затем меняется структура организации, часть пользователей получает новые роли, и команда уже не понимает, сколько у неё версий одного и того же отчёта. Противоположный вариант тоже выглядит логично: сделать один универсальный дашборд, который умеет показывать всё всем. Обычно он быстро обрастает десятками вкладок, фильтрами на половину экрана и показателями, большая часть которых конкретному пользователю не нужна. Формально отчёт единый. Фактически каждый человек открывает его и заново ищет свой рабочий сценарий.

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

#BI #шаблон_дашборда #семантическая_модель #RLS #OLS #дизайнсистема #аналитическая_платформа #управление_данными #регрессионное_тестирование #масштабирование_BI

Quality Intelligence: что QA знает о вашем продукте, но не показывает на дашборде

У компании могут быть десятки QA-метрик и при этом не быть ответа на вопрос: почему продукт становится все дороже и сложнее менять? Команда знает, сколько дефектов нашла за спринт, сколько ошибок дошло до продакшена, сколько времени занимает регрессия, какой процент сценариев автоматизирован. После каждого релиза появляются новые цифры, графики и отчеты. А теперь представим продукт, который выпускает релизы раз в две недели. Серьезных дефектов больше не становится, автоматизация развивается, команда укладывается в релизный цикл. На первый взгляд все в порядке. Но за последний год регрессия заметно выросла. Изменение одного сервиса все чаще требует проверки нескольких соседних. Одни и те же компоненты регулярно всплывают в инцидентах и срочных исправлениях после релиза. Для QA это дополнительные проверки и знакомые проблемные модули. Для CTO — возможный сигнал, что растет стоимость изменений. Через несколько кварталов эта история может проявиться уже в сроках разработки. Новые функции станут выходить дольше, оценки начнут расти, а для сохранения прежней скорости понадобится больше людей. Первые признаки проблемы при этом уже были в данных QA. Примерно вокруг этой идеи и строится Quality Intelligence . Что вообще такое Quality Intelligence За термином Quality Intelligence скрывается практичная идея: данные о качестве могут рассказать о продукте гораздо больше, чем просто показать, насколько хорошо он протестирован перед очередным релизом. История тестирования, дефекты, изменения компонентов, продакшн-инциденты, обращения пользователей, продуктовые показатели — все это следы того, как система развивается и как она реагирует на изменения. Если смотреть на них вместе и в динамике, можно заметить проблемы задолго до того, как они станут очевидны на уровне сроков, бюджетов или пользовательских жалоб.

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

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

Универсальный подход к регрессионному тестированию микросервисов: интеграция Postman, Newman и Python в Jenkins

Привет всем заглянувшим! В этой статье я поделюсь опытом автоматизации API‑тестирования связкой Postman + Newman, но с небольшим «секретным ингредиентом». Мы не просто будем запускать коллекции в Jenkins напрямую, а используем универсальный Python‑скрипт, который превращает стандартный прогон в мощный инструмент мониторинга. В чем «фишка» этого подхода? Обычно Newman выдает довольно сухие отчеты. Мой скрипт выступает в роли умной прослойки: он обрабатывает результаты тестов на статус‑коды, собирает данные и упаковывает их в наглядный Allure‑отчет. Более того, здесь добавлена функция почтовых уведомлений, чтобы контролировать состояние системы, не заходя в Jenkins.

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

#postman #newman #jenkins #python #автоматизация_тестирования #api_тестирование #регрессионное_тестирование #jenkins_ci #allure_jenkins_plugin #allure_report

Ошибка в расчёте скидки, которую не видно глазами: проверяем ответ API по документации, когда автотестов нет

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

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

#тестирование_api #проверка_ответов #json #валидация_данных #ручное_тестирование #тесткейсы #логи #elasticsearch #бизнеслогика #регрессионное_тестирование

Как мы построили систему регрессионного UI-тестирования для iOS-приложения: XCUITest, mock backend и XcodeBuildMCP

По мере роста UI-регрессии сложнее всего становится управлять не тестами, а их окружением: состоянием приложения, ответами backend и воспроизводимостью сценариев. В статье разбираю архитектуру, которая связывает тест-кейсы QA, mock-профили, XCUITest и XcodeBuildMCP в единый процесс — от подготовки сценария до запуска в CI.

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

#iOS #Swift #XCUITest #UIтестирование #регрессионное_тестирование #автоматизация_тестирования #mock_backend #XcodeBuildMCP #ИИагенты #iOS_Simulator

[Перевод] Мы дали ИИ написать код и тесты: что обнаружило мутационное тестирование

AI-агент самостоятельно создавал приложение и по ходу работы покрывал его тестами, а качество кода оценивали автоматические проверки. На первый взгляд всё выглядело надёжно: покрытие росло, тесты проходили. Однако мутационное тестирование показало, что часть тестов лишь выполняет код, почти не защищая его от реальных поломок. В статье разберём, какие сенсоры действительно помогают находить регрессии, а какие создают ложное чувство уверенности.

https://habr.com/ru/companies/otus/articles/1048504/

#мутационное_тестирование #ИИагенты #генерация_тестов #качество_кода #сопровождаемость #статический_анализ #ESLint #Stryker #регрессионное_тестирование #архитектура_кода

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

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

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 #производительность

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

Привет, меня зовут Смирнов Владимир, и я отвечаю за тестирование торгового бэкенда в 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 #баги

От макета до пострелиза: путь новых сервисов глазами 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 #управление_качеством #визуализация #регрессионное_тестирование

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

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

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

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

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

Тестирование — это не просто поиск ошибок. Это способ убедиться, что продукт действительно работает так, как должен, и делает жизнь пользователей проще, а не сложнее. Хорошее тестирование начинается задолго до первого нажатия кнопки “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-инженер в компании 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 #регрессионное_тестирование #приемочное_тестирование #процессы_разработки #команда_разработки