t.me/atinfo_chat Telegram группа по автоматизации тестирования

Видео докладов с seleniumcamp 2020 [часть 2]: AspectJ, мобильная автоматизация, Code Coverage, Test Coverage, SDET, Drill4J, статический анализ.

Теги: #<Tag:0x00007f749769bd48> #<Tag:0x00007f749769bc80> #<Tag:0x00007f749769bbb8> #<Tag:0x00007f749769baf0> #<Tag:0x00007f749769ba28> #<Tag:0x00007f749769b960> #<Tag:0x00007f749769b898>

Продолжение видео докладов с Selenium Camp

Ссылку на первую часть вы можете найти в конце страницы.

1. AspectJ в автоматизации (Maksym Barvinskyi, Ukraine) [UA]
AspectJ является де-факто стандартной реализацией Aspect-Oriented Programming (AOP) в Java. В этом выступлении мы познакомимся с этим инструментом, посмотрим, как он работает под капотом, и какие проблемы он может помочь вам решить в автоматизации тестирования. Например, наиболее выгодным его применением является возможность регистрации методов, вызываемых во время выполнения теста, без явного добавления команд регистрации. Мы увидим, как AspectJ используется в других инструментах и средах, таких как Allure и Spring, и какова цена волшебства. Конечно, будет демо.


2. Подводные камни автоматизации гибридных мобильных приложений с WebView (Елена Венхрова, Украина) [UA] (Olena Venhrova, Ukraine) [UA]
Я опишу основные проблемы, с которыми я столкнулся при настройке мобильной автоматизации в одном из проектов в EPAM, и способы их решения. Я надеюсь, что это поможет моей аудитории быстро запустить мобильную автоматизацию в своих проектах.


3. Молчание Code Coverage – время для тестирования тестов (Evgeny Mandrikov, France) [RU]
Модульные тесты являются опекунами для вашего кода, но «Quis custodiet ipsos custodes?» («Кто будет охранять самих охранников?»). Что делать, если показатели покрытия велики, но код все еще глючит? Пришло время проверить тесты! Приходите и откройте мутационные тесты


4. Миф о Test Coverage разрушен: карта Test-to-code и Test Impact Analytics (Сергей Пирогов, Украина) [RU]
Почему так важно знать магическое число 42 и почему мы его неправильно понимаем. В выступлении будут рассмотрены возможности сопоставления Test-to-code, которое является краеугольным камнем Test Impact Analytics и источником данных для Test Gap Analysis.
Новый инструмент, который может расширить повседневную деятельность по тестированию, и выделить идеи, которые помогут инженерам QA преуспеть в своих усилиях по тестированию.


5. Как стать SDET c 0 опытом в программировании (Vadym Rudenko, Ukraine) [RU]
Насколько технически должен быть инженер, что бы делать максимум в автоматизации? Крупнейшие компании отрасли имеют разные ответы на этот вопрос, и здесь, в Preply, мы внедрили некоторые решения, которые, по нашему мнению, могли бы работать на нас. В этой презентации я расскажу вам о наших результатах, полученных знаниях и проблемах, с которыми мы столкнулись. Эта информация будет полезна для тех, кто не останавливается только на автоматизации и всегда будет на впереди улучшения качества. Вы узнаете о новых возможностях и «новых тенденциях» по качеству delivery. Вы узнаете, как сотрудничать с разработчиками и помочь им обеспечить еще более высокое качество продукции, даже если вы находитесь в отпуске.


6. Анализ пробелов и минимизация наборов регрессии с Drill4J (Дмитрий Гуменюк, Беларусь) [RU]
Анализ пробелов в тестах - это процесс выявления пробелов, когда новый код был развернут, но еще не был протестирован. Однако часто ваш отдел тестирования не знает, какие части кода были изменены разработчиками. В результате тестеривщики запускают некоторые ненужные тесты, в то время как другие важные тесты игнорируются.
С помощью анализа пробелов в тестах мы можем найти пробелы и помочь вам избежать ошибок, допущенных в результате недавних, непроверенных изменений. При этом вы можете оптимизировать интерфейс между разработчиками и тестировщиками и избегать исправлений после выпуска системы.

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


7. Инструменты статического анализа как лучший друг QA (Николай Алименков, Украина) [RU]
Мы потратили много лет на тестирование наших приложений и систем вручную и с помощью средств автоматизации тестирования. За это время многие причины ошибок были классифицированы и могут быть обнаружены автоматически с помощью специальных инструментов статического анализа. Большинство из них могут быть применены на ранних стадиях разработки еще до того, как код будет интегрирован в основную ветку разработки. В этом выступлении я рассмотрю доступные решения и продемонстрирую, какие типы проблем могут быть обнаружены автоматически, что сокращает время и усилия, затрачиваемые на традиционное тестирование.


Первая часть докладов: