The logic of verification

Software testing is sometimes described as «verification and validation» —according to Wikipedia «the process of checking that a software system meets specifications and that it fulfills its intended purpose». Yet, if we examine the concept and logic of verification, we quickly recognize that there are serious limitations to what can and cannot be checked and verified. This is not to say that checking is a bad thing — on the contrary; checking can be very valuable. Still, it’s important for testers and their clients to recognize the fundamental limitations of checking, and to address those limitations in our testing strategies.

In this talk, Michael Bolton will outline the logic of verification and ways in which we might be vulnerable to false premises and misleading conclusions about it. He’ll also identify ways that we can address those problems by embedding verification in a larger system of testing, experimentation and critical thinking.

Tester, consultant, and trainer Michael Bolton is the co-author (with James Bach) of Rapid Software Testing, a course that presents a methodology and mindset for testing software expertly in uncertain conditions and under extreme time pressure. Michael is a leader in the context-driven software testing movement with twenty years of experience testing, developing, managing, and writing about software. Currently, he leads DevelopSense, a Toronto-based consultancy. Prior to DevelopSense, Michael was with Quarterdeck Corporation. Michael's home page is www.developsense.com.

Проблемы тестирования блокчейна и способы их решения на примере блокчейн-платформы Waves

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

Занимается тестированием более 10 лет. Создавал отделы тестирования и руководил ими в ИТ-компаниях, в том числе в компании ИТАР-ТАСС. Проводил тестирование десктопных, мобильных и веб-приложений.
Разработал несколько фреймворков для автоматизации тестирования — фронта и бекэнда.
Обладает обширным практическим опытом применения различных средств автоматизации тестирования.
С июля 2017 года работает в компании Waves.

Автоматизированное тестирование унаследованного кода: приемы безопасного рефакторинга

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

Как же быть в подобной ситуации нам — разработчикам, ценящим качество и надежность продукта, когда требуется в короткие сроки внести изменения в унаследованный код, для которого нет тестов?

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

Доклад продемонстрирует примеры из мира С++, но будет актуален и для других языков программирования.

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

Test your Java applications with Spock

Remember the old days when you tested using JUnit? How boring it was? You made a lot of excuses to avoid testing your code. Luckily those dark days now belong to the past because Spock is with us.

Spock is a Groovy-based testing and specification framework for Java and Groovy applications that makes writing tests fun again. We can write beautiful and highly expressive tests because of its DSL and all the power that Groovy provides us.

In this live-coding session, you'll learn the basics of Spock and you'll see how easily you can test a Java application. After the talk you won't have any excuse not to test your applications, so you have been warned before coming to the talk!

Ivan is a Software Engineer and Systems Administrator with 14 years of experience. He is a member of the Grails team at Object Computing, Inc. (OCI). He discovered Grails 8 years ago and since then he develops almost exclusively using Groovy. He is the creator of some Grails plugins like PostgreSQL-Extensions and Slug-Generator.

He's also the coordinator of the Madrid Groovy User Group (@madridgug), the organizer of the Greach Conference (http://greachconf.com) and a frequent speaker at conferences like SpringOne 2GX, GR8Conf, Greach, Codemotion, GeeCon, Spring IO, RigaDevDays, JavaCro, and so forth.

Fuzzing-тестирование: ищем баги в JIT-компиляторе и не только

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

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

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

Инженер компиляторов в Azul Systems. Последние 4 года занимается оптимизирующими JIT-компиляторами для виртуальных машин. С 2017 года работает над Zing VM, активно коммитит в LLVM. До этого работал над виртуальными машинами ART и Dalvik в компании Intel, внёс свой вклад в Android Open Source Project.

Testing in the modular world

The Java Platform Module System (JPMS) introduced with Java 9 poses new challenges when it comes to organizing and executing automated software tests.
Finding tests and executing them via the Reflection API is still possible but needs some extra configuration.
JUnit 5 supports scanning for tests in modules since 5.1 and has a sample project that demonstrates three possible approaches.
Sources are available at: github.com/junit-team/junit5-samples/tree/master/junit5-modular-world

I'll start the talk with a basic introduction to JUnit 5 and the JPMS.
The remainder of the talk will be spent on presenting the three approaches for executing tests when using the JPMS from the command line:

