Базовые знания тестировщика веб-приложений

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

UAT и Support

UAT (User acceptance testing) – обычно это тестирование на стороне клиента. Он проверяет, то ли Вы сделали, чего он просил и насколько качественно. Что требуется от тестировщика, если со стороны клиента поступили замечания (как правило, это баги):

Проверьте, получается ли у Вас воспроизвести баг. Манера изложения у клиента может отличаться от того, что Вы привыкли видеть в своей команде. Если не получается, то Вы можете попросить у него больше деталей (браузер, User ID, запись видео). Имейте ввиду, что работа над клиентскими багами имеет высокий приоритет. Поэтому следует отложить работу над другими фичами и заняться исследованием UAT багов.

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

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

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

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

Support – это поддержка пользователей (решение их проблем). Большинство проблем возникает после заливки нового кода на продуктовый сайт. Работа над багами, которые сообщили пользователи, выполняется по тем же правилам, что и над клиентскими. Разница лишь в том, что воспроизвести их бывает очень сложно и еще сложнее понять, что конкретно приводит к ошибке. Бывает, что не хватает и целого дня, чтобы разобраться, в чем дело. На это есть 2 причины:

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 и не представляют, какие еще сведения от них нужны. Также, возможно, у них есть другие задачи, и они хотят, что бы Вы все продумали, предложили дизайн, а они только подтвердили что это то, что им нужно. Исходя из этого и нужно строить общение с клиентом – Вы задаете вопрос и сразу предлагаете возможные решения.

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

На основании каких заказов считать статистику?

За какой период?

На какой странице ее можно посмотреть?

Кому она доступна?

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

Опция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

“Currently, all devices running iOS are limited to playback of a single audio or video stream at any time. Playing more than one video—side by side, partly overlapping, or completely overlaid—is not currently supported on iOS devices. Playing multiple simultaneous audio streams is also not supported. You can change the audio or video source dynamically, however. See Replacing a Media Source Sequentially for details.”

Возможные пути решения

Опция1: Мы добавим новый скрипт, который будет выполняться при нажатии на кнопку [Play] в видео. Этот скрипт будет останавливать все видео на текущей странице и только после этого запустит текущее

Опция2: Для пользователей продукции Apple мы будем выводить продвигаемые товары по одному, с возможностью переключатся между ними при помощи кнопок [Next] и [Back]

Реализация каждой из этих опций потребует 2 дня на реализацию, включая тестирование. Какую из них Вы предпочитаете?

С уважением,

Карпов Сергей

В завершении письма ставится сигнатура – подпись. Она должна содержать имя и фамилию отправителя, его контакты. Очень часто приходится слышать вопрос: А зачем нужен email в сигнатуре, ведь почтовый клиент всегда показывает имя отправителя? На практике очень часто письма объединяют в треды (группа писем объединённая в цепочку), пересылают их друг другу (reply и forward), присылают письма как файл, прикрепленный к другому письму (attachment) и т.д. Если Вы получите несколько писем объединённых в тред, то при отсутствии email в сигнатуре связаться с кем-то из участников будет невозможно. Кроме email указывают и другие контакты – телефон, id мессенджеров, почтовый адрес, но они скорее для экстренных случаев, чем для нормального режима работы. Для вашего же удобства можно указать еще ваш часовой пояс, чтобы ваши заграничные или очень удаленные партнеры реже беспокоили Вас в нерабочее время (если речь идет о телефоне) или меньше переживали, если Вы долго не отвечаете на важные письма.

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

Послесловие

Если Вам понравилась эта книга, и Вы хотите чтобы вышло продолжение, то можете сделать пожертвование:

Яндекс Деньги: 410012676033116

Web Money: R411931155582

По всем вопросам и предложениям обращайтесь по адресу:

[e-mail]