Что пишут в блогах

Подписаться

Конференции

Конференция по тестированию Heisenbug 2022 Autumn

Большая техническая конференция по тестированию Heisenbug 2022 Autumn
7–8 ноября в онлайне и 18 ноября в офлайне в Москве.

Что пишут в блогах (EN)

Разделы портала

Онлайн-тренинги

Практика обучения в QA отделе. Профиль тестировщика
14.04.2022 00:00

Автор: Елена Поплоухина, руководитель группы тестирования в Usetech (https://career.usetech.ru/)

Оригинальная публикация

Добрый день! Я – Елена Поплоухина, руководитель группы тестирования в компании Usetech. В предыдущей статье я рассказывала про опыт построения обучения в группе тестирования на основе практики квартальных целей. 3,5 года мы пользовались этим подходом, но в итоге решили всё переделать. Почему так получилось? Для этого было несколько причин, и о них я расскажу в этой статье.

Это следующие причины:

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

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

  • Периодически не устраивал период выполнения цели в 3 месяца. На квартал могли выпадать и новогодние праздники, и отпуск сотрудника. В таком случае времени на выполнение цели не хватало. Требовалось варьировать период выполнения целей с учётом как их сложности, так и других факторов.

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

Базовая версия профиля тестировщика была получена нами на одном из курсов по тест-менеджменту и переработана на 50% под нашу компанию. Давайте рассмотрим, как выглядит профиль.

Подробнее...
 
Ожидания в Cypress, и как их избежать
13.04.2022 00:00

Автор: Филип Рик (Filip Hric)
Оригинал статьи
Перевод: Ольга Алифанова

Среди тестировщиков множество перфекционистов. Практически у всех, с кем я сталкивался, чешутся руки использовать команду .wait() в Cypress и остановить тест на пару секунд. Если вы из таких людей, то отлично знаете, что такое использование .wait() – не лучшее решение, и пробуете найти альтернативу. Тест просто ничего не делает несколько секунд. Их может быть достаточно, но иногда этого мало.

Когда мы используем .wait(), то хотим, чтобы приложение пршило в нужное состояние. Закрытие модального окна, получение ответа от сети, смена состояния кнопки… Cypress был создан с учетом повторных попыток – это означает, что как только команда сработает, Cypress перейдет к следующей. Если команда не срабатывает, Cypress будет пытаться выполнить ее повторно в течение нескольких секунд.

Эта архитектура часто приводит к тому, что Cypress зачастую слишком быстро бежит по приложению, а мы хотим заставить его подождать. Жестко закодированное ожидание – зачастую способ приказать Cypress замедлиться. Но это не идеальный подход, как я уже говорил. Давайте посмотрим, что можно сделать, если вы сталкиваетесь с этим пугающим решением.

Подробнее...
 
Конференция для senior-тестировщиков
12.04.2022 00:00

Test Driven Conf ++ 2022 — конференция об автоматизации в тестировании и не только. Вас ждут 2 дня живого общения, более 30 докладов от профессионалов индустрии на актуальные темы, знакомство с современными подходами в автоматизированном тестировании, обзор лучших практик, лайфхаков и перспективных технологий.

Программа конференции построена вокруг тематик:
— Cutting-edge технологии;
— Cookbook - готовые рецепты;
— Нагрузочное тестирование;
— Автоматизируем рутину;
— Оптимизация тестов и аналитики и др.

Программа и расписание конференции.

Билеты уже в продаже, успейте до 15 апреля забронировать участие по выгодной цене. Присоединяйтесь!

 
Сочетание Shift-Left и «Традиционной» модели тестирования в будние дни QA
11.04.2022 00:00

Автор: Владислав Тарасенко

Оригинальная публикация

В этом материале будет кратко рассказано, почему Shift-Left – это не всегда хорошо и почему не стоит забывать о традиционной модели тестирования. Рассмотрим паттерны поведения QA при тестировании обычных задач и как постепенно стать продуктивным тестировщиком, не утопая в регрессах и бесконечных проверках одного и того же.

Я часто подхожу к тестированию как к игре в шахматы. Это делает процесс поиска проблем не монотонным, порой даже увлекательным и полезным. В научной и технической литературе у этого метода тестирования есть название: Shift-Left тестирование, но всегда ли нужен такой подход?

Подробнее...
 
Введение в тестирование контрактов, часть 4 – автоматизация процесса
07.04.2022 00:00

Автор: Баз Дейкстра (Bas Dijkstra)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

Подробнее...
 
Автоматизация тестирования на примере Allure TestOps
06.04.2022 00:00

Автор: Руслан Ахметзянов, Qameta Software

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

А ведь десять лет назад релизы происходили раз в месяц, если не реже. Ускорение релизного цикла в сотни раз стало возможным благодаря десяткам новых инструментов и подходов в разработке и эксплуатации. Ломающий барьеры DevOps с облаками, CI/CD системами, контейнерами и мониторингами и рассчитанный на максимальный фокус и скорость Agile применяют (с переменным успехом) порядка 80% IT-компаний.

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

Подробнее...
 
Совместное программирование и задачи для Рук, Мозгов и Голосов
05.04.2022 00:00

Автор: Маарет Пюхяярве (Maaret Pyhäjärvi)
Оригинал статьи
Перевод: Ольга Алифанова

В ходе летней конференции Agile 2021 я занималась тем, что до этой поры никогда не удавалось закончить. Я организовывала группы, пробующие заниматься совместным программированием, и наблюдала за их деятельностью. В результате у меня получился материал, на который я сегодня наткнулась – я назвала его "Задачи для Рук, Мозгов и Голосов".

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

Подробнее...
 
Автоматизировать или нет: спорные кейсы, плюсы и минусы автотестов
04.04.2022 00:00

Автор: Дмитрий Ремезов, QA-инженер, Технократия

Миру требуется все больше и больше софта: любой магазин или автосервис хочет сайт или мобильное приложение. Но забагованный софт не хочет никто, нам нравится, когда все работает красиво и корректно. Эффективно искать баги помогает тестирование, и иногда оно проходит автоматически. Вот про этот случай мы и поговорим.

Качество разрабатываемого продукта конечно зависит от всей команды, но давайте выделим тестирование, в нем я разбираюсь. Меня зовут Дмитрий Ремезов, я QA-инженер в Технократии, и в этом тексте я дам вам вводные об автоматическом тестировании: когда оно поможет, а когда от него стоит отказаться. Дам список из плюсов и минусов подхода, и в конце опишу проект, которому точно требуется автоматизация.

Подробнее...
 
Как узнать, что ваша автоматизация обречена
01.04.2022 00:00

Автор: Деннис Мартинез (Dennis Martinez)
Оригинал статьи
Перевод: Ольга Алифанова

Не все проекты по разработке ПО обречены на успех. На самом деле, как гласит множество исследований, большая их часть провальна отчасти или полностью. К примеру, исследование Standish Group выявило, что две трети изученных ими проектов по разработке ПО не достигли успеха. Другой опрос 2016 года от Innotas показал, что 55% респондентов участвовали в провальном проекте в этом году. Если вы работаете в разработке ПО, то реальность такова, что шансы не в вашу пользу.

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

Подробнее...
 
Вред прямой автоматизации, SpecFlow, TypeScript, сравнение инструментов тестирования нагрузки: самые интересные новости тестирования за конец марта-2022
31.03.2022 11:30

Опубликован выпуск рассылки за начало марта.

В выпуске собраны ссылки на новые статьи, слайдкасты, отобраны самые интересные публикации в ленте блогов и темы на форуме.

Содержание рассылки доступно по ссылке.

Подписаться на рассылку

 
Не автоматизируйте test cases
30.03.2022 00:00

Перевод: Поповкин Игорь

Автор оригинала: Blake Norrish

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

Общепринятой практикой в индустрии является использование тест кейсов в качестве основы для автоматизации тестирования. QA инженеры разрабатывают их на основе user stories в рамках обычного тестирования, а затем автоматизируют эти тесты. С каждой итерацией тестируется больше историй, автоматизируется больше тестовых случаев, и набор автоматических тестов становится всё больше. Руководители продвигают такие метрики, как, например, «процент покрытия» и хвалят команды с высокими показателями. Некоторые компании даже специально нанимают «инженеров по автоматизации», чья единственная работа состоит в том, чтобы брать тест кейсы и автоматизировать их.

К сожалению, автоматизация тест кейсов и навязывание «процента покрытия» — это антипаттерн обеспечения качества, который неизбежно приводит к раздутым и сложным в обслуживании наборам тестов, которые приносят мало пользы. Хотя автоматизация имеет решающее значение для agile delivery, этот чрезмерно упрощенный подход «фабрики автоматизации» не является хорошим способом автоматизации тестирования.

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

Подробнее...