• Resorting to the --class-path
• Patching test binaries into main modules at runtime
• Patching main sources into test modules at compile time

Future work and outlook:

• Variations or other approaches?
• How do build tools support you?
• What are best practices in IDEs?

Happy modular testing!

Christian is an Open Source Software Developer who is programming with Java since 1996. He has a faible for automated testing and joined the core JUnit 5 team in 2017.
He is living in Bonn, Germany and works for MICROMATA GmbH.

Scaling approaches with 0 to 40 hours of tests

Challenges in mobile test automation (Android, iOS and mobile web) are quite different from desktop web. Applications are developed with different technologies on different languages and different platforms. You need a strategy while picking the tools for mobile test automation. It is important to understand what you want to achieve with it and how to show the value to your stakeholders. Having automation tests doesn't mean anything by itself. Speed and stability of your tests are necessary to build the trust between the developers and QA. While we want to see a pyramid structure in testing — unit tests, integration tests, etc — end-to-end tests are not merely the pointy bit at the top, but are the bridge between client and server pyramids.

Badoo delivers Android and iOS applications once in a week and mobile web twice per day. While the product is continuously pushing for the features and teams got scaled over the last two years, how do we start working with developers and manual QA and keep being a part of its delivery process?

Sathish works as Mobile QA Automation Lead at Badoo. Since 2013, he is responsible for developing test automation solutions for mobile applications at Badoo. He has 13 years of experience and has worked in various positions from a software developer to a technical lead. He strongly believes the true success of the test automation lies when it is integral part of the product delivery process and meets the needs of it's stakeholders.

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

В Badoo мы прогоняем более 1200 end-to-end тестов для наших iOS-приложений в один прогон. Это более 40 часов тестов, которые проходят за 45 реальных минут.
В докладе расскажем, как мы распутали тесно связанные тесты и инфраструктуру iOS и перешли к серверу устройств; как это упростило параллельный запуск тестов и сделало наши тесты и инфраструктуру проще для поддержки и масштабирования.
Из доклада вы узнаете, как легко запускать тесты параллельно с помощью таких инструментов, как fbsimctl, и как разделение тестов и инфраструктуры может упростить принятие, поддержку и масштабирование ваших тестов.

Занимается автоматизацией тестирования в Badoo с фокусом на инструментах и инфраструктуре iOS.
До этого работал 3 года в 2ГИС, разрабатывая в основном внутренние инструменты, включая систему непрерывного тестирования пакетов данных и open source-реализацию WebDriver для автоматизации тестирования под Windows Phone.

Вы всё еще пилите свой отчет? Тогда мы идем к вам!

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

Доклад будет одинаково интересен как тем, кто незнаком с Allure-отчетом, так и активным пользователям. Мы добавили довольно много новых фич. Приходите, будет интересно!

Более 8 лет занимается автоматизацией тестирования веб-приложений. За это время работал в разных командах и в разных ролях: автоматизатор тестирования, менеджер команды разработки инструментов тестирования, руководитель группы автоматизации тестирования. Артем имеет большой опыт работы с популярными инструментами (Selenium, HtmlElements, Allure, Jenkins). Программирует в основном на Java, Groovy.

Как разработчику научиться строить тестовую пирамиду

Мы слышим ото всюду о том, как важно строить пирамиды, чтобы тестирование стало быстрым, простым, надежным. Но почему никто этого не делает? Мы обсудим:

• Какие из тестов на каком уровне стоит писать, чтобы построить пирамиду;
• Как создавать несколько пирамид, учитывая, что многие проекты сегодня фактически состоят из двух подпроектов: backend & UI;
• Какой должна быть архитектура приложения, чтобы позволять писать больше низкоуровневых тестов;
• Какие моки помогают, а какие мешают выстроить качественное тестирование.

Доклад ориентирован на разработчиков и руководителей проектов.

Разрабатывает с 2008-го, в основном на Java. Всегда тяготел к тестированию и качеству кода. В какой-то момент начал увлекаться оптимизацией процессов и в 2013 переключился на CI/CD активности. Никогда полностью не был доволен работой AQA и поэтому в 2015 ушёл в тестирование, чтобы доказать, что всё можно делать намного лучше. Доказал и ушёл в бизнес-анализ.

