Как быть, когда вокруг вроде бы девопсы, аджайлы и скрамы, но разработка и тестирование по-прежнему не живут в одном пайплайне душа в душу?

Из-за того, что необходимо преодолевать эту стену и находить общий язык, мы даже создали конференцию Heisenbug, предназначенную одновременно для тестировщиков и разработчиков. А ещё мы проводим Java-конференции, и осенью Артём Ерошенко выступил там с докладом «Как правильно (не) использовать тестировщиков». На примере Java-проекта он поделился своей болью и рассказал, что считает нужным делать.

И теперь, в преддверии нового Heisenbug и нового JPoint (обе конференции пройдут в формате «офлайн + онлайн»), мы решили сделать хабрапост на основе его доклада. Дальше повествование от имени Артёма.

A tester is one of the most stressful roles in IT. You constantly need to be concentrated and report bugs to developers in your team. Lidiya Yegorova, Innotech’s “Scoring conveyor” team QA-Lead shared her practices on how to minimize the stress while testing.

В 2019-2020 годах на одном из проектов я был идейным вдохновителем перехода на JUnit 5. Для проверок мы использовали стандартные ассерты и Hamcrest. Тогда мне казалось, что этого более чем достаточно.

За последние пару лет, несмотря на менеджерскую позицию, я написал свыше пятисот тестов, и мой подход к тестированию претерпел значительные изменения. В этой статье я постараюсь объяснить, почему AssertJ — это лучшее решение для проверок в тестах, существующее сегодня (год 2022 от Р.X.). Разумеется, всё ниже сказанное — это моё субъективное мнение.

Привет всем!

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

P.S. Если автор что-то не разобрал и не написал, значит он посчитал это не обязательным в рамках этой статьи))) 

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

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

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

За пятнадцать лет работы в тестировании я наблюдаю, как отрасль из простой и незрелой, ориентированной на начинающих айтишников, становится профессиональным направлением. Раньше тест-менеджер должен был распределять задачи между тестировщиками и следить, чтобы они тестировали разные области, не повторяя одно и то же - такая вот “высокоинтеллектуальная управленческая задача”. Со временем в тестировании появилась узкая специализация, и теперь тестировщики решают разные задачи. Кто-то занимается тест-анализами и тест-дизайном, кто-то автоматизирует тесты, кто-то проводит ручное тестирование как по готовым скриптам, так и в свободном поиске, используя множество инструментов исследовательского тестирования. Соответственно, роль тест-менеджера также поменялась. Теперь он не просто распределяет задачи, а организует процесс, выделяет необходимые задачи для решения, объединяет людей с абсолютно разной квалификацией и целями, чтобы на выходе получить прекрасный результат. И тут, внимание, вопрос: а что же такое прекрасный результат в тестировании? 

Привет, Хабр. В этой статье я кратко расскажу о деталях реализации микросервисной архитектуры с использованием инструментов, которые предоставляет Spring Cloud на примере простого концепт-пруф приложения.

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

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

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

Становится понятно, что важность тестирования API очевидна. Некоторые методологии и ресурсы помогают нам узнать КАК тестировать API - вы можете использовать ручное тестирование, автоматическое тестирование, тестовые среды, инструменты, библиотеки и фреймворки. Однако, независимо от того, чем вы будете пользоваться - Postman, supertest, pytest, JMeter, mocha, Jasmine, RestAssured или любыми другими инструментами - прежде чем открывать любой инструмент тестирования, вам необходимо определить, что тестировать...

В предыдущей статье я рассказал о подготовке данных для тестирования, что данные лучше генерировать, а не клонировать. Теперь стоит подробно разобрать, как их генерировать. Есть несколько подходов к генерации данных: c SQL, Python, сериализацией. У всех из них есть свои плюсы, минусы и особенности, которые стоит учитывать.

Система сборки проектов Gradle стала значительной вехой в эволюции инструментов подготовки артефактов и заменила во многих проектах ранее популярный Maven (который ранее стал заменой для make и ant). Де-факто Gradle является стандартом для сборки проектов для Android, но в действительности он может использоваться и для других целевых платформ и технологий разработки, отличных от JVM. Подобно maven в gradle используются устанавливаемые дополнения, которые могут добавлять свои цели и элементы конфигурации, а также встраиваться в существующие цели и добавлять операции как и исходными текстами (например, форматирование), так и с вспомогательными объектами (как пример можно привести кодогенерацию), а также вызов внешних команд или объектов классов (например, компилятора kotlin или инструментов сборки ресурсов для android).

В этой статье мы пошагово создадим и протестируем простой plugin трансформации текстовых файлов для gradle (при разработке будем в основном использовать API, который поддерживается версиями 6.0+, но отдельно отметим, какие функции поддерживаются только в Gradle 7.0 и более новых).

Сначала начнем с определения контекста. Сборка любого проекта состоит из последовательности действий (actions), которые в конечном счете приводят к появлению целевого состояния (task). Конфигурация сборки описывается в виде gradle-сценария, который может взаимодействовать с методами, импортированными из plugin'ов или входящих в gradle-core, либо с версии Gradle 4.0 с использованием Kotlin Scripting (.kts) с возможностью использования объектов стандартной библиотеки Kotlin и импортируемых библиотек.

Парадигмы программирования

• инструкция (императивное программирование, FORTRAN/C/PHP),
• функция (функциональное программирование, Haskell/Lisp/F#/Scala),
• прототип (прототипное программирование, JavaScript),
• объект (объектно-ориентированное программирование, С++/Java),
• факт (логическое программирование, PROLOG).

Создатели инструментов заявляют о 1000-кратном увеличении производительности. Альтернативный взгляд и несколько важных советов при изучении применения инструментов автоматизации тестирования AI/ML.

Невероятно оптимистичные заявления о преимуществах AI/ML инструментов автоматизации трудно игнорировать: пишите автоматические тесты в 3 раза быстрее! На 90% дешевле! Получите повышение производительности в 1000 раз! (да, в тысячу)

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

Как добиться необходимого контроля, удобства и даже скорости при подготовке тестовых данных для микросервисов и тестов производительности? В каких случаях лучше не генерировать XML и JSON файлы с помощью конкатенации строк? Зачем анализировать статистику по SQL запросам?

Меня зовут Вячеслав Смирнов, и я ускоряю дистанционное банковское обслуживание юридических лиц, а еще поддерживаю чат QA — Load & Performance в Телеграм, где сообщество инженеров по тестированию производительности обсуждает тестирование нагрузки.

Статья получилась длинной, поэтому сегодня я расскажу про подготовку тестовых данных для тестирования производительности и про то, как с помощью SQL, Pandas и Java эти данные готовить. Поговорим про анализ метрик и логов с точки зрения данных и с использованием InfluxDB, Grafana и прочих инструментов, А ещё о том, как может выглядеть хороший отчет по системе, в которой много данных. В следующих частях перейду к генерации и анализу тестовых данных для нагрузки.