Библиотека

Тестируем производительность фронтенда через вкладку Performance в DevTools

barancev@gmail.com (Administrator) — Sun, 14 Dec 2025 20:00:00 +0000

Автор: Ященко Святослав

Продолжаем разбирать малоизвестные, но крайне полезные фичи Chrome DevTools. Меня зовут Святослав Ященко, я тимлид QA-команды Platform V Kintsugi. Это графическая консоль для сопровождения PostgreSQL и Postgres-like СУБД. Ранее я писал о том, как подменить трафик в DevTools. Сегодня покажу, как тестировать производительность web-приложения, не выходя из Chrome.

Наш продукт — высоконагруженный, как в части бэкенда, так и в части фронтенда. БольшУю нагрузку на web-часть дают графики метрик наблюдаемых баз данных. Нагрузочное тестирование бэкенда в нашей команде — тема отдельной статьи, но об этом постараюсь рассказать в другой раз, а сейчас протестируем производительность фронтенда.

ПОТРАЧЕНО–2. Как тестировать локализацию переводов, чтобы потом не было стыдно

barancev@gmail.com (Administrator) — Sun, 07 Dec 2025 20:00:00 +0000

Автор: Михаил Кургузов

В первой статье цикла мы обсудили вводную про локализацию и её особенности. Пришло время поговорить про конкретные проблемы, с которыми можно столкнуться в процессе локализации. А ещё расскажу, как и кем выполнять тестирование.

Возможные проблемы

Плохое знание продукта и некорректное тестирование
Тут многое зависит от того, кто именно будет проводить тестирование локализации. Представьте пример — у вас есть баг, при котором текст не появляется в нужном окошке. Но исполнитель не очень знаком с продуктом и вообще не знает, что в этом окошке должен быть текст.
Отсутствие консистентности на разных версиях оборудования

Что должен знать и уметь Разработчик Автоматического Тестирования, чтобы называться Инженером

barancev@gmail.com (Administrator) — Tue, 28 Oct 2025 20:00:00 +0000

Автор: Daniel Haimov

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

В области автоматического тестирования я работаю уже 15 лет. За это время я работал как в крупных компаниях, так и в небольших стартапах. Использовал различные языки программирования и технологии. Был частью разных команд — от специализированных групп разработчиков автоматического тестирования до смешанных команд, где вместе работали и разработчики, и тестировщики. За время карьеры занимал различные позиции и дорос до Senior Automation Engineer.

Как мы научились эффективно работать с техническим долгом

barancev@gmail.com (Administrator) — Tue, 14 Oct 2025 20:00:00 +0000

Оригинальная публикация

Меня зовут Эдвард. В сфере обеспечения качества я с 2012 года. Последние 7 лет работаю в Т-Банке, начинал со старшего специалиста по тестированию бэкэнда и работал в Т-Инвестициях. А сейчас занимаю позицию QA Head управления разработки социальных платформ.

Расскажу о том, как мы формировали подход по работе с техническим долгом, зачатки которого в нашей компании стали появляться еще в 2022. Также, покажу примеры визуализации метрик по техническому долгу в разрезе причин его возникновения и оставлю рекомендации по устранению каждой из причин формирования технического долга.

QA за пределами тестирования: надежность через учебные сбои

barancev@gmail.com (Administrator) — Wed, 17 Sep 2025 20:00:00 +0000

Оригинальная публикация

Привет! Я Леша Севальников, старший QA-инженер в команде, которая занимается разработкой бэкенд-сервисов для хранения, предоставления и актуализации данных о юридических лицах.

Почти пять лет работаю в Т-Банке, где с нуля организовал тестирование в своей команде. За это время я успел пройти путь от ручного до автоматизированного тестирования, встроить и автоматизировать нагрузочное тестирование и многое другое.

В какой-то момент все эти активности стали работать как единый механизм в текущих процессах, и мы задумались над следующим шагом для развития зрелости команды — повышение надежности. Расскажу о практике, которая поможет повысить надежность систем и команд.

Изучай и властвуй: как с помощью одного UX-исследователя, этнографии и тестов мы разработали систему управления складами

