Articles / Bookmarks / Profile of eroshenkoam / Habr

Артем Ерошенко @eroshenkoam

User

Profile Publications 2Comments 13Bookmarks 13

ilyubin Mar 29 2022 at 16:14

Grafana и автотесты: учимся измерять работу тестов

8 min

16K

Website development*IT systems testing*Web services testing*Development Management*Ozon Tech corporate blog

Управление — трудоёмкая работа, которая усложняется при отсутствии подходящего инструмента. Легко упустить из виду постоянно меняющиеся компоненты и сложно быть в курсе событий: что-то обязательно проходит незамеченным.

Grafana позволяет собрать на одном экране разную информацию:

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

Этот список можно продолжать и вводить новые метрики для задач тестирования. Расположение метрик на одном экране позволяет получать прозрачные отчёты о тестировании, которые понятны и инженерам, и руководителям. Главное в этом деле — научиться измерять и правильно подсвечивать проблемы. Тогда управлять тестированием станет проще.

На примерах наших тестов покажу, как Grafana помогает в анализе результатов автотестирования, чтобы точнее понимать, что происходит.

Читать дальше →

+30

yurchenkovski Nov 24 2021 at 17:29

Будущее ручного тестирование и главные тренды области: интервью с Артёмом Ерошенко

4 min

8.7K

IT systems testing*InterviewDINS corporate blog

Артём Ерошенко — CPO и сооснователь Qameta Software. Он преподает тестирование, хостит подкаст «Айтишники», делает доклады в IT-сообществе, а 1 декабря во второй раз станет ведущим QA Meeting Point. Артём рассказал, зачем делиться знаниями и почему он не верит в будущее ручного тестирование.

+14

vvmax Sep 9 2021 at 12:16

Путь к автоматизации тестирования в SuperJob: инструменты, проблемы и решения

8 min

9.8K

IT systems testing*TDD*SuperJob corporate blogDebugging*Web services testing*

Привет, Хабр! Меня зовут Антон Шкредов, я QA Lead в SuperJob. В День тестировщика хочу поделиться историей о том, как около четырех лет назад мы с командой перешли от ручного тестирования к автоматизации UI и какой профит в итоге получили. Внутри подробности про усталость от ручных тестов, с чего начали автоматизацию, какие инструменты использовали, а также про сложности и бонусы от внедрения.

+21

ARG89 May 24 2021 at 11:59

Управление тестами в TestOps: храните информацию, а не выводы

8 min

6.7K

IT systems testing*Web services testing*

Обеспечить представление данных из любой большой системы так, чтобы человек мог спокойно с этими данными работать — задача нетривиальная, но давно решенная. В этой гонке уже давно победило "дерево". Папочные структуры в операционных системах знакомы всем и каждому и исторически простое дерево в UI/UX становится первым решением для упорядочивания и хранения данных. Сегодня поговорим о тестировании, так что в нашем случае объектами хранения будут выступать тест-кейсы. Как их хранят чаще всего? Верно, в папочках!

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

Давайте!

+11

vaniaPooh Oct 6 2015 at 17:57

Тестирование в Яндексе. Как сделать отказоустойчивый грид из тысячи браузеров

7 min

41K

Website development*Open source*Java*Яндекс corporate blogWeb services testing*

Любой специалист, причастный к тестированию веб-приложений, знает, что большинство рутинных действий на сервисах умеет делать фреймворк Selenium. В Яндексе в день выполняются миллионы автотестов, использующих Selenium для работы с браузерами, поэтому нам нужны тысячи различных браузеров, доступных одновременно и 24/7. И вот тут начинается самое интересное.

Selenium с большим количеством браузеров имеет много проблем с масштабированием и отказоустойчивостью. После нескольких попыток у нас получилось элегантное и простое в обслуживании решение, и мы хотим поделиться им с вами. Наш проект gridrouter позволяет организовать отказоустойчивый Selenium-грид из любого количества браузеров. Код выложен в open-source и доступен на Github. Под катом я расскажу, на какие недостатки Selenium мы обращали внимание, как пришли к нашему решению, и объясню, как его настроить.

Читать дальше →

+51

eroshenkoam Dec 15 2014 at 15:58

Курс от Яндекса о том, что должен знать каждый разработчик, который хочет делать большие системы. Модное слово DevOps и другое