More effective testinge

Tools, approaches and techniques to help you be more effective.

We all test software to varying degrees for both software we create and software we use. There are many reasons we test: some test 'full-time' and may be called testers, others test to check their work or the work of others.

Software testing ranges from «monkey see, monkey do» and «do-as-you're told», to «certified testers», versus self-declared artists and practitioners. There's little feedback and few effective tools to help us make better decisions and receive feedback about the testing we are doing and what would be good to do next. Software testing doesn't need to be this way: this presentation provides examples of tools, approaches and techniques we can use to be more effective and improve our practices through data and evidence.

Looking beyond our immediate vista, to other domains such as medicine, can provide useful, fresh insights and enable us to improve our craft and our products.

«Put everything to the test. Accept what is good.» Thessalonians 5:21

Julian's been actively involved in many aspects of testing and development of mobile apps globally, since 2006. This includes roles at Google, eBay, etc as well as contributions to open source apps (such as Kiwix for Wikipedia) and test automation including Selenium and several test automation frameworks for mobile apps. He's contributed to the highly successful Mobile Developer's Guide to the Galaxy, co-authored the Mobile Analytics Playbook, and wrote perhaps the first book on test automation for mobile apps. Currently he's studying a PhD part-time to find ways to improve the testing and development of mobile apps using mobile analytics in addition to the other bits and pieces.

JUnit, дай пять! Переносим код в JUnit Extensions

JUnit 5 — полностью новый фреймворк, первый релиз-кандидат которого выпущен менее года назад. Имя JUnit обязывает ко многому, так как он является самым популярным решением для написания тестов в Java-мире, свежую версию которого ждали более трех лет.

Что же мы получили? Полностью новую кодовую базу, архитектуру и API, в сочетании с простотой и выразительностью предыдущей версии.

Процесс миграции с версии 4 прост — вы можете ограничиться исключительно заменой аннотаций.
Но мы в PropellerAds, при переходе на JUnit 5, постарались ответить на вопрос: как использовать новые API для того, чтобы изменить наши тесты к лучшему?

Итак,

• если ваши функциональные тесты написаны в стиле AAA (Arrange – Act – Assert), и секция подготовки данных сложнее, чем Calculator calculator = new Calculator();
• если вы пишете тесты на «сложные» веб-проекты, такие как: интернет-банки, системы документооборота, CRM и т.д., а также создаете большое число «доменных» объектов ради простого тест-кейса;
• если вы хотите реализовать действительно простые API для того, чтобы любой новичок мог расширять тестовое покрытие в вашем проекте, не испытывая шока при виде класса с тестами,

то этот доклад именно для вас! На реальных примерах расскажем, как мы не ограничились простой заменой аннотаций и избавились от первой «А» в аббревиатуре AAA.

Работает в IT 10 лет. Начинал в аналитике, затем управлял проектами в роли Project Manager, но тяга к прекрасному победила, и несколько лет назад Дмитрий сконцентрировался на разработке и автоматизации тестирования на Java.

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

Верит в то, что «простые» тесты могут быть написаны для сколь угодно сложных систем, и считает, что автоматизация тестирования не менее увлекательна, чем разработка.

Делаем CI для мобильного SDK с нуля

В конце 2017 года наша команда начала работу над новым мобильным SDK, используя как самые последние опенсорс-технологии, так и самые последние внутренние разработки. И конечно мы хотели исправить и те недочеты, которые видели в CI наших предыдущих продуктов.

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

Список ключевых слов: Jenkins, AWS, Serverless, Docker, Mac mini, git, repo, Gerrit, Java, Go

Начинал с веб-приложений, затем перешел на бэкенд. Сейчас в основном работает над CI, инфраструктурой и автоматизацией. Пользователь AWS с 2010 года. Гофер с 2015 года. Контрибьютор в опенсорс-проекты. Ярый сторонник точки зрения, что тестирование сейчас — это не про поиск багов, а про увеличение качества, скорости и продуктивности.

How to improve CI/CD pipeline for mobile test automation

In this talk, Niranjani will discuss how containers can simplify the many different flavors of mobile app builds, how to utilize parallelization to speed up build and test execution time, and how the choice of a CI system can improve the efficiency of the entire CI/CD pipeline. She’ll be citing examples from her experience in the Android world via a problem/solution based approach which will be helpful for the audience to understand and apply to other platforms.

