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

Меня зовут Ксения Сергеева, я QA-инженер в компании SM Lab, IT-компания Спортмастера. Сейчас работаю с мобильным приложением для продавцов, а за последние несколько лет успела потрудиться на благо финтеха и сервисов топливной компании. И, конечно, на каждом из проектов я сталкивалась с проведением регрессионного тестирования.

Что самое креативное в работе QA-инженера? Тестировать новую функциональность. Что самое скучное в работе QA-инженера? Гонять регресс. Здесь со мной могут не согласиться нелюбители писать документацию, но и в таком случае прохождение регресса занимает почетное второе место в списке самых занудных активностей QA.

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

А еще регрессу как правило сопутствует куча ограничений. Сдвинулись сроки передачи фичи в тест? Время на регресс уменьшилось. Близится конец периода, а мы не все успеваем? Режем регресс. Коллега ушел на больничный и рук не хватает? Ну, вы понимаете.

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

Для начала внедрения тестирования контрактов существует множество хороших ресурсов, которые помогут вам с практической стороной ваших проблем. Скажем, если вы работаете с Pact, у него есть документация и отличное сообщество в Slack – они помогут вам найти ответы на многие вопросы.

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

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

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

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

Большинство людей, думая или говоря о тестировании контрактов, думают об ориентированном на потребителя варианте, который часто сокращают, как CDCT. Однако тестирование контрактов куда шире «только» CDCT. Одним из первых вопросов, на которые надо найти ответ, и про который часто забывают, будет вопрос «Какой тип тестирования контрактов лучше всего подойдет нашей ситуации?»

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

Автор: Кассандра Ланг (Cassandra H. Leung)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

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

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

Загляните в свежий Интернет, и вы, скорее всего, найдете Еще Одну Статью про Регрессионное Тестирование, утверждающую, что регрессионное тестирование нужно автоматизировать, потому что это механическая повторяющаяся деятельность.

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

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

Test Replay приходит в Cypress

Возможно, вы слышали новости о Cypress. Версия 13, их крупнейший релиз, демонстрирует функцию Test Replay, позволяющую пройтись по прогону своих тестов. В ходе прогона все снимки DOM, сетевые вызовы и логи консоли будут записаны, позволяя глубоко анализировать прогон.

Cypress – решение с открытым исходным кодом, но за ним стоит компания. Премиум-сервис, который эта компания предлагает – это сервис Cypress Cloud, облегчающий параллелизацию тестов, тест-аналитика, а теперь еще и Test Replay.

Автор: Рауль Парваль (Rahul Parwal)
Оригинал статьи
Перевод: Ольга Алифанова

Исследовательское тестирование – популярный стиль тестирования ПО, который заключается в одновременном изучении продукта, проектировании тестов и их выполнении. В отличие от сценарного тестирования, исследовательское делает упор на открытия, обучение и гибкость.

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

Автор: Элизарян Виктория, должность: SDET/Senior QA Automation, https://www.linkedin.com/in/victoriya-elizaryan-a860a4149/

Добрый день, меня зовут Виктория и я много лет занимаюсь автоматизацией. В этой статье я хотела бы рассказать о паттернах автоматизации, которые использую, а также о такой штуке, как архитектура проекта.
Я разворачивала проекты на разных языках программирования и для различных типов проектов (мобильные, веб, как чистый фронтенд, так и бэкенд). Для себя я выделила 6 паттернов программирования:

Автор: ООО «Программный Продукт»

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

Автор: Роб Мини (Rob Meaney)
Оригинал статьи: Tea-Time With Testers, #01/2021
Перевод: Ольга Алифанова

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