Доклады

Cutting-edge технологии (1)

Нюансы тестирования распределенной базы данных

Если с тестированием сайта, мобильного приложения или даже игры все, вроде бы, понятно, есть множество людей занимающихся этим и готовых поделиться опытом, то что насчет базы данных, да еще и распределенной?
Тема тестирования "монстров" вроде Apache Ignite показалась мне малораскрытой и я решил поделиться подробностями нашего опыта в этом докладе.

Я занимаюсь разработкой распределенного хранилища Apache Ignite с тех самых пор как проект вошел в Apache Software Foundation.
И под разработкой я понимаю не только написание кода, но и тестов, бенчмаркинг, автоматизированные испытания и демонстрации.

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

Доклад принят в программу конференции

Cookbook - готовые рецепты (6)

Фаззинг-тестирование с учетом структуры данных, библиотека libblobstamper

Николай Шаплов

Postgres Professional

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

Для преодоления этого препятствия предполагается использовать фаззинг-тестирование с учетом структуры данных (Structure Aware Fuzzing). При SAF тестировании генерируются формально валидные (синтаксически верные или структурно корректные), но фактически случайные данные, что позволяет подвергнуть тестированию уровни системы лежащие за синтаксическим анализатором.

Библиотека LibBlobStamper, созданная в недрах компании Posrgres Professional, позволяет решать задачи построения SAF-тестов как для случая строковых (синтаксических) так и для бинарных (структурных) входных данных.

В данном докладе рассказывается о проблематике Structure Aware Fuzzing'а, приводится краткий обзор имеющихся инструментов и проводится наглядная демонстрация того как задачи SAF-фаззинга могут быть решены с использованием библитеки LibBolbStamper.

Доклад принят в программу конференции

Git submodules в автоматизации тестирования

Сергей Мишанин

ПАО "Банк "Санкт-Петербург"

Когда необходимо организовать процесс автоматизации тестирования в большом количестве команд, неизбежно встает вопрос: как избежать разработки собственных "велосипедов" командами, сделать их код единообразным и совместимым и при этом сделать это удобным образом.
В своём докладе я сравню подходы с использованием Maven зависимостей и Git submodules, обозначу потенциальные проблемы при использовании подмодулей и покажу вариант решения таких проблем.

Доклад принят в программу конференции

Ускорение тестирования за счёт Crowd

Ляйсан Исхакова

ООО "Яндекс"

Как в Яндексе придумали решить все боли разом:
- Тестирование перестало быть "узким горлышком"
- Появились комитменты сроков тестирования и даже прогноз в будущем.
- Тестировщиков избавили от рутины, утомительного регресса. Дали больше времени на сложные задачки и выстраивание правильных процессов.
- Масштабируемость - научились обменивать деньги тестирования на скорость тестирования, покрытие конфигураций, увеличение вероятности качества.

Доклад принят в программу конференции

Стабильность в нестабильном мире: тестируем при помощи Kubernetes

Доклад состоит из двух частей: теоретическая и практическая.

1. Теория
- Понимание continious-процессов. Для чего нам нужны тесты и как мы хотим проводить тестирование и доставлять продукты.
- Модели ветвления: что в итоге окажется на целевых окружениях.
- Как и когда нам может помочь kubernetes, а когда можно обойтись и без него.

2. Практика
- Если у нас есть kubernetes в продакшне, как бы нам прикрутить его еще и для быстрого тестирования.
- То же самое, но если у нас нет kubernetes в продакшне? Используем "легкие" версии k8s, сокращаем накладные расходы.
- Инструменты для CI/CD: GitLab, GitHub Actions, Jenkins.

Доклад принят в программу конференции

Spring Boot. Эффективное тестирование Service и Data layer

Семен Киреков

МТС Диджитал

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