Key takeaways:

• Learn how containers can simplify your build process.
• A problem/solution approach to addressing the common test automation issues while trying to improve CI/CD pipeline.
• Caveats of different CI systems.

Niranjani is a Senior Software Engineer in Test at Pinterest. She is responsible for developing test automation solutions for the Android platform. She has 8 years of experience and has worked at companies like eBay and Twitter in a similar role. She’s passionate about code and product quality and gets involved in efforts to improve the CI/CD pipeline.

Краудсорсинг в тестировании

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

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

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

В докладе мы расскажем:

• как удалось сделать задачи ручного тестирования максимально формализованными и обучить им сотни удаленных сотрудников;
• как удалось поставить процесс на промышленные рельсы, обеспечить тестирование в различных окружениях, выдерживать SLA по скорости и качеству;
• с какими трудностями мы сталкивались и как их решали (а некоторые еще не решили);
• какой вклад внесло тестирование асессорами в развитие продуктов Яндекса, как оно сказалось на частоте релизов и количестве пропускаемых багов.

Руководитель краудсорсинговой платформы Толока и управления экспертных оценок Яндекса.

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

Область интересов — математика в мире экспертных оценок, автор докладов и статей по этой теме.

Есть ли автотестирование в играх?

Доклад посвящен вопросам использования штатного инструментария Appium и графов игровых сцен для реализации автоматизированного тестирования. На живых примерах покажем, как это работает в компании Zeptolab и как полученный нами опыт можно использовать в других проектах.

QA в GameDev уже шесть с половиной лет. Начал свой профессиональный путь в компании Gaijin Entertainment, после неё успел поработать в таких крупных игровых компаниях, как Glu Mobile, Crazy Panda, а также в нескольких стартапах. В данный момент занимает позицию QA-лида в компании Zeptolab.

Специалист в области IT. Работал в таких крупных IT-компаниях, как IBM, Dors, Paragon Software. Прошел путь от системного администратора до Product Owner. В настоящий момент работает на позиции QA Manager в компании Zeptolab и занимается внедрением инновационных решений.

Тестирование на основе сетей Петри

Что делать, когда тесты принципиально не способны находить ошибки, возникающие при необычных состояниях тестируемой системы, обычно называемые «edge cases»? Можно ли увеличить тестовое покрытие и находить больше ошибок, не создавая излишних тестов и не жертвуя временем их выполнения?

В этом докладе мы поговорим о том, как мы столкнулись с этой проблемой в Toptal, начали переход от обычных тестов к тестированию на основе моделей, какие проблемы встретили на этом пути, почему мы используем сети Петри вместо конечных автоматов и что у нас получилось в итоге. Доклад будет проиллюстрирован примерами сетей Петри и множеством Ruby кода.

Занимается тестированием больше 11 лет, из них последние 5 лет помогает улучшать качество в Toptal, крупнейшем в мире распределенном сообществе высококлассных специалистов. Контрибьютор Mozilla. Разработчик Watir. Коммитер Selenium, где отвечает за Ruby часть.

Web security testing starter kit

В докладе расскажем о несложном порядке действий, которые позволят сделать веб-приложение безопаснее.

Расскажем, как искать уязвимости, какие угрозы для пользователей и сервиса они несут.

Подробнее остановимся на самых распространённых: XSS, SSRF, SQL injection, IDOR, CSRF, Misconfiguration (ex: CORS), XXE.

Расскажем об инструменте (Burp Suite), который позволит облегчить процесс поиска уязвимостей.

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

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

Последние десять лет занимается поиском уязвимостей в веб-приложениях. Участник многих Bug Bounty-программ. Больше всего любит ошибки бизнес-логики, когда программа работает так, как написано, а не так, как хотел программист. В компании SEMrush работает в команде безопасности, отвечающей за безопасность продукта и рабочей инфраструктуры и многое другое.

Десять миллионов тестов в день

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

Тимлид QA/Release команды в Azul Systems, отвечающей за Zulu OpenJDK. До этого долгое время проработал в Oracle, где занимался QA JavaFX и Java2D. Любит делиться своим опытом на конференциях и stackoverflow.com

