Как организовать тестирование, чтобы выпускать действительно качественные продукты.
1. Недооцененность тестирования
2. Минимальные стандарты и регламенты тестирования
3. Инструменты и системы управления
4. Документирование. Зачем и почему важно?
5. Почему тестирование должно быть независимым?

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

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

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

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

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

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

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

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

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

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

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

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

Умеете писать unit тесты? А как на счёт E2E ?

Вэб эволюционирует, тестирование тоже. Быстрое, простое и надежное тестирование для всего, что работает в браузере. Е2Е совсем не страшно. Расскажу и покажу Cypress, как с ним работать, расскажу про плюсы, покажу как развернуть и начать писать тесты. (А потом попросить больше денег у работодателя)

В разработке