barancev@gmail.com (Administrator) — Sun, 10 Aug 2025 20:00:00 +0000

Оригинальная публикация

Меня зовут Саша – я ведущий исследователь пользовательского опыта в операционных продуктах ecom.tech, @ecom_tech_channel). На наших технологиях работают Самокат и Мегамаркет. В этой статье расскажу, как я оказалась на огромных складах и как мои исследования помогли разработать собственную систему управления складами. Внутри вас ждёт этнография, много тестирования и живые фото. Поехали!

Как видеть всё: внедряем простой мониторинг производительности в командах (на примере QA)

barancev@gmail.com (Administrator) — Mon, 02 Jun 2025 20:00:00 +0000

Анализ показателей по ключевым метрикам — то, что помогает командам принимать верные решения. Оперативно выявлять узкие места в процессах, оценивать их эффективность на разных этапах релизного цикла, равномерно распределять нагрузку между сотрудниками.

Только как быть, если в вашей команде уже не 5 человек, а 15, и вручную отслеживать данные стало непросто?

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

Под катом рассказываем, как мы начали (и продолжаем) централизованно мониторить эффективность нашего QA-направления. Поэтапно и с практическими советами.

Привет, меня зовут Василий, я Deputy CTO в Сравни. Уже пару лет мы централизованно мониторим производительность в командах, чтобы видеть реальную рабочую нагрузку, выявлять сложности в процессах и влиять на персональное развитие сотрудников. Речь, по сути, о визуализации данных из корпоративного таск-трекера — по настраиваемым полям получаем на дашбордах данные в нужном нам разрезе, на их основе делаем выводы.

Как писать баг-репорты, которые помогут всей команде

barancev@gmail.com (Administrator) — Tue, 27 May 2025 20:00:00 +0000

Автор: Михаил, специалист по тестированию в компании ITFB Group

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

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

Локализация дефектов как прохождение лабиринта

barancev@gmail.com (Administrator) — Wed, 08 Jan 2025 20:00:00 +0000

Автор: Ekaterina Noga, оригинальная публикация

Одной из основных частей работы QA является локализация дефектов.

Техники тест дизайна помогают нам выбрать сценарии тестирования делая его эффективнее. Но что такое локализация дефекта и что может с этим помочь?

Начнем с начала.

Локализация это поиск ответа на вопрос «в какой момент и где что‑то пошло не так?». Без правильной локализации дефект может передаваться как между фронтендом и бэкендом, так и между командами разработки. При этом теряется время на исправление и, возможно, контекст.

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

Как написать требования к IT-продукту и их протестировать, чтобы результат соответствовал ожиданиям

barancev@gmail.com (Administrator) — Sun, 12 May 2024 20:00:00 +0000

Автор: Зубов Вадим QA специалист IT компании Intelsy

С техническим заданием, и в частности с требованиями, лично я имею дело постоянно, поэтому собрал полезную для начинающих и продолжающих специалистов информацию по требованиям к IT-продукту, их видам, техникам и метрикам тестирования требований. На эту инфу стоит ориентироваться не только аналитикам и тестировщикам, но и остальным членам команды.

Логи, мониторинг и предупреждения

barancev@gmail.com (Administrator) — Thu, 24 Oct 2019 20:00:00 +0000

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

На этой неделе я расскажу о трех вещах, которые нечасто ассоциируются с тестированием: это логирование, мониторинг и предупреждения. Возможно, вы пользуетесь логами, тестируя, однако мониторинг и предупреждения – проблемная область в IT и DevOps. Но ведь приложение без багов не стоит ничего, если ваши пользователи не могут до него добраться, потому что сервер упал! Поэтому очень важно разбираться в логировании, мониторинге и предупреждениях, чтобы мы, как тестировщики, могли участвовать в обеспечении качества наших приложений.

Программная инженерия и управление жизненным циклом

barancev@gmail.com (Administrator) — Sat, 11 Oct 2008 07:11:12 +0000

Главы из книги Сергея Орлика и Юрия Булуя «Введение в программную инженерию и управление жизненным циклом» (базируется на SWEBOK).

От автора: о чем эта книга

