1) От конечных пользователей к тестировщику поступает катастрофически мало информации. Часто это не последовательность действий, а лишь описание проблемы, с которой столкнулся пользователь.
2) Примеры, которые приводят пользователи, могут быть очень нагруженными и содержать множество деталей, не имеющих отношения к делу. Например, делаете графический редактор. Пользователь столкнулся с проблемой сохранения данных. У него есть некий рисунок, в котором 100 объектов. Он добавляет 101 первый и жмет кнопку [Сохранить]. После перезагрузки рисунка мы видим, что 101 первый объект пропал, то есть данные в базе не обновились. Возможно, что Вам даже не сообщат какого типа был 101 объект. Может оказаться, что дело не в типе объекта и не в их количестве. Может даже оказаться, что проблема воспроизводится только с этим рисунком, и не воспроизводится с его копией. Еще хуже, если баг воспроизводится не стабильно.
К сожалению, нет четкой инструкции, как действовать в этой ситуации. Вот лишь несколько рекомендаций:
Проверьте, нет ли ошибок при воспроизведении бага. Загляните в консоль браузера, на сервер (обычно сервера имеют файлы – logs – куда сохраняется вся информация о серверных ошибках) или в средства слежения за ошибками операционной системы, в которой работает сервер. Текст ошибок может значительно сузить область, в которой возникла проблема.
Попробуйте воспроизвести баг в тестовой среде. Для этого обычно необходимо скопировать пользовательские данные из базы продуктового сайта в базу тестового сервера. Воспроизведение ошибки в тестовой среде позволит программисту подключить к серверу средства отладки, которые также позволят Вам и ему продвинутся к сути проблемы.
Если у Вас есть четкие шаги для воспроизведения проблемы, но Вы не знаете, что конкретно к ней привело, то попытайтесь ее детерминировать, постепенно убирая детали. В примере с графическим редактором сделайте копию рисунка. Если Вы сделали копию средствами вашего сайта и баг не воспроизводится с копией, то сравните, чем отличаются данные копии в базе от оригинала. Если воспроизводится с копией, то постепенно убирайте из нее объекты и проверяйте, не пропал ли баг. Проанализируйте, удаление какого объекта привело к исчезновению бага. Проверьте вашу гипотезу на другом рисунке.
Если баг не стабильный, то пробуйте воспроизводить его в разное время и с разной скоростью. Также оцените периодичность его возникновения. Я сталкивался с ошибками, которые воспроизводились, когда пользователь слишком быстро нажимал на кнопки. Он не дожидался ответа от сервера, это как раз и приводило к потере данных. Также некоторые баги воспроизводятся только в часы наибольшей нагрузки на сервер – часы с наибольшим количеством пользователей. Сейчас существует множество программ, которые могут симулировать большую нагрузку. Если Вы заметили, что ваш баг воспроизводится с вероятностью, например, 1/16 и чем больше Вы тестируете, тем больше Вы в этом уверены, то возможно причина генерация случайных чисел. Мне приходилось видеть баги, в которых из-за неправильно выбранного типа данных переменной в GUID отбрасывался ноль в начале. Без этого нуля валидация на правильность формата GUID падала. Это приводило к серверной ошибке с печальными последствиями. Вероятность выпадения 0 в начале GUID – 1/16.
Деловая переписка
Как ни странно, но переписка занимает существенную часть рабочего времени тестировщика. Основные задачи для переписки:
Выяснение требований к новой функциональности и оценка трудозатрат
UAT (Тестирование на стороне клиента) – Урегулирование разночтений и починка пропущенных багов
Поддержка пользователей и исследование багов на продуктовом сайте
Электронная почта до сих пор является основным средством переписки. Рассмотрим основные правила на ее примере.
Любое письмо начинается с приветствия, например, Hello Tom. Приветствие является важной частью письма. Так как большинство писем отправляются не одному человеку, а группе, то приветствуя адресата по имени, Вы выделяете его из группы и назначаете ответственным за выполнение задания, описанного в письме. Если письмо не требует ответа или каких либо усилий, (например, Вы хотите проинформировать ваших коллег о предстоящем отпуске), то можно обратится ко всем сразу, например, Hello Team.
Большинство почтовых клиентов имеют несколько полей для адресатов:
To – Кому
CС (Carbon Copy) – Копия
BCС (Blind Carbon Copy) – Скрытая копия
Как правило, в “To” указывают тех адресатов, к которым Вы обращаетесь в тексте письма. В “Cc” указывают остальную часть команды, которая должна быть в курсе вашей переписки, скрытую копию “Bcc” чаще всего отправляют руководству или в архив, чтобы можно было восстановить переписку, например, после увольнения сотрудника и удаления его аккаунта.
Вслед за приветствием следует краткое описание содержимого письма, например:
Не могли бы Вы взглянуть на наши вопросы по новой фиче – “Название фичи”
Зачастую большинство писем отправляются руководителю команды, который распределяет задания по команде, на некоторые отвечает сам. Чтобы не перечитывать письмо полностью для того, что бы понять, о чем оно, или кто за него будет отвечать и нужно краткое описание или введение.
Во всей массе писем можно выделить две большие группы – выяснение требований и описание проблемы. При выяснении требований нужно задать вопросы, которые возникают при прочтении задания, которое прислал заказчик. Количество вопросов зависит от того, насколько детально оно проработано. Очень редко задание поступает в виде детально проработанной спецификации, скорее это будет пара фраз типа “Хочу добавить на наш сайт возможность посчитать статистику заказов, чтобы выявлять популярные книги и заказывать их у оптовиков заранее”. Иногда клиенты даже не знают, чего конкретно они хотят, у них есть проблема, которую нужно решить. Проработка новой функциональности – это немалая работа и она занимает существенное время. Клиенты нередко делегируют ее исполнителю, так как они не всегда являются людьми из IT и не представляют, какие еще сведения от них нужны. Также, возможно, у них есть другие задачи, и они хотят, что бы Вы все продумали, предложили дизайн, а они только подтвердили что это то, что им нужно. Исходя из этого и нужно строить общение с клиентом – Вы задаете вопрос и сразу предлагаете возможные решения.
Вопросы нужно задавать от общего к частному, постепенно уточняя детали. Для примера со статистикой нужно узнать:
На основании каких заказов считать статистику?
За какой период?
На какой странице ее можно посмотреть?
Кому она доступна?