Android Production Level Test Driven Development And What's new

8/10 developers don’t really know how to test their apps and write testable code. From practically writing code to test genuine production level scenarios with different approaches to incredibly optimising your tests cases, we will also see what’s new in Android Test Support Library 1.0 and how to test on multiple devices.

-> Important Testing GuideLines

-> Espresso and Robolectric (In and Out ,Crisp and To the point)

-> Making Code highly Testable using MVVM, Repository Pattern and Data binding and Dagger 2

->Genuine production level Scenarios Testing Demoes :-

-> Common mistakes made by developers resulting in inefficient test driven development which leads to de-prioritisation of TDD :( :( .

-> Will be showing This with the following three approaches using Dagger 2:
a.) Using Robolectric (JVM based without needing a device or emulator)
b.) Using Espresso (Unit Instrumentation Tests)
c.) Testing the ViewModel (Purely JVM based)

-> Performance Analysis of these testing techniques; which one to choose and when

-> Testing on Multiple Devices

-> Espresso 3.0 New Features

-> New Features Of AndroidJUnitRunner

-> Lots and Lots of Code Snippets

Target Audience And TakeAways:-
This talk would be highly beneficial to people at all levels of expertise in the following ways :-

Beginner :- As I'll be covering TDD from scratch, how to write testable code, mistakes which people make when starting TDD, beginners from very start, would get into a habit of writing high quality code which is configurable, testable and highly maintainable.

Intermediate :- As the talk would be covering topics like Different patterns to write testable code, genuine production level scenarios,
different approaches to test apps and different frameworks, intermediate developers would get a direction as to how they can further shape their TDD.

Advance: People with advance testing skills would be able find out what's new is there for them. With topics like new «Features of Espresso 3.0» and «AndroidJUnitRunner» and what all options are available to test on multiple devices, they can add more efficiency to their Test Driven Development.

Kapil Bakshi is a very passionate techie with an aim to embrace technology, imbibe every bit of it, transcend all the barriers and turn ideas into reality. His experience spans across edtech, fintech and logistics sectors where he has developed things from scratch taking them to a level where they have scaled drastically and have become a brand in their respective domains.

He is currently working at BlackBuck which is redefining the logistics landscape of India, making it reliable and efficient. Kapil is playing an important role there to improve quality of all apps, doing optimisations and helping the company scale to go much beyond.

Apart from Android, he has worked on Backend technologies as well and many times single-handedly built complex features which have proven to be very beneficial for business.

In Android, his areas of interest include testing, architectural best practices and security.

He has spoken on emerging android technologies at Google Devfest India, Google Developer Days Extended Mumbai and other conferences in India and has got an overwhelmingly amazing response.

Kapil has also given talks on architectural best practices and testing and has been invited to speak at International Conferences like Droidcon Beijing 2017, DroidKaigi Tokyo 2018 and Android Makers France 2018.

Enterprise Automation with Selenium and why it has very little to do with Selenium

As Selenium is becoming a W3C standard, more and more organizations are moving to Selenium as their GUI automation tool. Most teams focus on writing tests and tackling issues via Selenium itself.

However, in our experience Selenium is usually the smallest «problem» in getting an enterprise ready test automation solution off the ground. This talk shows cases with many practical examples how test automation with Selenium boils down to being a full-blown software project, that needs to be treated and staffed as such. It will show the major pitfalls that prevent teams to build a scalable and reliable automation solution with the Selenium tool family. And it will show how to apply a lean approach in making test automation with Selenium a full success.

Founder and CEO of Element34 Solutions. Co-developed Selenium Grid. Ex-eBay Head of Quality Engineering. For more than 10 years Michael Palotas shaped software and test engineering at eBay International as the Head of Quality Engineering. He was key responsible for leading the transformation for eBay International from a waterfall to a highly agile organization employing new paths and approaches especially in the field of engineering practices. Before joining eBay, Michael held lead roles in companies like Ericsson, Nortel Networks, Intel.

Тестирование конфигурации для Java-разработчиков: практический опыт

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

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

Разрабатывает на Java более 10 лет. В юности программировал всякое-разное за еду и мобильный телефон, позже создавал обучающие программы для школьников в 1С и симулятор рекламных стратегий в Яндексе, а сейчас занимается генерацией цен в Deutsche Bank. Как настоящий профессионал, предпочитает сразу писать код без багов, но иногда подогревает свою самоуверенность тестами.