Когда речь идет о тестировании Service и Data layer, можно использовать моки и стабы, а можно и реальную СУБД. Я расскажу на примере Spring Boot, что это ничуть не сложнее, чем подход “мокать все и вся”. С помощью аннотаций @DataJpaTest и @SpringBootTest покажу, как настроить H2, Testcontainers и Flyway. И попробую вас убедить, что писать тесты, работающие с базой данных, не сложно и не страшно.

Доклад принят в программу конференции

Нагрузочное тестирование с помощью Python. Инструмент 'Locust' vs. Rest API / Kafka

Доклад посвящен Python- ориентированному инструменту для нагрузочного тестирования 'Locust'.
Помимо демонстрации процесса работы и общего описания, особое внимание будет уделено примерам реализации скриптов и технических задач.



Общее описание инструмента:
- Назначение
- Характеристики Locust
- Кому и чем удобен

Как строится работа с Locust:
- Особенности написания скриптов для нагрузочного тестирования
- Запуск тестов
- GUI для запуска и мониторинга тестов
- Графики, статистика по тесту, отчеты
- Работа с потоками и подход к генерации нагрузки
- Ресурсоемкость
- Совместимость с разными ОС

Примеры реализации скриптов:
- Отправка стандартных http запросов
- Отправка запросов в разные системы (на примере Kafka)
- Генерация собственной статистики
- Tear UP
- Tear Down
- Реализация нестандартной логики подачи нагрузки
- Запуск отдельных потоков в параллель с тестом
- Assertions
- Работа с операционной системой
- Взаимодействие с InfluxDB
- Конфигурирование тестов
- Логирование

Доклад принят в программу конференции

Нагрузочное тестирование (2)

Автономная система стрельб по проду на базе кластера сервисов

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

Доклад принят в программу конференции

Как ускорить запросы к InfluxDB с помощью InfluxQL Continuous Queries и разделения данных

Хранилищем результатов тестов производительности для популярных инструментов является InfluxDB. Это хранилище используется для JMeter, Gatling, Performance Center... И если выполнять тесты производительности регулярно, по несколько раз в день, то вскоре фильтровать результаты тестов производительности становится сложно. Запросы к InfluxDB становятся медленными.

Команда нагрузки ВТБ столкнулась с такой проблемой. И возникла необходимость разделения данных так, чтобы они сразу соответствовали фильтрам. А также необходимость хранения данных так, чтобы приходилось реже выполнять сложные агрегатные функции. Это позволило выполнять запросы быстрее.

Доклад принят в программу конференции

Автоматизируем рутину (3)

Мастер-класс по тестированию Web-аналитики

Когда речь заходит об эффективности проекта, то в первую очередь мы говорим цифрах. Дизайн, разработка, контекст, seo, smm и прочее — если ты не анализируешь и не отслеживаешь результаты своих телодвижений, значит, ты полагаешься на случай! Бизнесу важно принимать решения на основе достоверной информации.

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

Во время мастер-класса мы с нуля проверим отправку запросов в сервис по сбору аналитики — Snowplow.

Мы сэмулируем реальную бизнес-ситуацию, проведем ревью существующих на рынке средств автоматизации: WebdriverIO, Puppeteer, Playwright и получим полную картину того, насколько они подходят для решения данной задачи.

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

Доклад принят в программу конференции

Зачем QA работать за релиз-инженеров

В Ozon mobile QA выполняют задачи релиз-инженеров. Это помогает нам ускорить разработку фич и наращивать экспертизу там, где обычно не принято среди QA инженеров. Как мы к этому пришли и почему это работает — Дарья расскажет в своём докладе.

Доклад принят в программу конференции

How to Automate Routine Tasks Using Bash

Roel Van de Paar

Dream Computers Pty

Sharpen your Bash scripting skills and learn how to customize your scripts for improved task automation on Linux systems.

“With some creativity and ingenuity, almost any task can be automated with Bash.”

This talk will discuss how to automate routine tasks with Bash at a medium to advanced level. It will cover various advanced Bash commands and show how they can be used to accomplish complex and repetitive tasks. Attendees will also discover how to make their automation scripts more efficient.