В течение десяти лет работы в Borland мне постоянно приходится обсуждать с менеджерами, аналитиками, архитекторами и разработчиками вопросы применимости тех или иных продуктов, технологий, проектных решений. Последнее время, все чаще темой дискуссий становится процесс разработки программного обеспечения, как таковой, вопросы организации проектных команд, адаптации стандартов и подходов в управлении жизненным циклом ПО к сложившейся культуре разработки, и наоборот, трансформации существующей культуры и ценностей в новое качество. Приходится вспоминать и кое-что из опыта «прошлой жизни», когда я сам выступал в роли корпоративного разработчика и лидера проектной команды. Приходиться применять и уже более «свежий» опыт разработки рекомендаций по процессу разработки и внедрению технологий управления и поддержки жизненного цикла разработки приложений. И самому приходиться постоянно совершенствоваться, в том числе помогая другим.

Для кого эта книга

Для всех, кто связан с индустрией информационных технологий. Только не подумайте, что речь идет только о разработчиках и менеджерах проектов в области программного обеспечения. Конечно, нет. Ведь если в вашей деятельности программные системы играют серьезную роль в качестве повседневного и необходимого инструмента обеспечения вашей профессиональной деятельности, вы, наверняка, сталкиваетесь с вопросами взаимодействия с ИТ-специалистами. Вам, как пользователям и заказчикам просто необходимо иногда вникать в проблематику разработки программного обеспечения, если, конечно, вы хотите получить результат. Вы, кто создает (в общем смысле этого понятия, ни в коем случае не ограничиваясь только вопросами кодирования), поддерживает и развивает программное обеспечение, наверняка, найдете нечто новое в этой книге. Вы школьник или студент — вы учитесь. Не останавливайтесь. Эта книга и для вас. Хотя бы потому что это еще одна точка зрения. А две головы, иногда, лучше, чем одна. Так что, книга, как это принято иногда говорить — «для широкого круга читателей», для кого использование компьютера в повседневной работе не является абстракций, но полнофункциональным инструментом.

ПОТРАЧЕНО. Как тестировать локализацию переводов, чтобы потом не было стыдно

barancev@gmail.com (Administrator) — Tue, 25 Nov 2025 20:00:00 +0000

Привет! Меня зовут Михаил Кургузов, я из отдела локализации и переводов SM Lab. В этом цикле постов я расскажу о локализации и ее интеграции в процесс тестирования ПО.

Пост #1 (вы находитесь здесь) — общая вводная про локализация и интернационализацию, важные примеры, лингвистические ошибки и функциональные баги, особенности разных языков.
Пост #2 — особенности тестирования локализации, кто чем занимается, как проходит процесс.
Пост #3 — чеклист, лучшие практики, дополнительные материалы и много полезных примеров.

Начать хочу с пары историй. Например, всем известная Windows Vista очень сильно пострадала при выходе на японский рынок от некорректно выполненной локализации, потому что были не только некорректно переведены многие термины, но доходило до того, что, скажем так, текст всплывающих подсказок относился не к тем элементам, к которым должен был.

Управление временем контейнера с помощью docker-compose и faketime

barancev@gmail.com (Administrator) — Sun, 23 Nov 2025 20:00:00 +0000

Оригинальная публикация
Автор: Сергей Терентьев

Зачем нам управлять временем?

В начале немного о себе, мое основное занятие — обеспечение качества на вверенных проектах, я Senior QA в компании Umbrella IT. Периодически при тестировании микросервисов приходится сталкиваться с необходимостью изменения времени для проверки работы того или иного функционала. Это может быть функционал, который срабатывает по «тику» cron, или связанный с применением системного времени как одного из условий обработки/хранения/передачи данных тестируемым микросервисом.

Если микросервис разворачивается в Docker, то время контейнера берется из системного времени хост машины и без дополнительных инструментов максимум, что мы можем поменять — это часовой пояс контейнера, но не само системное время. Проблема в том, что часто для целей тестирования просто изменения часового пояса, ровно как и изменения времени в пределах 24х часов, оказывается недостаточно. Что делать если нам нужно протестировать работу микросервиса в граничных значениях даты‑времени, например начало и конец месяца/года, или использовать замечательные даты, такие как 29 февраля, последние даты месяцев со сменой количества дней, и так далее?

