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

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

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

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

Современные проекты требуют современных подходов к обеспечению качества. В этом докладе, Адриан познакомит публику с методами обеспечения качества на основе таких инструментов и технологий, как CucumberStudio, GraphQL и SonarCloud. Также он представит лучшие практики BDD и мониторинга (DataDog).

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

Юнит тестирование — одна из самых неоднозначных методик нашей индустрии. Одни считают её незаменимой, а для других она пустая трата времени, сил и ресурсов. Как так получилось, что один и тот же процесс приводит к таким противоположным результатам и выводам? Все дело в том, что юнит тестирование, как и любой другой инструмент, может принести как пользу, так и плачевные последствия, при неверном или небрежном использовании.

Каких бы размеров ни были ваши кубирнейтесы, в которых вы поднимаете сотни докер контейнеров для прогона селениуем тестов, сколько бы сотен тестов вы бы ни запускали в минуту – не стоит забывать об одной неприятной особенности селением тестов – хрупкости. Сейчас существует огромное кол-во способов борьбы с флаки тестами, начиная от использования фреймворков, позволяющих писать достаточно стабильные тесты и не стрелять себе в ноги, заканчивая инструментами, позволяющими “на лету” в ходе теста изменять элементы, позволяя тесту проходить.

Бывает, что после простого изменения, неожиданно проваливаются 50+ испытаний. Нестабильные тесты, которые зависят от специфики GUI и приводят в результате к ошибке NoSuchElementException – это основная проблема при тестировании с помощью Selenium. Повторная проверка проекта с открытым кодом представляет собой простое и элегантное решение.

За последние десятилетия AI проникает в самые обычные вещи. Телефон распознаёт лица и выполняет голосовые команды. Автомобиль может самостоятельно двигаться в потоке или припарковаться. Гражданская авиация не представляется без систем, принимающих критические решения, исключая человеческий фактор.