The key Bash features the speaker will discuss include pipes, conditionals and looping, advanced Bash idioms, xargs, sed, and regular expressions. We will also explore parallel processing and script optimization.

Duration: ~60-90 minutes.

Доклад принят в программу конференции

Оптимизация тестов и аналитики (5)

Почему программист не может тестировать свой код

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

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

Доклад принят в программу конференции

Главное - не моргай! Как мы избавлялись от flaky-тестов

Никита Чурсин

Технологический Центр Дойче Банка

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

Доклад принят в программу конференции

Три простых инструмента, которые экономят время тест-лиду в покрытии, анализе и планировании на проекте

Вас когда-нибудь спрашивали: “А сколько там ваши автотесты покрывают?”, “Зачем вам ЕЩЕ тестировщики??”, “Блин, опять баги нашли в авторизации. Как объяснить ПМу, что её давно пора рефакторить?”. Чтобы ответить на такие вопросы с доказательной базой, цифрами и графиками, я написал несколько инструментов, а затем и выложил их в OpenSource.


Именно о них и пойдет речь в докладе:
DataInu: говорит где у нас больше всего багов, что даёт повод для рефакторинга и фокус для написания автотестов. Вопрос: “Как объяснить ПМу, что авторизацию давно пора рефакторить?” больше не стоит, он и сам это понимает.
https://github.com/artkuznetsov/datadog ;
Workflow Simulation Service (WSS). Позволяет мне безопасно для проекта, команды и бюджета определять вероятность успешности изменений, на основе чего уже я могу принимать решение о их внедрении или отмене на живом проекте. Этот инструмент вместо меня отвечает на вопрос: “Зачем вам ЕЩЕ тестировщики??”
https://github.com/artkuznetsov/workflow-simulation-service ;
Подход, который даёт понимание, какие части приложения мы еще не покрыли, какие покрывать не надо,а какие - вообще мёртвые. Это понимание позволило нам правильно расставлять акценты при планировании скоупа автотестов на спринт. Способ применим только для Java приложений, но мы также сравним его с современными аналогами, такими, как Drill4J.
Теперь мы знаем сколько и что именно покрывают наши автотесты, а сколько - ручные.
https://bit.ly/3jdXzbP

Доклад принят в программу конференции

Скорость как показатель качества

От года к году число пользователей и заказов на Ozon растет. И наши IT-системы должны поддерживать этот рост: сервисам нужно отдавать контент как можно быстрее. И чтобы это делать, нужно знать, как измерять скорость сайта в браузере.


Достаточно ли проводить тестирование только на тестовых средах? Нет!
Стоит ли останавливать QA деятельность после релиза? Нет!
Будет ли продукт качественным, если сайт открывается долго? Нет!

Достоверно понять, как сайт работает, можно только по метрикам и тестам на продакшене.

В докладе я расскажу:
- как мы понимаем, что наш сайт быстрый
- какие есть инструменты для измерения скорости сайта;
- как мы проводим анализ метрик;
- о метриках TTFB, TTLB, LCP, CLS, SpeedIndex — какие из них больше относятся к фронтенду, а какие — к бекенду;
- на какие показатели рекомендует ориентироваться Google, и как далеко мы от этих показателей;

А также:
сравним 2 подхода по сбору метрик: RUM vs SiteSpeed
посмотрим примеры реальных кейсов: какие выводы можно делать по наблюдаемым измерениям.

Доклад принят в программу конференции

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

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

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

Доклад принят в программу конференции

QA и наука (4)

Как протестировать культурный код или UX-тестирование детского голосового помощника.

Анна Дегтева

Альфа-Банк

Роботы и печенье: детское устройство от этнографии до UX-тестирования.

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

На момент начала разработки в 2016 году в русскоязычном сегменте аналогичных устройств не существовало, голосовой интерфейс использовался реже, чем сейчас, и основные пользователи - дети, чаще всего, не имели опыта и наработанной манеры взаимодействия с ним (а разработчики - с детьми). Проектировать взаимодействие с устройством и проверять свои гипотезы команде приходилось практически “с нуля.”

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

