Заявки на доклады

Поиск по тегам:

TechLeadConf

- Как начать проект, создавая сразу необходимую DevOps атмосферу в коллективе
- Как получить DevOps как процесс , а не как отдельного человека
- Как бороться с возражениями команды
- В какой момент получилось продолжать строить процессы силой Dev и QA команд, без участия так называемого "DevOps инженера"
- Какие инструменты автоматизации мы использовали и как происходило обучение QA и Dev коллег использованию
На все эти вопросы мы постараемся дать предельно четкие ответы!

Программный комитет ещё не принял решения по этому докладу

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

Программный комитет ещё не принял решения по этому докладу

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

Программный комитет ещё не принял решения по этому докладу

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

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

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

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

В своём докладе я расскажу:
- Что такое инструмент для тестирования и как он может выглядеть
- Как анализировать свои рабочие процессы, чтобы понять, что вам нужен новый инструмент и как собрать для него требования
- Как приступить к разработке так, чтобы не забросить и при этом не мешать остальной работе
- Как мы придумали некоторые из наших инструментов и как мы их сделали
- - UserList - для оптимизации хаоса юзероцентрированного тестирования
- - QaApi - для автоматизации сложных операций с системой
- - Custom Receipts - для обхода ограничений песочницы AppleStore
- - Virtual Client - для изолирования биллинга от остальных систем при тестировании
- - MindMap Tool - для организации разрозненной документации
- - … и много чего ещё!
- Где и как искать места для автоматизации и оптимизации - потому что такие места есть ВСЕГДА. Поверьте мне.

Функциональное тестирование
,
Автоматизация тестирования
,
Интеграционное тестирование
,
Тестирование мобильного ПО
,
Приёмочные и функциональные тесты
,
QA / другое
Программный комитет ещё не принял решения по этому докладу

Представим ситуацию. Завершён проект, выпущен продукт, выполнены сервисные IT-работы. Как понять, что бизнес заказчик-получил то, что хотел? Если он доволен, то следование каким принципам позволило нам получить положительный результат? Что в нашем рабочем процессе было такого, что позволило зажечь искру синергии и совместными усилиями достичь бизнес-целей заказчика? Если же результат не очень, то что менять: перестроить процесс, подобрать более подходящие инструменты, прокачать компетенции команды?

Пытаясь отвечать на эти вопросы, мы вот уже 12 лет ставим эксперименты на наших сотрудниках и заказчиках. Сотрудники страдают от того, что внутренние правила игры постоянно меняются (процессы, инструменты, DoD и выходные артефакты проектов). С новыми заказчиками мы экспериментируем в том плане, что на их проектах мы применяем хорошо зарекомендовавшие себя наработки и обязательно проверяем какую-нибудь новую гипотезу. Цель экспериментов: приносить заказчикам максимально возможную бизнес-ценность при длительном сотрудничестве. Опираясь на опыт, мы приняли для себя тот факт, что успех нам сопутствует при соблюдении следующих принципов: прозрачный для заказчика рабочий процесс; глубокая вовлеченность стейкхолдеров; управление ожиданиями, основанное на одинаковом понимании бизнес-целей.

Собственно, подробностям эволюции нашего рабочего процесса с акцентом на текущее и перспективное его состояние будет посвящён мой доклад.

P.S.
По ходу доклада я буду использовать такие слова, как: BDD, Living Documentation, "Docs As Code", Impact Mapping, Story Mapping, Scrum, Kanban, Jenkins, Allure и другие термины из лексикона Agile-коучей. Но никакой инфо-цыганщины, только практические моменты.

Инструментальная поддержка, декомпозиция задач
,
Автоматизация разработки и тестирования
,
Методологии и процессы разработки ПО; Сроки и приоритеты
,
Работа со внешним заказчиком/исполнителем
,
Обслуживание клиентов, техническая поддержка, обратная связь
,
ТЗ/Help/Мануал - форматы и применение
,
Функциональное тестирование
,
Автоматизация тестирования
,
Приёмочные и функциональные тесты
,
Legacy системы, жизненный цикл продуктов
Программный комитет ещё не принял решения по этому докладу

Уже с середины 2010х годов набирает популярность идея inner source - применения идей open source, таких, как открытость и разработка программ сообществами, внутри крупных компаний, которые не готовы выкладывать исходные коды своих программ и привлекать внешних участников к разработке. Мы решили пойти дальше и нашли у себя примеры ПО, которое вполне можно опубликовать, чтобы коллеги, у которых возникают схожие проблемы, могли либо заимствовать наш опыт, либо поделиться своим. В докладе я расскажу, какие обстоятельства повлияли на то, что это стало возможно, рассмотрю состав и применимость набора библиотек, которые мы публикуем, опишу идеи, которые помогают продвигать идею open source внутри компании, и отмечу сложности, с которыми сталкиваешься, когда переходишь от внутренней разработки к открытой.

Микросервисы, SOA
,
Архитектурные паттерны
,
Разработка библиотек, включая open source библиотеки
,
Логирование и мониторинг
,
Корпоративная культура и мотивация
,
Продуктовая разработка
,
Enterprise-системы
Программный комитет ещё не принял решения по этому докладу

С ростом команды так или иначе возникает вопрос обмена знаниями и отслеживания технических решений в команде или отделе. Как правило понимание приходит тогда, когда полностью разработанные фичи зависает на ревью с серьезными претензиями к архитектуре и выбранному подходу в реализации. При этом готовую фичу переделывать сложно/дорого но и архитектурные проблемы нужно лечить. С другой стороны на больших проектах часто случаются проблемы, когда в разных частях проекта разработчики делают похожий функционал и когда казалось бы нам нужно объединить усилия и сделать его вместе, мы делаем каждый у себя и тратим на это в разы больше ресурсов. В своей практике мы столкнулись с такими проблемами и постарались их решить. Команда фронтенда в Яндекс.Деньгах насчитывает порядка 50-ти человек и нам было жизненно необходимо делиться знаниями и следить за архитектурой нашего фронтенда. В докладе я расскажу как модифицировался процесс разработки для того что бы исправить сложившиеся проблемы.

Программный комитет ещё не принял решения по этому докладу

Может быть, ваши QA на прошлой неделе были героями? Или вам срочно потребуется в следующем месяце купить десять iPhone с тремя камерами, без которых работа встанет? А Петя завтра уезжает в Таиланд, и ooops, это не поработать удаленно, а на месяц в отпуск, а вы не в курсе?

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

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

Программный комитет ещё не принял решения по этому докладу

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

Чаще всего в таких ситуациях из спичек и желудей создают прототип, или как еще модно называть, - MVP, с заверениями, что сразу после тестирования гипотезы код прототипа выкинут и напишут приложение заново как положено. Код действительно выкидывают, если “не взлетело”. А что делать, когда тестовый запуск прошел успешно и в нашей поделке уже живут настоящие пользователи?

Часто не смотря на все первоначальные договоренности приходится поддерживать и развивать то, что называлось MVP дальше. В докладе я расскажу о том как мы запускаем новые продукты, не выкидывая исходный прототип, но и не испытывая адских мучений с поддержкой.

Программный комитет ещё не принял решения по этому докладу