Что же не так с ДЭГ в Москве

Где лежат результаты и как их проверять

Привет, Хабр! Меня зовут Сергей Радченко, и мы с командой профессионально занимаемся тестированием уже несколько лет. Сегодня я посчитал количество автотестов, которые мы подготовили для веб-интерфейсов, десктопных приложений, API, систем двухфакторной авторизации и так далее (их оказалось более 5000). И мне захотелось рассказать о нашем опыте создания экосистемы для автоматизированного тестирования. В этом посте вы найдете описание полезных для комплексного тестирования фреймворков, а также исходный код некоторых дополнительных методов, которые мы дописали самостоятельно, чтобы написание тестов происходило быстрее, и тестирование приносило больше пользы. 

Привет, Хабр! Меня зовут Александр Старостин, я занимаюсь тестированием биллинговой системы МТС. Тестирование бэкенда — важная часть процесса проверки разработки ПО. Покрытый тестами бэкенд минимизирует ошибки при выкатывании новых фич на прод и в целом делает разработку более предсказуемой. Тесты бэкэнда быстрее разработать, они стабильнее и быстрее в прогоне, в отличии от тестов пользовательского интерфейса. К тому же не у всякого сервиса есть интерфейс, например публичный API для внешних систем. Но ручное тестирование может быть очень трудоемким. И тут нам на помощь приходит ее высочество автоматизация. О ней мы сегодня и поговорим.

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

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

Об этом я и хочу сегодня поговорить.

Конференция по тестированию Heisenbug грядет: до старта осталось меньше месяца. В программу вносят последние штрихи, поэтому уже можем рассказать Хабру, какие доклады в неё попали.

Будут полюбившиеся зрителям спикеры, работающие над популярными инструментами: Артем Ерошенко (автор Allure Framework), Андрей Лушников (занимается Playwright), Олег Ненашев (из команды Jenkins).

Будут и совершенно новые темы. Например, впервые на Heisenbug поговорят о тестировании Flutter-приложений и умных девайсов. Более того, речь зайдёт даже о беспилотных автомобилях и экзоскелетах!

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

Для хабрапоста мы разбили полный список докладов на тематические блоки —  так что можете выбрать интересное вам и перейти к нему.

Это вторая статья из короткого цикла про создание инфраструктуры для автотестов. Первая доступна здесь.

3 года назад команда Fiji решила переизобрести инфраструктуру для интеграционных тестов. Мы перенесли тестовые БД в docker-контейнеры и научились поднимать в Kubernetes контур для автотестирования.

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

Всем привет! Я Оля, тестировщик мобильных приложений в hh.ru. Ранее мы уже выпустили статью с ответами на вопросы ручного тестировщика про автотесты (а также в  формате видео). Продолжаем серию ответов: в этой статье мы ответим на 5 самых популярных вопросов менеджера про автотесты. Расскажем о том, сколько времени и ресурсов будет потрачено на автоматизацию, и как скоро она начнет приносить пользу. Видеоверсию можно посмотреть тут.

В последние лет пять про облачные технологии слышно все чаще. Microsoft и Amazon отчитываются о высоком росте доли облачных сервисов в отчетах о прибыли. Российский Яндекс относительно давно продвигает свое Облако. К этому подключился и Сбер со своим облачным продуктом. Часто можно услышать и о других, менее крупных игроках.

Смотря на все это многообразие я подумал, что происходит какая-то вечеринка, а меня не пригласили. Ну что же, давайте присоединимся к этой вечеринке сами разместив сайт на Azure и сравнив тарифы службы приложений и службы БД.

Цель этой статьи можно выразить в 2х пунктах:

1. С одной стороны мы познакомимся с тарифными планами службы веб-приложений и службы хостинга баз данных

2. С другой стороны мы проведем нагрузочное тестирование тремя стратегиями тестирования в разрезе разных тарифных планов.

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

