How to ask

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

Шаг 1
Сформулируйте (на бумаге или в уме) вопрос так, чтобы ответ на него был однозначным: да/нет или пронумеруйте варианты.
Для практического закрепления возьмём "Пример 5" из статьи "Практикум корректности". Варианты главного вопроса:
- Надо ли учитывать размер всех вложенных папок и файлов при подсчёте размера отчёта?
- Что должно входить в размер отчёта:
a) размер файла "[НаименованиеОтчётаПроекта]_timestamp.html";
b) размер файла "[НаименованиеОтчётаПроекта]_timestamp.html" плюс объём файлов в иерархичных папках "[НаименованиеОтчётаПроекта]_timestamp";
c) раздельно две величины - размер головного файла и размер файлов в папке документа;
d) иной вариант (переименовать колонку).
Если самостоятельно не можете выбрать, то
Шаг 2
Там же (на бумаге или в уме) обрисуйте ситуацию в деталях: продукт, условия (система, настройки, данные), произведённые действия.
В рамках практики: продукт - "ClearSQL" последней версии, модуль - "Project Report Assistant", закладка - "Report History", колонка- "Report File Size".
Если собственные мысли не сложились в ответ, то
Шаг 3
Поищите подобные ситуации в литературе и публикациях по теме продукта. Изучайте буквари - это Ваше развитие, укрепление профессионального мнения и подтверждение трудоспособности.
Повысить свою компетентность можно заглянув в аналогичные списки иных продуктов. docuVIEWER на закладке со списком доступных для просмотра документов показывает общий объём файлов в колонке "Docu Size".
Если совокупность знаний всё ещё вызывает сомнения, то
Шаг 4
В списке сотрудников и их компетенций выбираем наиболее подходящего по Вашему мнению специалиста. Чаще всего им оказывается программист, на которого была возложена тестируемая задача для кодирования.
Если нет списка компетенций или в списке не нашлось подходящего соответствия по теме вопроса, то
Шаг 5
Выберите главного или старейшего программиста/начальника.
В команде Gitt для этого существует "ответственный за фичу".
Шаг 6
Запишитесь на приём или дождитесь, когда внимание программиста оторвётся от кода.
Из собственной практики:
- когда у меня был соседний/проходной с программистами кабинет (не видели друг друга, но всё слышали), то достаточно было дождаться момента, когда обсуждение кода перерастало в бытовые споры. Переключить болтовню с нерабочей темы на профессиональную - долг трудоголика, так что смело шагайте и вливайтесь в беседу;
- когда офис объединял в одном помещении и программистов и тестировщика, то разворот от своего монитора в сторону разработчика через несколько секунд давал положительную реакцию и готовность общаться;
- в случае раздельных помещений и распределённой команды в личном чате публиковался главный вопрос или из "Шага 7".
Шаг 7
Обратитесь  с первым вопросом так, чтобы ответ был только положительным. Это чистая практическая психология, налаживающая позитивное общение.
Пример вопроса, повышающего авторитет программиста: "Можете помочь тупому тестировщику?"
Шаг 8
Переключите мысли отвечающего на тему основного вопроса:
- Ты же работал с продуктом "Х"?
- Знаешь о существовании модуля "У"?
- У меня тест проходил при условиях "Z" и получилось "Бла-Бла-Бла".
Задайте основной свой вопрос (см. "Шаг 1"), например, "Это баговое поведение?".
Шаг 9
Получите однозначный ответ или уточняющие вопросы, для ответа на которые помогут "Шаг 2" и "Шаг 3".
На этом этапе у программиста есть возможность отыграться за все пятёрки "Зачем?", заданные вами ранее и упущенные на этапе планирования.
Шаг 10
Поблагодарите за потраченное на Вас время и упомяните консультанта в задаче (если ответ о новом баге был положительным, то в новооформленной, иначе в тестируемой). Ссылка в описании или комментариях бага на разработчика защитит Вас от разбирательств при выяснении корректности задачи. Во многих командах планирование новых задач основывается на залогированном времени выпущенных фич, поэтому обе стороны диалога должны добавить затраченные на обсуждение минуты в одну и ту же задачу.

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

Учтите, что отвлекая сотрудника на две минуты подготовленного разговора Вы крадёте у него от четверти до получаса мыслительной деятельности. Поэтому предпочитаю пользоваться отложенными сообщениями в чате, а не созвонами или болтовнёй вживую.
Из личного опыта:
- диалог в одной комнате затягивается до получаса и перескакивает на отвлечённые темы;
- через Skype, TeamViewer вопрос решается за 20-50 минут, включая время установления стабильного соединения (слышимость, видимость монитора, запуск приложения для воспроизведения проблемы);
- через личные каналы чата решается от трёх до пяти вопросов за 20 минут переписки, поскольку алгоритм сокращается на шагах 1-8. Но такой вариант совсем не нравится заядлым стартаперам, которые собираются в команду не для производства продукта, а лишь пообсуждать новые гаджеты, автомобили или цветочки.