5 min

107K

Website development*IT systems testing*Яндекс corporate blogVersion control systems*Web services testing*

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

В Яндексе тестировщику невозможно без автоматизации. Мы даже развиваем экспериментального робота, который способен брать на себя функциональное тестирование. В какой-то момент мы поняли, что не так много людей осознают, сколько сейчас есть возможностей работать не 12 часов, а головой. Собрав весь свой опыт в тестировании и деплое, мы открыли в питерском офисе Яндекса Школу автоматизации процессов разработки. У нас получилась школа, где каждый, кто пишет код, может получить базовый набор знаний о том, как собрать, запустить и поддерживать сервис в продакшене так, чтобы это стоило недорого.

Курс открывает моя лекция о том, зачем вообще автоматизировать процесс разработки. Из нее вы получите представление о то, что будут рассказывать мои коллеги.

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

Читать дальше →

+64

jkt Aug 15 2014 at 14:35

Как внедрить у себя back-to-back-тестирование. Опыт Яндекса

8 min

20K

IT systems testing*Яндекс corporate blog

При ускорении разработки возникает потребность ускорить и написание автотестов. К числу подходов, позволяющих покрывать тестами значительные куски функциональности за небольшое время, относится back-to-back-тестирование. Одна из наиболее распространенных разновидностей подобного тестирования для веб-сервисов – это сравнение скриншотов. Мы рассказывали о том, как используем его в тестировании поиска Яндекса. Если у вас имеется протестированная версия продукта, то создать набор автотестов для следующих версий достаточно просто и на это не потребуется много времени. Основная трудность состоит в том, чтобы в разных версиях сервиса воспроизводились идентичные ситуации. Для этого зачастую приходится поддерживать большое количество тестовых данных в нескольких средах.

Когда задумываешься об использовании back-to-back-подхода, первое, что приходит в голову, – проводить сравнение со стабильной средой. Но как эталон она подходит для очень ограниченного круга продуктов, потому что данные в стабильном и тестовом окружении зачастую расходятся. Нередко, убедившись, что проводить сравнение со стабильной средой не удастся, исследователь отказывается от использования back-to-back-тестирования. Читайте под катом о паре стандартных способов внедрения данного подхода, которые мы используем для сервисов Яндеса и которые решают многие проблемы, возникающие при использовании стабильной среды. Также мы расскажем об их достоинствах и недостатках, которые мы обнаружили.

Читать дальше →

+38

art_koshelev Aug 8 2014 at 14:06

Allure — фреймворк от Яндекса для создания простых и понятных отчётов автотестов [для любого языка]

4 min

148K

Website development*IT systems testing*Яндекс corporate blog

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

Я вижу здесь сразу несколько проблем: ручные тестировщики не знают, насколько автотесты соответствуют написанным тест-кейсам; ручные тестировщики не знают, что именно покрывается автотестами; автоматизаторы тратят время на разбор отчётов. Как ни странно, но все три проблемы вытекают из одной: результаты выполнения тестов понятны только автоматизаторам — тем, кто эти тесты писал. Именно это я и называю непрозрачностью.

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

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

Читать дальше →

+65

Lanwen Jul 4 2014 at 15:03

Тестирование в Яндексе. Сам себе web-service over SSH, или как сделать заглушку для целого сервиса

10 min

23K

Website development*IT systems testing*Яндекс corporate blog

Вы практикующий ~~маг~~ менеджер. Или боевой разработчик. Или профессиональный тестировщик. А может быть, просто человек, которому небезразличны разработка и использование систем, включающих в себя клиент-серверные компоненты. Уверен, вы даже знаете, что порт это не только место, куда приходят корабли, а «ssh» это не только звук, издаваемый змеёй. И вы в курсе, что сервисы, расположенные на одной или нескольких машинах, активно между собой общаются. Чаще всего по протоколу HTTP. И от версии к версии формат этого общения нужно контролировать.

Думаю, каждый из вас при очередном релизе задавался вопросами: «Точно ли мы отсылаем верный запрос?» или «Точно ли мы передали все необходимые параметры этому сервису?». Всем должно быть известно и о существовании негативных сценариев развития событий наравне с позитивными. Это знание должно активно порождать вопросы из серии «Что если..?». Что если сервис станет обрабатывать соединения с задержкой в 2 часа? Что если сервис ответит абракадабру вместо данных в формате json?

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

