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

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

Вы увидите:

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

И, конечно же, ответим на главный вопрос - зачем вообще тестировщику спрашивать.

Алгоритмы — это не скучная теория, а способ смотреть на задачи иначе! На этом мастер-классе разберёмся, что такое алгоритмическое мышление, почему оно полезно не только программистам, и как тренировать его в жизни. Простые примеры, наглядные разборы и никакой скукоты — после этого занятия вы начнёте видеть алгоритмы даже там, где раньше не замечали!

Хочется выступить с докладом, но не знаешь, с чего начать? Этот мастер-класс поможет найти интересную тему, сформулировать ключевую идею и упаковать её так, чтобы слушателям было интересно. Разберём, как выбрать формат и донести свою мысль чётко и убедительно.

Идеально для тех, кто хочет выступать, но пока не знает, о чём говорить!

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

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

Как тестировщику читать спецификацию так, чтобы потом было не очень больно тестировать?

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

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

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

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

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

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

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

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

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

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