Shipping is a risky business

Businesses don’t write and release software for the fun of it. They write code to meet business needs. Of course, no software is without bugs, and no process is without edge cases, missed opportunities, and the normal sprinkling of errors. This means that each release is the result of a risk assessment that has determined that the risks of release outweigh the costs of failure to push to production. Because we’re human, that assessment is coloured not just by the fear of risk.

Canary releases, feature toggles, vigilant monitoring, and clearly defined rollback procedures are all technical approaches to mitigating this risk, but what else can we do? In particular, what can testers contribute over the lifetime of the project to keep the risk as low as possible? Over the course of this talk, we’ll recast the software development lifecycle as a conversation about risk. We’ll discuss the position of testers in a team, the role of testing, and the place that automation has in the conversation that is software development as a mechanism for assuaging the fear of risk.

Simon Stewart is the creator of WebDriver, the Open Source browser automation tool, and is the Selenium project lead. He previously led the build tool team at Facebook, developing the graph-based build tool Buck, and being a strong advocate of monorepos. Before joining Facebook, he spent almost five years at Google, and three at ThoughtWorks. He’s seen a lot of code.

Simon has an interest in byte-for-byte reproducible builds at incredible speed, and describes himself as "undeniably hairy".

Системы статического анализа кода: трудности выбора

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

Но даже код, покрытие которого близко к 100%, может и, как правило, содержит в себе ещё массу ошибок, отловить которые не под силу ни разработчику, ни тестировщику. Связано это с тем, что автотесты и функциональное тестирование не могут выявить большое количество специфических проблем, таких как, например, взаимная блокировка потоков или состояние гонки, связанных с ошибками проектирования многопоточных систем.

Поэтому на борьбу с багами выходят относительно новые типы ПО под общим названием SAST — системы статического анализа исходного кода. Сложность этих систем достаточно высока, учитывая их специфику. Из этого вытекает их высокая стоимость. Кроме того, интеграция такой системы в цикл разработки — дело отнюдь не простое, поэтому от её выбора напрямую зависит, вырастет ли эффективность работы технических отделов или же наоборот, она станет ненужной обузой или дорогой игрушкой.

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

Don't repeat yourself: UI-тесты для веб, iOS и Android одновременно

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

Давайте посмотрим, как на основе open source-решений можно быстро организовать E2E-тесты, которые заработают и в вебе, и в мобильных приложениях, а также какие сложности возникнут с подобным решением. Подход будет продемонстрирован на Python-стеке, но может быть легко перенесен на другой стек.
#python #web #mobile

Последний год Игорь занимается автоматизированным тестированием в стартапе Uptick. В основном пишет тесты на Python для UI (Web + Mobile) и API (REST + GraphQL) и немного на .NET (Component и Integration-тесты). До этого работал в Новых облачных технологиях, где получил опыт написания и поддержки более тысячи веб-тестов на Ruby, Watir, Cucumber.

Testers as their own worst enemies

Sometimes, in some organizations, testers complain that they're not respected or acknowledged. Project management views testers as obstacles to timely releases; developers see testers as uninformed and technically ignorant pests. Testers themselves step into professional and interpersonal tar pits by misunderstanding the role of the tester, the mission of testing, and the skills required to get the job done.

In this session, Michael Bolton will talk about several ways in which testers undermine their own reputations and the image of the testing profession. He will provide reframes and antidotes to help testers identify and resolve those problems, and he'll point the way towards developing technical skills, socials skills, and most importantly thinking skills that can build respect for testing and increase testers’ effectiveness.

Tester, consultant, and trainer Michael Bolton is the co-author (with James Bach) of Rapid Software Testing, a course that presents a methodology and mindset for testing software expertly in uncertain conditions and under extreme time pressure. Michael is a leader in the context-driven software testing movement with twenty years of experience testing, developing, managing, and writing about software. Currently, he leads DevelopSense, a Toronto-based consultancy. Prior to DevelopSense, Michael was with Quarterdeck Corporation. Michael's home page is www.developsense.com.

Atlas — ваш новый путеводитель по PageObject