Результатом работы стало усовершенствование не только устройства, но и методов тестирования и UXR для голосовых устройств.

Доклад принят в программу конференции

Оценка качества научных исследований и полученных данных

Берлин Хенис Александра

Лаборатория когнитивных и лингвистических исследований

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

Доклад принят в программу конференции

Метрика вовлечённости, или Как измерить качество изменений на образовательной онлайн-платформе

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

Задача оценки вовлечённости ученика не является новой. Исследователи давно научились с помощью опросов измерять вовлечённость учеников школ и университетов. Однако данный подход трудно масштабировать на многотысячные аудитории образовательных онлайн-сервисов.

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

Из доклада вы узнаете:
- как с помощью тех действий, которые совершают ученики онлайн-платформы, измерить факторы, влияющие на их вовлечённость в процесс обучения;
- какие факторы действительно влияют на вовлечённость, а какие — нет;
- как из полученных факторов собрать единую метрику вовлечённости ученика в процесс обучения и оценить её качество.

Доклад принят в программу конференции

Биометрические гаджеты как инструмент usability-тестирования

Исторически использование биометрии (пульс, кожно-гальваническая реакция, электроэнцефалография, отслеживание направления взгляда и т.д.) для оценки когнитивной и физической нагрузки, испытываемой пользователем программного или аппаратного продукта, оставалось уделом крупных лабораторий из-за дороговизны и эксклюзивности соответствующего оборудования. Однако современные гаджеты потребительского сегмента, ориентированные на фитнес и развлечения, сильно изменяют баланс: они достаточно широко доступны, чтобы обеспечить тестирование на адекватной выборке, и при этом достаточно точны, чтобы предоставить информацию, полезную для оценки UI/UX.
В докладе будет рассмотрено использование в тестировании таких гаджетов, как фитнес-трекеры, потребительские гарнитуры с функциями электроэнцефалографа и айтрекеры. Для каждого типа устройств будут предложены метрики, по которым можно выполнять сравнение и оценку результатов эксперимента, и кратко рассмотрены сценарии их использования для сравнения схожих программных продуктов в двух типах задач: задачах, связанных с последовательностями разнотипных операций, и с длинной последовательностью рутинных операций.
Также будет уделено внимание преодолению проблемы иного целевого назначения потребительских гаджетов, из-за которого их использование в исследовательских целях может оказаться затруднено: будут рассмотрены способы извлечения данных, вопросы шифрования биометрической информации и лицензирования.

Доклад принят в программу конференции

QA и саппорт (3)

QA and Support Pro’s: A Match Made in Heaven?

Roel Van de Paar

Dream Computers Pty

Quality assurance and support professionals share a lot of common ground. They both have to understand the product's goals and features, be able to identify issues, and have a thorough understanding of the procedures for interacting with users — from support calls to bug reports.

In this talk, learn how these two jobs can work together better to create a great customer experience.

Доклад принят в программу конференции

Выстраиваем отношения с техподдержкой

У пользователей того или иного сервиса возникают вопросы, сомнения или проблемы с использованием сервиса. Куда же направить таких пользователей? Какие каналы связи им предоставить? И как работать с огромным количеством технических обращений, если саппорт не технические специалисты, а советовать «переустановить приложение» – это самый первый шаг к потере клиента? В своем докладе дам ответы на эти и другие вопросы эффективного взаимодействия саппорта и тестирования, поделюсь различными лайфхаками. А также расскажу, как не работать в дни дежурства.

Доклад принят в программу конференции

Как свить гнездо для бага: воспроизводим проблемы с базой данных (mysql/postgres/mongo)