Читать дальше →

+41

smecsia Apr 7 2014 at 19:50

Плагинизация с использованием Maven и Eclipse Aether

10 min

4.3K

Java*Eclipse*

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

Подробности

eroshenkoam Oct 31 2013 at 16:00

Опыт от Яндекса. Как делать свой отчет для автотестов

15 min

22K

IT systems testing*Яндекс corporate blog

Tutorial

Хочу поделиться опытом, о том, как создавать хорошие отчёты об автотестах и одновременно пригласить вас на первое мероприятие Яндекса специально про тестирование.

Сначала пару слов о событии. 30 ноября в Санкт-Петербурге мы проведём Тестовую среду — своё первое мероприятие специально для тестировщиков. Там мы расскажем, как у нас устроено тестирование, что мы сделали для его автоматизации, как работаем с ошибками, данными и графиками и о многом другом. Участие бесплатное, но мест всего 100, поэтому надо успеть зарегистрироваться.

Тестовая среда для нас в первую очередь — площадка для общения. Мы хотим не только рассказать о себе, но и поговорить с участниками о том, как работают они, обменяться знаниями, ответить на какие-то вопросы. Думаем, общих тем будет много, но чтобы вы начали обдумывать их уже сейчас, мы начинаем серию публикаций о тестировании в Яндексе.

Автоматизации тестирования на Тестовой среде будет посвящено несколько докладов, в том числе мой. Итак, начну.

Бывают unit-тесты, а бывают высокоуровневые. И когда их количество начинает расти, анализ результатов запусков становится проблемой. Скажите честно, кто из вас не думал сделать свой отчет?

Читать дальше →

+54

LeonSabr Nov 6 2013 at 16:13

Как мы тестируем поиск в Яндексе. Screenshot-based тестирование блоков результатов

5 min

41K

IT systems testing*JavaScript*Яндекс corporate blog

Чем крупнее и сложнее становится сервис, тем больше времени приходится уделять тестированию. Поэтому желание автоматизировать и формализовать этот процесс вполне законно.

Чаще всего для автоматизации тестирования веб-сервисов применяется Selenium WebDriver. Как правило, с его помощью пишут функциональные тесты. Но, как всем хорошо известно, функциональные тесты не могут решить задачу тестирования верстки сервиса, что требует проведения дополнительных ручных, зачастую кроссбраузерных, проверок. Как тест может оценить корректность верстки? Чтобы обнаружить регрессионные ошибки верстки, тесту потребуется некоторый эталон, в качестве которого может выступать изображение корректной верстки, взятой, например, с продакшен-версии сервиса. Этот подход носит название screenshot-based testing. Подход этот применяется достаточно редко, и чаще всего верстку все же тестируют вручную. Причина этому – ряд достаточно строгих требований к сервису, к среде выполнения тестов и к самим тестам.

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

На примере тестирования колдунщиков в поиске мы расскажем, какими особенностями должен обладать тестируемый сервис, какие проблемы возникают у нас при использовании screenshot-based testing, и как мы их решаем.

Читать дальше →

+64

AlexanderTolmachev Nov 16 2012 at 13:05

Тестирование в Яндексе. Фреймворк HTML Elements: чего не хватает в Page Object, и как это исправить

5 min

39K

Website development*IT systems testing*Яндекс corporate blog

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

Наиболее существенные из них:

невозможность повторного использования кода page-объектов для страниц с одинаковыми элементами;
плохая читаемость и отсутствие наглядности кода для страниц с большим количеством элементов;
отсутствие типизации элементов.

Из этого поста вы узнаете, как мы в Яндексе решаем эти проблемы с помощью фреймворка с открытым исходным кодом HTML Elements. Он расширяет концепцию шаблона Page Object и позволяет сделать взаимодействие с элементами на веб-страницах простым, гибким и удобным.

Мы не будем останавливаться на описании самого паттерна и его принципов, поскольку большинству из вас он наверняка хорошо знаком. Если же кто-то с ним не встречался, то узнать о нём можно из этого поста или мастер-класса. Также, говоря о применении паттерна Page Object, мы будем подразумевать его Java-реализацию в фреймворке Selenium WebDriver.

Повторное использование кода

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

Читать дальше →

+32