Как понять, что индустрия развивается? В ней появляются всё новые и новые решения.
Сегодня существует много инструментов для автоматизации тестирования UI. Наиболее популярные для Java — это Selenide, JDI, Serenity BDD и HtmlElements. Каждый из них идёт своим путём, имеет свои плюсы и минусы.

Исторически на своих проектах мы использовали HtmlElements, но они сильно устарели. Полтора года назад узнали от разработчика HtmlElements о существовании новой версии. Дальше мы стали развивать проект вместе и создали новый фреймворк для работы с PageObject — Atlas (Application Test Layout).

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

Доклад будет полезен как старым пользователям HtmlElements, так и новым людям, которые находятся в поисках фреймворка для тестирования.

Больше шести лет в тестировании. Начинал с ручного тестировщика браузерных игр и постепенно стал задумываться об автоматизации, поэтому следующим местом работы выбрал Яндекс, где работает до сих пор. За это время несколько раз менял проекты и задачи. Имеет большой опыт в написании API и UI-тестов на Java.

Бета-тестирование ВКонтакте

Рассказ о бета-тестировании ВКонтакте: с чего всё начиналось и при чём тут Джеймс Бах, как мы тестируем масштабные обновления и совершенно новые продукты и какой инструментарий используем.

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

Родилась в Киеве, училась в ИТМО на кафедре БИТ. Выпускник программы Game|Changers. Работала в Йота Лаб, «Корус Консалтинг», i-Free и Documatic. В 2014 году присоединилась к команде ВКонтакте в качестве тестировщика. С 2016 года руководит тестированием ВКонтакте и развивает программу бета-тестирования VK Testers.

Тестируем до последнего: Smart Responsive Interface Design Patterns

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

Внимание! Возможно, вы не сможете забыть всё то, чему вы научитесь во время доклада.

Виталий Фридман любит красивый контент и никогда просто так не сдаётся. Родом из Минска, Беларусь, Виталий изучал информатику и математику в Германии, где обнаружил интерес к типографии, письму и дизайну. Проработав в качестве фрилансера дизайнером и разработчиком в течение шести лет, он основал Smashing Magazine, один из ведущих онлайн-журналов о дизайне и веб-разработке. Виталий — автор, соавтор и редактор всех Smashing Books. В настоящее время занимает позицию главного редактора Smashing Magazine в прекрасном городе Фрайбург, Германия.

Вспомогательные приемы при тестировании микросервисов

Тестирование микросервисов привносит много интересных и новых задач. Речь пойдет о проблемах генерации, загрузки и очистки тестовых данных; о поддержке множества HTTP-клиентов и проверке того, что весь кластер микросервисов готов к тестированию в начале и в процессе прогона тестов. Доклад построен на модели «проблема-решение». #spring #cucumber #java

В индустрии разработки и тестирования с 2008 года, с некоторым перерывом на аспирантуру и эксперименты по ядерной физике. В тестировании работал с e-commerce платформами, IPTV системами и location-based сервисами. Занимался как поддержкой существующей тестовой архитектуры, так и построением автоматизации с нуля для backend, UI и мобильных приложений.
В данный момент работает в берлинской компании Signavio и строит автоматизацию для backend и UI.

The «C0MEDIES» of testing in the cloud age

Testing an application that lives in the cloud requires the same tricks and techniques as one that resides on your own iron. But when testing something that is going to live in the cloud, you need to test not just the user-facing functionality, but all the things that make it «cloud». In fact, it could be argued that the ensuring the cloud-ness of your application is almost more important than the user-facing part as re-architecting for the cloud problems will absolutely cause re-testing.

In the illustrious tradition of heuristics and mnemonics, Adam proposes that we add «C0MEDIES» to our vocabulary when testing an app that runs on a cloud-like environment. By dealing with the «C0MEDIES», you can manage the Chaos of the cloud, while doing 0 downtime deploys, for applications that at Monitored, are Elastic, in an infrastructure that is constantly being Developed, is Idempotent, Efficient and Secure.

Automator of things that should be automated, doer of things that should not. Efficient, not lazy. Jack of all trades, master of a couple. Brought Selenium-IDE back from the dead once, and has been apologizing ever since. Roller Derby referee, not player (that's crazy!).