Пользователь
Всем привет! Я Оля, тестировщик мобильных приложений в hh.ru. Сегодня мы завершаем серию ответов на самые популярные вопросы про автоматизацию тестирования. Ранее мы уже ответили на вопросы ручного тестировщика, менеджера и технического директора. Пришло время ответить на пять самых интересных вопросов начинающих автоматизаторов — про флакования и баги с прода, нашу борьбу за стабильность и как не терять всеобщее доверие к автотестам.
Всем привет! Меня зовут Алексей, в hh.ru я занимаюсь автотестами и их инфраструктурой.
hh.ru — довольно большой продукт: 150+ микросервисов и 50 команд разработки. Большинство команд пишут E2E-тесты, и на текущий момент написано уже около 1800 тестовых классов, в которых примерно 8000 аннотаций @Test. Как со всем этим жить и как вообще устроено E2E-тестирование в hh.ru разберемся в сегодняшней статье. Поехали!
Привет! Меня зовут Дмитрий Трофимов (@angryqa во ВКонтакте или @trofimovdigital на просторах интернета). Я тимлид отдела автоматизации тестирования в VK ID. С командой мы проделали большой путь при внедрении автотестов в наш продукт, и на этом пути мастерски овладели принципами написания идеальных тестов, которыми спешу поделиться с вами.
Дисклеймер: меня зовут Эрик Бурыгин, я давно работаю тестировщиком, веду студентов на курсе «Инженер по тестированию», поэтому может показаться, что тестировщик просто хочет перекинуть кусок работы на разработчиков. На самом деле у описываемого подхода есть как плюсы, так и минусы, поэтому статья носит в том числе и дискуссионный характер. Буду рад увидеть в комментах мнения как разработчиков, так и тестировщиков.
Summary: Игорь Зубцов, руководитель автоматизированного тестирования в направлении омниканальных решений Лиги Цифровой Экономики, рассказал, как его команда разработала сервис для мониторинга покрытия автоматизированными сценариями, с какими сложностями столкнулись и как он работает.
В этой статье я бы хотел рассказать о разработанном нашей командой сервисе Coverage Manager. Мы используем его для мониторинга покрытия автоматизированными сценариями, однако разработку можно применять и на других проектах.
Естественное желание — видеть наглядный результат работы автоматизаторов на проекте. Всегда хочется знать, а главное, видеть ответы на вопросы: «А что у нас с покрытием этого функционала?», «А покрыт ли у нас этот сценарий?» и подобные. Coverage Manager предназначен для визуальных ответов на многие такие вопросы. Любой причастный к проекту человек может зайти и посмотреть, покрыт ли тот или иной сценарий автотестами, а также пронаблюдать динамику.
***
Когда проект только начинался, у нас работали один автоматизатор и несколько ручных тестировщиков, острой необходимости в снятии метрик автотестирования на тот момент не было. Но постепенно команда росла, проект с монолитной архитектурой оброс микросервисами, и становилось все сложнее помнить и понимать, какой функционал покрыт тестами. Первоочередной целью мы выбрали подсчитать покрытие функционала API-тестами.
Это было особенно важно, поскольку команда проекта поделилась на стримы, и автотестировщики работали относительно изолированно, внутри своих небольших команд, — а из-за этого тесты могли пересекаться.
Привет! Меня зовут Ксения Якиль. Я пишу core-сервисы на C и Go в бэкенд-отделе Badoo и Bumble. Наш бэкенд — это высоконагруженная распределённая система, обслуживающая пользователей по всему миру. Она оперирует большими массивами данных и делает всю ту магию, благодаря которой люди находят друг друга.
В этой статье я не буду концентрироваться на специфике наших сервисов, а расскажу, как мы реализовали автоматизированные интеграционные тесты в распределённой системе, поделюсь общими принципами и нюансами создания фреймворка для них. В тексте будут встречаться отсылки к реализации на Go, так как мы использовали именно этот язык, но понять основную мысль это не помешает.
После весны 2020 года слово “тестирование” приобрело некоторые неожиданные значения и неоднозначные коннотации — пожалуй, везде, кроме IT. В нашей сфере без него никуда — и так было всегда.
Видов тестирования ПО — множество: модульное, функциональное, А/В-тестирование, интеграционное, нагрузочное и т д. И на наш взгляд, как раз последнее является как самым важным, так и наиболее сложным. Ведь если ошибки, которые могут быть выявлены с помощью A/B-тестов, модульных, функциональных и интеграционных тестов, проявляются практически сразу после “выкатки” новой версии приложения, то проблемы, на выявление которых нацелено нагрузочное тестирование, — “спящие”. И обнаруживаются они только тогда, когда на новую версию вашего сайта или приложения придет реальный пользовательский трафик, с которым не справится “софтверная” часть проекта (база данных, application-сервер) или “железно-инфраструктурная” (нехватка оперативной памяти в кластере, большая нагрузка на дисковую подсистему при операциях чтения-записи).
В этой статье расскажем и покажем, как мы проводим, кажется, эталонное нагрузочное тестирование — в плане полноты покрытия и полноты получаемого в итоге отчёта. Наши наработки вполне воспроизводимы, так что вы можете воспользоваться ими для улучшения работы собственного проекта.
В ЮMoney большой отдел тестирования — в нём почти 80 человек, которые каждый день проверяют качество продуктов и сервисов. В этой статье рассказываем, как мы измеряем эффективность тестирования, какие метрики собираем и что за результаты это приносит.
Процесс погружения в автоматизацию волнует и начинающих специалистов, и опытных инженеров по тестированию. Одни считают, что автоматизация не их конёк, другие — что это трудозатратный процесс, который стоит отложить. В этой статье расскажем, как погрузиться в автоматизацию новичку, а также дадим совет, как начать автоматизировать на проекте.
Рассмотрим две отправные точки погружения в автоматизацию: 1) когда начинающий специалист задумался о переходе на этапе обучения или выбрал путь автоматизатора изначально; 2) опытный инженер в роли Manual QA на проекте.
Рассказываем, как создали понятную систему оценки качества для команд разработки Авито. Мы отобрали самые релевантные метрики, протестировали их, а затем показали коллегам, как ими пользоваться. Звучит просто, но на самом деле это был долгий и кропотливый процесс. Что получилось в итоге, читайте в статье.
Мы продолжаем делиться внутренними документами Авито. Сегодня это будет модель зрелости. Она может пригодиться как трекер внедрения инженерных практик всем компаниям, где есть своя разработка. Чётко прописанная модель зрелости помогает быстро синхронизироваться и находить зоны роста команд.
Всем привет! Меня зовут Иван Чечиков, я QA lead в МТС Digital, работаю над проектом стримингового сервиса WASD.TV. В этой статье я поделюсь опытом о том, как мы внедряли систему управления тестированием (TMS) Allure TestOps в наш проект и что из этого получилось. А еще отмечу подводные камни, с которыми столкнулись и обозначу пути их обхода. Статья может быть полезна тем, кто задумываются о переходе на данную TMS с других готовых решений, таких так Zephyr, TestRail, Test IT.
Подробности – под катом.
В этой статье я попытался придать систематический вид основным видам тестирования, которые я нашел в различных источниках. Идея для этой статьи зародилась у меня, когда я обнаружил, что в интернете существует множество разнообразных классификаций, и многие отличаются друг от друга. Вначале я начал это исследование для себя, но затем решил поделиться результатами со всеми, надеясь, что оно пригодится другим, как и мне.
Привет! Меня зовут Оля, я работаю в сфере обеспечения качества ПО уже более 15 лет. За это время я успела поработать в самых разнообразных компаниях по очень разным направлениям: от ПО для автозаправок до финтеха и агротеха. Пробовала себя и в ручном, и в автоматизированном тестировании. В итоге ушла с головой в менеджмент.
Больше всего мне нравится работать над процессами: выстраивать с нуля, встраивать практики обеспечения качества в существующие процессы, калибровать их в зависимости от результатов и прочее.
Сейчас я курирую QA в нескольких командах в Спортмастер Лаб, и в том числе помогаю им выстраивать те самые хорошие процессы.
На одной из прошлых SQA days я сделала доклад на тему анализа дефектов в командах, и решила написать статью по его мотивам.
В этой статье я собираюсь поделиться некоторыми идеями, которые помогли создать качественные продукты. Хотя QA не является единственным лицом, ответственным за качество, но в большинстве случаев QA является последним человеком, который проводит предварительное / сквозное тестирование, прежде чем доставлять или демонстрировать его клиентам.
Это будет полезно для тестировщиков, обычно фокусирующихся на тестировании с использованием "черного ящика" и автоматизации тестирования, но не проникающихся архитектурой и деталями реализации.
Тенденцией современности является изучение всё большего количества инструментов для автоматизации, но мышление QA важнее.
Данное руководство позволит оценить требующийся уровень знаний для инженеров по автоматизации и инженер по разработке ПО в тестировании (SDET). Статья содержит конкретные критерии, которые должны стать ориентиром при необходимости перехода на новый уровень.
Гуд ньюз эвриван! Спустя полтора года работы восьми айтишников с суммарным опытом в IT 130 лет достигнут результат в виде учебника по тестированию, которого еще никто и никогда не делал.
Если бы мне задали такой вопрос, то я не смог бы на него правильно ответить. Ведь начинал я с ручного тестирования, а сейчас мы департаментом раскатываем на весь банк гигантский «дашборд», который привязан буквально ко всем данным компании, и позволяет оценить качество работы любой команды. Меня зовут Иван Боклач, я руководитель направления развития экспертизы QA в Центре Координации и Повышении эффективности разработки в Альфа-Банк. Я занимаюсь развитием новых технологий, метриками, стандартизацией и автоматизацией процессов.
Всё это пишу не для хвастовства, отнюдь, а чтобы показать, куда вас может привести дорожка QA. И, главное, что на этой дорожке вам нужно «крафтить», чтобы получить примерно те же результаты.