После ухода с российского рынка популярных систем вроде TestRail, Qase и Zephyr у команд появился запрос на отечественные TMS с удобным интерфейсом, различными интеграциями и встроенной аналитикой.
В статье разберём топ-3 отечественных TMS: сильные стороны, функциональность для ручных и автоматизированных тестов, интеграции, аналитику, AI и стоимость.
Привет! Меня зовут Андрей Максимкин. Я iOS-разработчик в hh.ru. В своих статьях (тут, тут и не только) мы уже не раз говорили о большой любви к тестам и их важной роли в нашем процессе разработки. В этой статье хочу поделиться опытом использования snapshot-тестов, начиная с этапа внедрения. Статья будет полезна для QA и iOS-разработчиков разных уровней. Обсудим не только теорию, но и напишем реальный snapshot-тест — как в нашей практике.
Вместо вступления
Сначала расскажем про snapshot-тесты и для чего они нужны. Snapshot тесты — это метод тестирования, который используется для защиты внешнего вида компонентов и интерфейсов от незапланированных изменений. Они позволяют зафиксировать эталонное состояние компонента и в дальнейшем использовать как образец. Это помогает выявлять изменения в пользовательском интерфейсе, которые могут возникнуть в результате обновлений кода.
В hh.ru мы активно разрабатываем нашу собственную дизайн-систему (ДС). Дело в том, что компоненты ДС могут иметь широкий набор свойств: цвета, размеры, скругления. Проверять корректность, например, цветов обычным ручным тестировщикам на длинной дистанции невозможно, поэтому возникла потребность автоматизировать проверки. Кроме того, при рефакторинге кода некоторые компоненты могут сломаться — хотелось бы находить такие проблемы сразу. Snapshot-тесты показались лучшим решением этих проблем.
Когда-то давно в hh.ru уже были snapshot-тесты. На тот момент они были написаны на экраны приложения. Эти экраны часто меняли свой дизайн, тесты вели себя нестабильно и падали, поэтому их приходилось переписывать. В итоге от snapshot-тестов отказались. Так что в своей новой попытке внедрения snapshot-тестов решили не писать тесты для экранов, а только для ДС.
Каков наш статус тестирования? Какая эффективность исправления дефектов?
В сегодняшней статье рассмотрим статус тестирования и эффективность исправления дефектов.
Полнота покрытия проекта тестами во многом предопределяет его качество, надёжность и безопасность, поэтому команды предсказуемо стремятся писать тесты на все методы и компоненты. Это имеет и обратную сторону: увеличение покрытия удлиняет прогоны, что, в свою очередь, сказывается на продуктовых метриках. В результате при разработке возникает необходимость искать баланс между покрытием и способами ускорения прогонов. Здесь у каждой компании свой подход.
Меня зовут Мария Рогова. Я iOS-разработчик в ОК. В этой статье я расскажу, с чего мы начинали, почему требовалась оптимизация и что мы предпринимали для ускорения прогона UI-тестов в iOS.
Статья посвящена использованию Gradle в автоматизации тестирования. Рассматриваются настройка проекта, управление зависимостями, запуск тестов и лучшие практики для QA-инженеров. Приведены готовые примеры конфигураций и сравнение с Maven.
За 8+ лет работы в тестировании я сталкивалась с разными подходами ведения базы знаний для тестировщиков на проектах. Где-то на проектах статей в базе знаний было так много, что глаза разбегались от количества информации, которую нужно было изучить на входе в проект. Но чаще попадались проекты, где базу знаний вели редкими набросками или не вели совсем. И это вызывало чувство безысходности в первые месяцы работы на проекте, так как информацию приходилось собирать буквально по крупинкам и не один месяц.
В этой статье я хочу поделиться списком возможных тем для статей, которые могут быть полезными для наполнения базы знаний тестировщиков на проекте.
В условиях стремительных перемен в ИТ‑сфере специалистам по тестированию необходимо быть гибкими, осваивать новые подходы и непрерывно развивать лидерские и коммуникативные навыки. Это помогает оставаться конкурентоспособными вне зависимости от технологий.
Почти всегда можно услышать говорящую фразу «тесты нужны всегда», но увы, это неправда. С вопросом о необходимости автотестов на проекте рано или поздно сталкиваются все команды. Почти у всех есть сомнения, а не рано ли? Окупится ли время затраченное на них?
Давайте разберемся, как понять, нужны ли вам автотесты? Или придем к мнению, что вам они не нужны (пока).
Я работаю в компании, которая занимается тестированием ПО, и одним из наших предложений для клиентов является внедрение автоматизированного тестирования как одного из самых эффективных способов ускорить выпуск релизов без ущерба для качества.
Сегодня доступно множество инструментов: Selenium, Playwright, Cypress и другие. Каждый имеет свои преимущества. Но в подавляющем большинстве наших проектов мы используем Selenium. Расскажу, почему мы сделали такой выбор.
Цель автоматизации — экономия
Главная задача автоматизации — снизить ручную нагрузку и минимизировать человеческий фактор. Рассмотрим на примере интернет-магазина. Если компания выпускает по 5 версий в месяц, перед каждым релизом необходимо проверять ключевые сценарии: добавление товара в корзину, оформление заказа, оплату. Регулярные ручные проверки требуют времени, увеличивают затраты и подвержены ошибкам.
Автотесты выполняют эти проверки быстрее и точнее. С экономической точки зрения, однократные инвестиции в разработку автотестов, как правило, окупаются за счет экономии на многократных ручных проверках.
Однако окупаемость инвестиций напрямую зависит от стабильности продукта и частоты тестирования. Если функциональность, покрытая автотестами, часто меняется, затраты на их поддержку могут превысить выгоду.
Точно так же автоматизация может окупаться долго, если релизы выходят редко или регрессионное тестирование проводится с большими интервалами.
Требования клиентов и гибкость технологий
Как IT-компания, мы сталкиваемся с разными требованиями заказчиков. Клиенты часто просят использовать определенный язык программирования, чтобы их команды могли поддерживать тесты. Например, если бекэнд написан на C#, то и автотесты предпочтительнее на нем.
Всем привет. Недавно понадобился мобильный браузер для работы на iOS и пока искал сделал сравнительный анализ. В статье выделены критерии оценивания, проанализированы преимущества и недостатки каждого из решений, рассказывается об интересном функционале.
N месяцев — столько ушло на то, чтобы ваше приложение стало тем, каким вы хотели его видеть. И вот оно – готово. Пора показать миру!
Но перед тем как приложение попадёт в руки пользователей, его должны одобрить строгие модераторы App Store и Google Play. И вот тут начинается самое интересное. За последние годы требования стали такими, что даже опытные разработчики получают реджекты по полной программе.
В данной статье приведем простые действия и технические моменты, которые помогут быстрее пройти модерацию и зарелизиться в сторах.
Работа тестировщика часто состоит из множества мелких, но обязательных действий. Эта статья - подборка инструментов, которые берут часть этой рутины на себя. Здесь вы найдете 10 расширений, чтобы быстро работать с валидацией, визуальной частью или тестовыми данными, делая ваш процесс тестирования более эффективным.
Что такое мобильная ферма и зачем она нужна – расскажем о том, как устроена ферма СовкомТеха и поделимся отзывами коллег.
Привет, Хабр! Меня зовут Максим, и я тестирую мобильные приложения. Знакома ситуация, когда кнопка не работает, приложение виснет, анимации тормозят, но при этом нет никаких ошибок на экране?
Можно часами играть в детектива, гадая по UI и строя догадки, что пошло не так. А можно за несколько минут найти настоящего преступника — ведь iOS щедро оставляет улики в виде логов. Нужно лишь знать, где их искать. Секрет — в грамотном выборе способа, как собрать доказательства. Но обо всём по порядку.
Мы переехали на ARM-архитектуру и наши Appium UI‑тесты стали пробегать в три раза быстрее. И это выгоднее, чем закупать в серверную классические Xeon'ы на X86!
А вдруг вы тоже хотите? Взвесить все «за» и «против» поможет эта статья, а бонусом — расскажу, куда можно дальше развить вашу новую тестовую инфраструктуру. Например, в ферму управления эмуляторами и девайсами.
Привет! Я Женя, работаю QA-инженером. У нас в компании случился классический сюжет: с ростом команды появились проблемы из-за отсутствия системы управления тестированием. Решили внедрять, но какую выбрать? Устроили мини-исследование. Где-то радовал функционал, но пугали возможная блокировка или цена. Где-то нужно было пройти квест по настройке под себя. Были и неожиданно приятные находки. Что в итоге оказалось под капотом у пяти TMS из нашего топ-листа — в моей статье.
Привет! Я Ева, тестировщик в KTS.
В этой статье я хочу рассказать про Requestly — мощный инструмент, позволяющий перехватывать и модифицировать HTTP-запросы и ответы без участия разработчиков. Он особенно полезен при тестировании нестандартных сценариев, симуляции ошибок и быстром создании нужных тестовых данных.
Во многих разделах Requestly есть обучающие видео про работу с этим инструментом, однако они не всегда подробно покрывают все его возможности. К тому же, на русском языке материалов о нем довольно мало. Я решила собрать весь свой опыт работы с Requestly в один объемный туториал — от начала работы до конкретных юз-кейсов.
В этой статье мы разберем как можно быстро и удобно конвертировать mind map в чек листы с дальнейшим импортом в Testops и Testrail.
Цель - сэкономить время на рутинных операциях с тестовой документацией.
Мы ускорили релизный цикл в 2 раза за счёт жёсткого shift‑left: запретили писать и коммитить код без ранней проверки требований и автогенерации тестов ИИ. Рассказываем, как у нас это получилось и насколько выгоден такой подход компании.
Примерно 65% критических багов в IOS-приложениях можно выловить ещё на этапе разработки, если грамотно использовать встроенные инструменты Xcode
В этой статье – подробный разбор инструментов, наиболее востребованных в команде тестирования мобильных приложений в Совкомбанк Технологиях.
