Ключевой доклад

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

Ключевой доклад

Задача тестера – проверить, что продукт готов к доставке заказчику, не так ли? Если вы так считаете, то у меня для вас плохие новости: вы не тестеры и ваша команда не понимает, что такое тестирование. И вы не одиноки. Большинство команд устроено именно так: тестеры заняты тем, что проверяют продукт перед выпуском и подтверждают, что дефектов в нем не обнаружено. Подобная организация работы ведет только к снижению качества, а не к его повышению. Постараюсь объяснить, что я имею в виду и показать на примерах

Ключевой доклад

Как и в фильме «Один дома», похоже, что Dev и Ops отправились в путешествие, и забыли взять тестирование/обеспечение качества с собой. Корпорации рассказывают истории о том, что у них нет тестировщиков, что все тесты проходят в еще на этапе разработки – полностью автоматизировано на уровне кода, и так далее. На самом деле, правда где-то рядом – между этими высказываниями!

Ключевой доклад

Краудтестинг включает в себя в основном обычных людей и тестировщиков, но в конечном итоге он – пользовательская база для вашего продукта – никакой усталости, недоразумений или людей, застрявших в мыслительном тупике. Более того, мы имеем дело с реальными устройствами – без программ-эмуляторов, без стерильных лабораторных условий. Вместо этого используются реальные мобильные сети и реальные настройки смартфонов. Если применять краудтестинг в сочетании с вашей стратегией тестирования, краудтестинг даст вам большую свободу и быструю обратную связь с пользователем. Никакой автоматизации не требуется!

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

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

Фирма 1С производит инструменты для быстрой разработки кросс-платформенных бизнес-приложений и рантайм для их работы. Бизнес-софт, разработанный на нашей платформе, работает на Windows, Linux, macOS, Android, iOS, использует СУБД MS SQL, Oracle, IBM DB2, PostgreSQL. Наш софт используется пятью миллионами конечных пользователей в полутора миллионах организаций.

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

DevOps – приоритетная задача для предприятий. Компании с развитыми системами расформировывают изолированные IT отделы и объединяют их в группы и отделы по разработке продуктов. Тестирование и методы тестирования лежат в самой основе этих изменений, поэтому компании нацеливаются на непрерывное тестирование в надежде облегчить прохождение «узких мест»…

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

Пора завершать использование только ручного труда для создания и выполнения тестов. Надо начинать применять богатые возможности, находящиеся в сферах Data Science, AI. А это значит, что пора начинать использовать виртуальных помощников для специалистов QA.
Поговорим про использование логического ИИ при разработке сценарных тестов; про то, что требуется для работы в паре
с виртуальным помощником; как происходит создание “”базы знаний””, общение и обучение; как выглядят такие сценарные тесты; какую выгоду мы получаем от такого сотрудничества.

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

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

План доклада:
-Что такое API;
-Проектирование функциональных API тестов;
-Нагрузочные тесты для API;
-Общие проблемы, с которыми мы сталкиваемся когда используем функциональные API тесты для нагрузочного тестирования API.

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

В своем докладе Павел расскажет об особенностях тестирования UI интерфейса с cypress на стороне разработки и интеграцию этого инструмента на проектах вместо Selenium WebDriver. Также покажет реальные конфигурации и расскажет особенности конфигурирования данного инструмента и интеграцию запуска ui автотестов на bamboo. Более того, будут затронуты популярные паттерны проектирования в ui автоматизации и показана их эволюция в контекст cypress, а еще Павел поделится некоторыми архитектурными “”плюшками””, которые увеличат скорость написания автотестов и упростят их поддержку. В заключении доклада будут представлены преимущества cypress перед Selenium WebDriver и преимуществ подхода написания автотестов на стороне frontend разработки.