Тестирование безопасности API – Неограниченное потребление ресурсов

barancev@gmail.com (Administrator) — Tue, 11 Nov 2025 20:00:00 +0000

Автор: Баз Дейкстра (Bas Dijkstra)
Оригинал статьи
Перевод: Ольга Алифанова

В этой серии статей я обращусь к уязвимостям из списка топ-10 OWASP, посвященного безопасности API. В каждой статье я покажу вам, как экспериментировать с API, тестируя уязвимость, и обсужу свои выводы.

В качестве подопытных я буду использовать разные API. Все они демонстрационные – в реальной жизни и публичных приложениях они не используются. Следовательно, все обсуждаемые уязвимости абсолютно безвредны, если вообще не внедрены специально.

Как мы систематизировали работу с техдолгом в своей QA-команде

barancev@gmail.com (Administrator) — Sun, 26 Oct 2025 20:00:00 +0000

Оригинальная публикация

Меня зовут Илья, работаю инженером по обеспечению качества в Т-Банке. Пишу автотесты на Kotlin, занимаюсь ручным тестированием и стараюсь улучшать процессы в команде.

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

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

Тестирование Push-уведомлений: Полный чек-лист (ну или почти)

barancev@gmail.com (Administrator) — Mon, 20 Oct 2025 20:00:00 +0000

Автор: Павлович Евгений

Введение

Push-уведомления — это инструмент для взаимодействия с пользователями мобильных приложений. Они позволяют доставлять сообщения, напоминания или акции даже тогда, когда приложение не активно. Их работа зависит от множества факторов: операционной системы, настроек устройства, состояния приложения и сетевого подключения.

Этот чек-лист я написал для себя, чтобы протестировать на проекте push-уведомления для iOS и Android, и возможно он может быть будет полезен другим тестировщикам, что бы упростить немного работу, а также уточнить или добавить этот чек-лист в комментах.

Нефункциональные проверки мобильных приложений

barancev@gmail.com (Administrator) — Sun, 17 Aug 2025 20:00:00 +0000

Меня зовут Алексей, я работаю тестировщиком в компании «Совкомбанк Технологии». Хочу поговорить о нефункциональном тестировании мобильных приложений на платформах Android и iOS.

Нефункциональные проверки играют ключевую роль в обеспечении качества, удобства использования и стабильности продукта. В сети можно найти множество чек-листов и статей на эту тему, но зачастую проверки, описанные в них, либо избыточны, либо устарели. Более того, редко где объясняется, зачем проводить те или иные тесты и какие процессы происходят «под капотом» приложения.

В этой статье я не только разберу основные нефункциональные проверки, но и расскажу, что происходит с приложением в моменты, когда, например, вы сворачиваете его или выключаете экран – не взаимодействуете с телефоном. Часть тестов применима к обеим платформам, а некоторые актуальны только для Android или iOS. Примеры всех багов взяты из личного опыта тестирования.

Падаем с изяществом: руководство по культуре ошибок для тестировщика

barancev@gmail.com (Administrator) — Sun, 03 Aug 2025 20:00:00 +0000

Автор: Штефан Дирнштофер (Stefan Dirnstorfer)
Оригинал статьи
Перевод: Ольга Алифанова

Зачем тратить время на продумывание сообщений об ошибках?

Перед моей последней поездкой я попытался зарегистрироваться онлайн. Пользовательский путь, который проходил через утомительную серию полей формы, внезапно завершился кратким сообщением об ошибке: HTTP_400_BAD_REQUEST.

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

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

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

От релиз-менеджера до разработчика: почему я ушел из QA и не жалею

barancev@gmail.com (Administrator) — Tue, 08 Jul 2025 20:00:00 +0000

Автор: Николай Алешин (Nikolay Aleshin)

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

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

Даже при наличии опыта, глубокого понимания процессов и бизнес-контекста, квалифицированные QA-инженеры уже не так востребованы, как раньше. Компании по-прежнему нанимают людей на эту должность, но не понимают, зачем она им нужна. Роль QA размыта до предела — теперь это что-то между тестировщиком, аналитиком, DevOps-инженером и ещё бог знает кем.