Чем отличается жизнь QA инженера и Support на примере баз данных MySQL, MariaDB, Percona Server, Postgresql, Mongo? QA ищет проблемы, а Support старается ответить на вопросы.
Сокращаем время ответа с помощью быстрого старта пустых баз. Ищем золотую середину между воспроизводимостью бага и честностью микробенчмарка. Открываем дверцу в исходный код через perf и gdb.
Воспроизводим конфигурацию репликации и кластеров, чтобы найти ошибки конфигурационных опциях.
Всё это на живых примерах Docker и LXD контейнеров.

Доклад принят в программу конференции

Как и чему учиться и учить (4)

Как в Почтатех ручных QA в автоматизацию переводили

Андрей Буров

Почтовые технологии

Александр Бутаков

Почтовые технологии

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

Расскажем:
- как увеличить скорость выпуска релизов без потери качества если у вас в команде нет сильного автоматизатора
- о собственном опыте привлечения ручных тестировщиков в автоматизацию
- как мы добились хороших результатов
- как мы использовали best practices (многопоточность, BDD, мультибраузерность из коробки).

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

Результаты, которых мы добились:
1) ручные тестировщики перешли в автоматизацию
2) покрыли авто-тестами 95% функционала
3) уменьшили время регресс с нескольких до одного дня

Доклад принят в программу конференции

Выход на новую работу как прохождение игры

Смена работы — это всегда стресс.

Но что, если посмотреть на это с другой стороны? Я понял, что все сложные и пугающие моменты, связанные с выходом на новую работу в тестировании, очень похожи на прохождение уровня в компьютерной игре:
* Просмотр вакансий — это выбор уровня.
* Собеседование — конфигурация сценария под те условия, в которых мне нравится играть.
* Первый день на работе — появление на неизвестной для меня карте в игре.
* И все остальные элементы тоже максимально похожи!

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

Доклад принят в программу конференции

Круглый стол: "Как учиться и чему учить в тестировании?"

Мы собираем круглый стол для обсуждения обучения в тестировании в широком формате:
Чему учиться чтобы стать тестировщиком?
Почему с неохотой берут джунов без опыта?
Куда двигаться, если уже успешно работаешь?
Как начать заниматься автотестами и не сойти с ума?
Насколько важны soft-skills и какие?
Как и в какую сторону изменяется IT?

Эти и многие другие вопросы мы обсудим с приглашенными звёздами. Можно будет задать свои вопросы.
Чтобы обсуждение не потерялось, так же запускается opensoucre проект по картированию знаний в области тестирования, можно к нему присоединяться.

Доклад принят в программу конференции

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

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

1. Как работать со своей базой навыков и знаний, как ее улучшать и актуализировать.
2. Какие есть варианты - что экономически целесообразно и что будет пустой тратой времени и денег.
3. Как обогнать, перегнать и еще и использовать свои знания и умения, полученные до начала карьеры для текущих рабочих задач.
4. Что делать, чтобы не скатиться в самобичевание, достигаторство и синдром самозванца.

Доклад принят в программу конференции

Удаленка и законодательство (1)

Удалёнка без нервных тиков: как быть эффективным, но не начать жить на работе?

Честный рассказ об удалёнке от человека, который с 2013 года бывает в офисах своих работодателей раз в 3-6 месяцев, как правило, оставаясь на хорошем счету и в добрых отношениях с коллегами.
Поговорим о самом главном:
- чем отличаются собеседования на удалённую позицию;
- на что стоит обратить внимание при удалённом трудоустройстве;
- когда точно стоит приехать в офис;
- когда можно работать из дома или любой точки мира;
- что хорошего и что плохого в хоум-офисе;
- как подготовиться к удалёнке по простому чек-листу;
- сколько займёт адаптация и как приучить домашних вас не беспокоить.
В докладе я постараюсь обобщить не только свой опыт работы в российских и международных компаниях, но и опыт российских и иностранных коллег различных профессий из разных ИТ-сфер.
Бонус: будут полезные ссылки по теме и данные актуальных научных исследований, на которые можно ссылаться.

Доклад принят в программу конференции