Я аналитик, который сам недавно оказался в ситуации первого типа (вообще не слышал ничего о GraphQL и Hasura, каюсь), поэтому статья не претендует на глубокое погружение в тему и нацелена скорее на аналитиков и тестировщиков, которые не работали с упомянутыми инструментами.

Теперь всё, переходим к контенту с чистой совестью.

Интеграция утилит покрытия кода gcov/lcov в проект на базе сборочной системы QBS.

Привет, читатель!

Меня зовут Василий Кудрявцев, и вот уже ~10 лет я занимаюсь нагрузочным тестированием, а из них последние 1,5 года – в компании РТЛабс.

И сегодня мы поговорим не об инструментах или общих подходах, а об области, которую обычно обходят стороной или собирают на коленке — тестовые стенды для нагрузочного тестирования.

Здесь, на Госуслугах, мы пока только конструируем мечту каждого нагрузочника — свой отдельный, выделенный, рабочий (!) тестовый стенд.  Особенно это мечта актуальна для небольших продуктовых команд.

Всем привет. Меня зовут Серёжа Аксёнов, и я тестировщик. А ещё я пишу стихи, и сегодня мы попытаемся скрестить ежа с ужом.

Шутка. На самом деле и тестированием, и поэзией я занимаюсь довольно долго и хочу поделиться своими наблюдениями о том, как привычные тестировщику навыки и подходы могут быть эффективно применены в области, на первый взгляд, далёкой от IT — литературной критике. 

Тестирование – та же критика, только не стихов/прозы, а программ. Но поэзия, хоть и существует пару тысячелетий, в настоящее время является областью глобально менее значимой для человечества, чем программирование. На повышение эффективности литературы не бросаются такие силы и средства, как на разработку ПО. Поэтому молодая наука сегодня учит старую. Хотите поговорить об этом?

Может показаться, что я не люблю поэзию. Нет! Не любят поэзию те, кто не хочет, чтобы она развивалась.

Итак, рассмотрим неумелую литературную критику как набор антипаттернов тестирования ПО.

Эта статья является переводом материала «When to Mock».

Использование моков в модульном тестировании является спорной темой. Автор оригинала заметил, что на протяжении всей своей карьеры в программировании он сначала перешел от «моков почти для каждой зависимости» к политике «без моков», а затем к «только моки для внешних зависимостей».

Ни одна из этих практик не является достаточно хорошей. В этой статье Владимир Хориков покажет, какие зависимости следует мокать, а какие использовать как есть в тестах.

Я посмотрела, как тестируют поиск начинающие тестировщики, и решила написать этот чит-лист проверок. Это такая серебряная пуля, которую можно применить на любом проекте, лишь немного варьируя под себя, под свой проект.

Поиск — он же есть практически в каждой системе. Поэтому здорово, когда есть шпаргалка «какие вопросы задать аналитику» и «какие проверки провести». Именно это мы в статье и обсудим. Сначала я дам чек-лист, а потом разберу каждый пункт отдельно.

Как заниматься парным программированием, если коллеги сидят поодиночке в разных квартирах? И если не подозвать коллегу со словами «смотри, как это делается», с помощью чего записать для него скринкаст? А какие инструменты для тестирования особенно актуальны при удалёнке?

Весной на TechTrain это обсудили Всеволод Брекелов (vbrekelov) и Артём Ерошенко (eroshenkoam). Им близок мир тестирования, поэтому получился уклон в эту сторону, но упомянуто и много универсального. Зрителям обсуждение понравилось — поэтому теперь мы сделали его текстовую расшифровку.

Если вы знаете, какие ещё инструменты стоило бы упомянуть, то расскажите о них в комментариях. А мы тем временем готовим следующий TechTrain: это бесплатное IT-мероприятие, которое пройдёт онлайн уже 18 сентября (в следующую субботу). Так что если этот материал вас заинтересует, то и на новые доклады стоит обратить внимание.