Последний год поиска работы стал для меня настоящим шоком. Я увидел, как QA-индустрия мутировала в нечто неопределённое: требования нереалистичны, зарплаты мизерные, а доверие к профессии почти исчезло. Это заставило меня переосмыслить свой путь и сделать трудное, но необходимое решение — уйти из QA.

Предъявите мне вашу карту! Или как составить ИПР с помощью карты компетенций

barancev@gmail.com (Administrator) — Mon, 19 May 2025 20:00:00 +0000

Оригинальная публикация

Всем привет! Меня зовут Ксения Лопатина. В предыдущей статье я рассказывала вам о своем подходе к построению карты компетенций для команды тестирования. Там я описала зачем нужна карта компетенций, как можно подойти к ее построению и как провести оценку.

Сегодня я хочу рассказать о том, что же делать дальше, после того, как вы провели оценку. Вы узнаете, что такое ИПРы и как создавать их на базе карты компетенции, как правильно ставить задачи и нужно ли контролировать их исполнение. Также покажу вам наиболее оптимальный формат, который я выработала путем проб и ошибок. Статья будет полезна и тем, кто уже выбрал подход работы с ИПР и тем, кто только в начале данного пути. Также будет полезно если вы составляете ИПР себе самостоятельно или делаете их для ваших сотрудников.

Что тестировщикам (и не только им) важно знать о базах данных. Шпаргалка по популярным ошибкам

barancev@gmail.com (Administrator) — Mon, 13 Jan 2025 20:00:00 +0000

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

Разумеется, БД — вовсе не черный ящик с магией внутри, а такой же набор взаимодействующих по определенным правилам компонентов, как и все остальное, с чем ежедневно приходится иметь дело QA-инженерам (и разработчикам, на самом деле, тоже, но они обычно больше погружены в контекст). Понимание того, что там под капотом, помогает эффективно проводить тест-дизайн, локализовывать баги, общаться с разработкой.

Под катом — наша шпаргалка по распространённым багам в работе баз данных. Разбили их по категориями, снабдили примерами и объяснили первопричины появления. Надеемся, будет полезно не только QA-специалистам, но и бэкенд-разработчикам начального уровня, а также всем, кто хочет углубить свои познания в области взаимодействия с БД.

Документирование вашей тест-автоматизации

barancev@gmail.com (Administrator) — Tue, 28 May 2024 20:00:00 +0000

Автор: Баз Дейкстра (Bas Dijkstra)
Оригинал статьи
Перевод: Ольга Алифанова

В этой статье я хочу ответить на вопрос, заданный мне в LinkedIn Полом Сименом (Paul Seaman). Он спросил, что я думаю о документировании автоматизированных тест-кейсов как способе продемонстрировать, что автоматизация вообще делает.

Краткий ответ: я не определился.

Это, конечно, не очень-то полезный ответ, да и статья вышла бы странно короткой – постараюсь развить свою мысль.

Как эффективно протестировать чатбот

barancev@gmail.com (Administrator) — Tue, 16 Jan 2024 20:00:00 +0000

Автор: Сумиа Мухерджи (Soumya Mukherjee)
Оригинал статьи: Tea-Time With Testers, #02/2021
Перевод: Ольга Алифанова

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

НАШ ОПЫТ ИНТЕГРАЦИИ CYPRESS И EVERYQA.IO

barancev@gmail.com (Administrator) — Mon, 16 Nov 2020 20:00:00 +0000

Автор: Новиков Александр, QA engineer at Roowix

Добрый день! Меня зовут Александр, я - QA в компании Roowix.

Мой профиль - автоматизация тестирования, и сегодня я расскажу, как мы разворачивали screenshot-based тестирование на биржевом проекте при помощи Everyqa.io и Cypress.

Специфика проекта заключается в отображении состояния котировок на графике в canvas с большим количеством фильтров и настроек. Использовать стандартные средства для тестирования проекта на canvas было неудобно. Исходя из этого мы начали поиск подходящего инструмента и стратегии написания автотестов.