Senior QA
Багодельня — марафон по убийству престарелых багов
Сколько открытых багов у вас в бэклоге? 100? 1000?
А сколько времени они там лежат? Неделю? Месяц? Годы?
А почему так происходит? Нет времени? Надо делать более приоритетные задачи? «Вот сейчас все срочные фичи реализуем, а потом точно будет время на разгребание багов»?
… Некоторые используют Zero Bug Policy, у кого-то хорошо развита культура работы с багами (своевременно актуализируют бэклог, пересматривают ошибки при изменении функциональности и т.д.), а кто-то выращивает волшебников, которые пишут вообще без багов (маловероятно, но, может, и такое бывает).
Сегодня я расскажу вам про наше решение по чистке бэклога багов — проект «Багодельня».
Как выполнять много UI-тестов параллельно, используя Selenium Grid?
Всем привет! Я работаю в Avito и занимаюсь разработкой инструментов для тестирования. Когда у нас стало много UI-тестов, мы столкнулись с проблемой масштабирования Selenium-серверов, и сейчас я расскажу, как мы ее решили.
И так как же все-таки выполнять много UI-тестов параллельно, используя Selenium Grid? К сожалению — никак.
Selenium Grid не способен выполнять большое количество задач параллельно.
Хотите зарегистрировать действительно большое количество нод? Что ж, попробуйте.
Хотите скорости? Её не будет — чем больше нод зарегистрировано на гриде, тем менее стабильно выполняется каждый тест. Как следствие — перезапуски.
Хотите отказоустойчивость на случай, если Grid перестал отвечать? Тоже нет: вы не можете запустить несколько реплик и поставить перед ними балансировщик.
Хотите обновить Grid без даунтайма и чтобы тесты, выполняющиеся в данный момент, не упали? Нет, это не про Selenium Grid.
Хотите не держать тысячи Selenium-ов разных конфигураций в памяти, а поднимать их по требованию? Не получится.
Хотите знать, как решить все эти проблемы? Тогда приглашаю вас прочитать эту статью.
*(Мой доклад с таким же названием уже звучал на Heisenbug 2017 Moscow, и, возможно, кто-то из читателей с ним знаком. Под катом — более подробная текстовая версия рассказа об инструменте).
Улучшая performance review
Про то, как в Avito работает performance review, я очень много раз рассказывал внутри компании, а этой весной ещё и на двух конференциях — TeamLeadConf и CodeFest. Мы активно вкладываемся в доработку процесса, проводим много экспериментов и собираем кучу полезных данных, поэтому каждое новое выступление стабильно включает в себя какой-то новый контент. Цель этой статьи — не выдать вам готовое коробочное решение, а поделиться всеми практиками и инсайтами, которые мы обнаружили на своем пути.
Как тестируют в Автотеке: MindMap’s, статический анализ кода и MockServer
![](https://habrastorage.org/webt/93/rt/-e/93rt-erujom8mgz5w-1gmrjl2ew.png)
Багодельня: BUgHunting. Как найти 200 багов за день
Всем привет! Меня зовут Юля, и я тестировщик. В прошлом году рассказывала вам про Багодельню — мероприятие, проводимое у нас в компании для чистки бэклога багов. Это вполне жизнеспособный вариант значительно уменьшить его (в разных командах от 10 до 50%) всего за один день.
Сегодня я хочу рассказать вам про наш весенний формат Багодельни — BUgHunting (BUH). В этот раз мы не фиксили старые баги, а искали новые и предлагали идеи для фич. Под катом много подробностей про организацию таких мероприятий, наши результаты и отзывы участников.
Zero Bug Policy. Нет багов — нет проблем?
Кто про что, а я про баги.
В прошлом году я рассказывала вам про Багодельню — мероприятие, проводимое у нас в компании для чистки бэклога багов. Событие хорошее и полезное, но решающее проблему с багами разово. Мы провели уже шесть Багоделен, но количество участников постепенно снижалось и стало очевидно, что потребность в этом мероприятии начала отпадать. Основной причиной стало появление у нас Zero Bug Policy. О ней есть не так много источников на русском, где можно почитать и найти удобное решение для себя. В этой статье я расскажу про наш подход к теме и с удовольствием почитаю про ваш опыт в комментариях.
Как мы внедряли Agile-testing
Привет! Меня зовут Алёна Исакова, я ведущий тестировщик в Авито, и я хочу рассказать вам про свой опыт введения Agile-тестирования в команду. Когда я читала доступные на русском языке статьи про Agile-тестирование и ATDD, у меня сложилось впечатление, что я «не модная», «не по Agile». Казалось, что это некая сложная структура, которая требует включения разработчиков, и до её применения мне ещё «пахать и пахать».
Какое-то время я жила с этой мыслью, писала в задачи чек-лист проверок при постановке, собирала встречи «feature-team», на которую приглашались PM, QA, Frontend и Backend для обсуждения нюансов задачи до начала реализации.
Те, кто понимает о чем речь, уже заметили подвох, не правда ли?
Open source: CI/CD и тестовая инфраструктура Авито для Android
В этой обзорной статье мы расскажем, почему решили сделать свою работу открытой, о наиболее значимых библиотеках проекта и сориентируем, куда идти с возникающими вопросами. Детально разберём отдельные библиотеки, Gradle-плагины и наши подходы к разработке в следующих материалах.
![](https://habrastorage.org/webt/ij/ha/sr/ijhasr2dv95azaem9mgilu7e1kw.png)
Автоматизация тестирования в микросервисной архитектуре
Привет, Хабр. Меня зовут Сергей Вертепов, я senior backend инженер. Это небольшая обзорная статья о том, как мы тестировали монолитное приложение Авито, и что изменилось с переходом на микросервисную архитектуру.
Зачем инженерам тратить время на перформанс
Привет, меня зовут Михаил Юдин, я Android-инженер в Авито. Хочу рассказать, в чём польза перформанса и как начать внедрять его в продукте. Осенью 2018 года у нас появилась команда перформанса — есть шаги и инструменты, которые нам помогли, поэтому пора делиться опытом.
Автотесты на Android. Картина целиком
Всем привет!
Автотесты под Android — это непросто. Чтобы выстроить процесс автотестирования, надо запланировать и решить множество задач. Но самая большая беда заключается в том, что нигде нет полного описания, что вообще включает в себя автотестирование под Android, каковы его основные стадии. Отсутствует цельная картина. Этой статьей мы хотим восполнить пробел.
Она также выступит в роли схематичной дорожной карты работы Avokado Project. Мы верим в то, что в скором времени разворачивание автотестирования будет занимать куда меньше времени, чем сейчас. И активно работаем в этом направлении.
«Ну, покати!» или CI/CD мобильных приложений на основе контракта
Всем привет! Меня зовут Дмитрий, я релиз-инженер в команде CI/CD Speed Авито. Вот уже несколько лет мы с коллегами отвечаем за всё, что связано с релизами наших мобильных приложений и не только. Про наши «релизные поезда» и как мы к этому шли уже очень подробно рассказывал Алексей Шпирко.
Но мы не стоим на месте и сегодня постараемся рассказать, как наша система CI/CD эволюционировала из набора скриптов и TeamCity-билдов в полноценный сервис мобильных релизов, позволяющий управлять всем процессом выпуска приложений через удобный интерфейс.
На чем писать Android UI-тесты
Всем привет. Мы в Avokado Project продолжаем рассказывать про автотестирование в Android. Эта статья — обзор и сравнение существующих инструментов для написания UI-тестов.
Давайте начнем с того, что вспомним, как обычно выглядит процесс тестирования. Будем называть сущность, которая взаимодействует с приложением, клиентом. Для взаимодействия с приложением клиенту обычно доступно несколько интерфейсов: API, REST API, CLI, GUI и т.д. И если, например, API используются клиентами-программами, то GUI используется человеком.
Ожидания от поведения приложения описываются в спецификации. Задача тестирования — проверить, что поведение приложения соответствует спецификации.
Crash-crash, baby. Автоматический мониторинг фатальных ошибок мобильных приложений
Всем привет! Меня зовут Дмитрий, я релиз-инженер в команде CI/CD Speed Авито. Вот уже несколько лет мы с коллегами отвечаем за всё, что связано с релизами наших мобильных приложений и не только. В прошлый раз я рассказывал о нашей системе релизов мобильных приложений на основе контракта. Сегодня речь пойдет о том, как мы автоматизировали сбор информации из Firebase о новых фатальных ошибках в мобильных приложениях.
Организация кодовой базы и тестирования в монорепозитории
Всем привет. Меня зовут Илья, я фронтенд-разработчик из юнита BuyerX в Авито. Хочу поделиться тем, каким образом у нас в команде организовано хранение кодовой базы, почему мы пришли к использованию монорепозитория и как улучшаем DX-работы с ним, а также кратко рассказать про организацию тестирования.
Live site review. Разбираем инциденты
Нам важно, чтобы Авито стабильно и надёжно работал. Но бывает, что несмотря на наши усилия, что-то ломается. Это может быть железо или какой-то архитектурный компонент под высокой нагрузкой. В этом случае важно починить возникшую проблему как можно быстрее. Для этого у нас есть развесистая система мониторинга и алертов, а также служба круглосуточных дежурных.
Помимо того, чтобы быстро восстановить работу сервиса, важно избежать повторения проблем там, где это возможно. А там, где предотвратить аварии совсем нельзя, — минимизировать ущерб как для пользователей, так и для сотрудников.
Поэтому кроме круглосуточного мониторинга у нас есть процесс разбора инцидентов. И сами пожары на проде, и работы по анализу проблем мы называем live site review или LSR. Я отвечаю за часть работ с LSR после пожаротушения и хочу поделиться нашими наработками.
Ошибка.log(): как логируются ошибки в мобильном приложении Авито
![](https://habrastorage.org/r/w780/getpro/habr/upload_files/7e3/209/092/7e32090923ee52020e4e3ee143f26d14.jpeg)
Вы настроили в приложении краш-репортинг, всё протестировали и выложили в магазин. Постоянно мониторите crash rate, в котором всегда четыре девятки, — приложение работает отлично и все довольны. Но всё-таки вы смотрите на него как будто сквозь замочную скважину и не видите полной картины. Чтобы это исправить, нужен полноценный лог ошибок.
Как QA-инженер может влиять на unit-тесты
![](https://habrastorage.org/r/w780/getpro/habr/upload_files/a1f/88d/d56/a1f88dd5663ce92fd660932f5c9ba10e.jpeg)
Привет! Меня зовут Алёна Луцик, я QA-инженер в команде Авито. За время работы я много раз убеждалась, что разработчик и тестировщик смотрят на код по-разному.
Зачастую перед тестировщиком стоит задача покрытия функциональности автотестами без избыточных проверок, с соблюдением пропорций пирамиды. Но прежде, чем начать покрывать бизнес-логику, стоит понять, что вообще можно покрыть на уровне unit-тестов.
В статье я расскажу о шагах, которые помогут прийти к взаимопониманию с коллегами-разработчиками.
Как можно тестировать платформенные сервисы
![](https://habrastorage.org/r/w780/getpro/habr/upload_files/cbc/eee/178/cbceee1785ded01933d8b327f6b92694.jpg)
PaaS (Platform as a Service) — внутренняя платформа для запуска и разработки приложений. Если коротко, то наш PaaS позволяет легко и, можно сказать, при нулевом знании внутренней кухни создать свой сервис и начать пилить продуктовые компоненты. Более длинное объяснение — в этом видео. Под катом небольшой рассказ о том, с какими проблемами пришлось столкнуться при первом приближении к тестированию продукта, как происходил сам процесс тестирования платформенных решений на примерах и какую пользу это принесло.
Меня зовут Лариса Седнина, я работаю QA-инженером в Авито в юните QA Center of Excellence. Наш юнит — это центр экспертизы по обеспечению качества, основная задача которого в распространении лучших практик тестирования, помощи в настройке процесса тестирования и разработке инструментов для тестирования.
Информация
- В рейтинге
- Не участвует
- Откуда
- Казань, Татарстан, Россия
- Зарегистрирована
- Активность