Автор: Сарит Вакрат (Sarit Vakrat)
Оригинал статьи
Перевод: Ольга Алифанова

В динамическом мире разработки ПО очень важна способность эффективно масштабировать и оптимизировать процессы. Работая над улучшением инфраструктуры нашей автоматизации в Glassbox, мы пришли к применению возможностей DevOps, Groovy, скриптов DSL и AWS EC2 Jenkins-агентов. Эта комбинация позволила создать масштабируемую и устойчивую систему, способную на запуск более чем 1000 задач в день, что дает нам высокую производительность и надежность.

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

Всем привет! Меня зовут Ксения Лопатина, я вот уже почти 9 лет в тестировании. Не так давно поймала себя на мысли, что мой аккаунт на Хабре совсем запылился. А ведь за годы работы у меня было достаточно много опыта на различных позициях от ручного тестировщика до руководителя и мне действительно есть чем поделиться. Так и пришла в мою голову мысль поднять в очередной раз тему развития в тестировании. Мне кажется, что эта тема будет актуальна всегда. Эта статья будет первой, в планах у меня уложиться в три, но там уж как пойдет. 

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

Автор: Филип Рик
Оригинальная публикация

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

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

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

Конечно, нет.

Автор: Игорь Авдонин

С момента своего появления и по сей день подход Test-Driven Development (TDD) вызывает оживленные дискуссии в сообществе разработчиков, и до сих пор нет единого мнения о ее эффективности.

Но что будет, если совместить TDD и AI-генерацию кода? В статье я покажу:

• Как соединить TDD и AI;

• Как AI-driven TDD улучшает процесс разработки;

• Как TDD влияет на качество сгенерированного AI кода.

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

Кратко о TDD

Разработка через тестирование (Test-Driven Development, TDD) — это методология программирования, при которой тесты пишутся до написания кода. Процесс строится на коротких итерациях: сначала создается тест, затем реализуется минимальный код для его прохождения, после чего код рефакторится. Утверждается, что такой подход помогает создавать надежное и поддерживаемое программное обеспечение, снижая вероятность ошибок и улучшая архитектуру кода.

Автор: Хуссем Маатали (Houssem Maatali)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

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

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

Автор: Томаш Балог (Tamás Balog)
Оригинал статьи
Перевод: Ольга Алифанова

Тестировщики, скорее всего, знакомы с понятием тест-пирамиды: юнит- и компонентные тесты, различные уровни интеграционных тестов, и все остальное.

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

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

Начинаем

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

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

Здесь и далее я буду употреблять именно слово “тестировщик”, так как согласен с мнением, высказанным в книге “Agile Testing”, что в попытке называть специалистов QС или QA больше желания уйти от негативных ассоциаций низкоквалифицированной должности, чем реальных расширений компетенций. Тем не менее тестировщик в agile, как правило, более t-shaped и оказывает влияние на весь процесс разработки ПО. О выделенных ролях QC и QA, не занимающихся непосредственно тестированием, речи мы не ведем.

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