Всего за 0.01 руб. Купить полную версию
Проверьте, нет ли ошибок при воспроизведении бага. Загляните в консоль браузера, на сервер (обычно сервера имеют файлы – 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 и не представляют, какие еще сведения от них нужны. Также, возможно, у них есть другие задачи, и они хотят, что бы Вы все продумали, предложили дизайн, а они только подтвердили что это то, что им нужно. Исходя из этого и нужно строить общение с клиентом – Вы задаете вопрос и сразу предлагаете возможные решения.
Вопросы нужно задавать от общего к частному, постепенно уточняя детали. Для примера со статистикой нужно узнать:
На основании каких заказов считать статистику?
За какой период?
На какой странице ее можно посмотреть?
Кому она доступна?
Для каждого варианта ответа обязательно предложите опции, среди которых клиент будет выбирать, либо предложит что то свое. Не лишним будет сделать комментарии для каждой опции, которые помогут сделать выбор, например:
Опция1 – Требует меньше всего трудозатрат,
Опция2 – Обеспечивает наивысшую производительность
Если Вы не очень четко понимаете, чего хочет клиент, делаете что-то впервые, либо клиент хочет сразу очень большой функционал, то можно предложить ему разбить разработку на несколько итераций. Это поможет сконцентрироваться на главном (договорится об основных функциях, пользовательском интерфейсе) и вовремя скорректировать работу, если Вы стали делать что-то не так как он этого хотел. Например, клиент хочет, что бы Вы сделали для него векторный графический редактор, в котором можно рисовать несколько типов линий (ломаная, Безье, свободная рука) и геометрические примитивы (круг, полигон, фигуры из шаблонов). Тут Вы как раз можете предложить сделать в первом релизе по одному типу линий и примитивов. В первом релизе Вы сделаете основу, покажете клиенту, чтобы он проверил, такой ли он себе представлял ход работы в редакторе. Во втором релизе добавите дополнительные функции и расширите набор типов линий и фигур.
Если ваш вопрос подразумевает ответ "Да" или "Нет", то не лишним будет задать вопросы типа: Должны ли мы поддерживать мобильные девайсы, если да, то какие? Это позволит сократить количество итераций при переписке. Также если Вы не уверены, что правильно его поняли, либо есть разночтения у членов вашей команды, то обязательно нужно уточнить правильно ли Вы поняли то или иное предложение. Для этого опишите своими словами то, как Вы его поняли и приведите пример. Например, клиент говорит, что хочет, чтобы пользователям была показана реклама при просмотре видео ролика в тот момент, когда начало окончания конца начала ролика началось. Этот пример я взял из одного фильма, но он наилучшим образом демонстрирует, насколько сложно иногда бывает разобраться в требованиях. По поводу этой фразы нужно обязательно уточнить у клиента: Правильно ли мы поняли, что рекламное сообщение должно всплывать, когда видео ролик просмотрен на 3/8? Например, если продолжительность фильма 16 минут, то реклама всплывет на 6 минуте (16 * 3 / 8)?
Вторая категория писем – письма с описанием проблемы. Они пишутся в следующей последовательности:
Краткое описание функциональности, где Вы видите проблему
Суть проблемы и ее причины
Возможные пути решения или профилактики
Выводы и призыв к действию
Будет не лишним вставить описанные выше разделы прямо в текст письма и выделить их жирным. Это облегчит чтение, и позволит человеку, который в курсе дела, пропустить уже известную информацию и быстрее перейти к делу. Вот пример такого письма:
Добрый день, Федор,
Вы просили разобраться, почему некоторые пользователи испытывают проблемы при просмотре рекламных сюжетов на странице "Promotion". Вот наши результаты:
Описание страницы
На странице "Promotion" пользователям доступен список продвигаемых товаров с их техническим описанием и рекламным видео роликом.
Причины проблемы
Как мы выяснили, все пользователи, заметившие проблемы с проигрыванием видео, пользуются продукцией фирмы Apple. Предположительно пользователи пытались запустить следующее видео, не остановив предыдущее. Как Вы возможно знаете, продукция фирмы Apple не поддерживает одновременное воспроизведение двух видео или аудио на одной странице. Вот ссылка:
https://developer.apple.com/library/safari/documentation/AudioVideo/Conceptual/Using_HTML5_Audio_Video/Device-SpecificConsiderations/Device-SpecificConsiderations.html