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

Почти все браузеры имеют встроенные средства разработки. Для их включения нужно нажать клавишу F12. Большинство из них позволяет делать следующее:

Просматривать и редактировать разметку страницы (html) и стили, которые к ней применились (css)

Просматривать скрипты (javascript), которые были загружены вместе со страницей

Просматривать ошибки, которые произошли во время загрузки и работы со страницей

Просматривать всю сетевую активность, которую выполнил браузер для загрузки этой страницы, а также для ее работы

Просматривать файлы Cookie и Cache

Чем полезны средства разработчика для тестировщика и что он может проверить с их помощью:

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

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

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

Средства разработчика позволяют очищать файлы Cookie и Cache только для текущего сайта (домена). Это очень удобно, так как очистка файлов Cookie приводит к потере сессии. Если почистить все cookie, которые есть в браузере (Ctrl + Shift + Delete), то Вам придется повторно авторизоваться на всех сайтах.

Некоторые сайты для ускорения загрузки файлов используют CDN (content distributed network) – распределенное хранилище файлов. Пользователи загружают файлы из хранилища максимально приближенного к ним, за счет этого и происходит ускорение. При загрузке файлов убедитесь, что они загружены с CDN (Обычно CDN имеет другой адрес, нежели текущий сайт). Также на CDN загружают не только пользовательские файлы (картинки, аудио и видео) но и большие, редко изменяющиеся скрипты.

Smoke test

После завершения работы над новой функциональностью, она попадает на тестовый и далее на продуктовый (production) сайт. Процесс заливки новой функциональности в другую среду (environment) не обходится без участия тестировщиков. Что нужно проверить после заливки:

Открыть основные страницы приложения, выполнить поиск/создание объектов на них

Проверить, что не возникли проблемы, исправленные при прошлой заливке

Выполнить Smoke test. Smoke test – это быстрая проверка основной функциональности. Как правило, выполняется после заливки нового кода. Начинать его нужно с той части сайта, которая доступна конечным пользователям. Например, Вы тестируете интернет-магазин, который состоит из 2 частей. Первая часть доступна для покупателей. Она состоит из каталога товаров, корзины и страницы заказов. Вторая часть доступна для администраторов и менеджеров, которые обрабатывают заказы. В этом случае тестирование нужно начинать с 1 первой части, так как она доступна большему количеству пользователей и ее простой обходится большими издержками для бизнеса. В рамках smoke test интернет-магазина нужно проверить, что работает просмотр товаров во всех категориях, работает добавление товаров в корзину и просмотр содержимого корзины. Также нужно выполнить заказ. В рамках Smoke test не нужно уделять внимание деталям и проверять редкие кейсы. Его цель как можно быстрее убедиться в работе основного функционала и обозначить наиболее критичные баги.

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

Проверить, что попали все фиксы, которые были сделаны в тестовой среде, но не были сделаны на продуктовом сайте. Не обязательно проверять их детально, как Вы это делали в тестовой среде. Достаточно убедится что код, относящийся к ним, залит.

Проверить новую функциональность. Только убедившись, что старый функционал не сломан, можно переходить к проверке новой функциональности. Так как все уже было детально протестировано в тестовой среде, достаточно выполнить только позитивные кейсы. Если в рамках новой фичи была изменена структура данных, например, было добавлено новое поле в форму заказа, то обязательно проверьте что это поле заполнено у существующих заказов. Обычно пишется скрипт который назначает всем существующим заказам новое значение. Обычно это значение по умолчанию (default value) или NULL. Уделите этому очень большое внимание, если были сделаны более сложные преобразования, например, для хранения информации о заказе была добавлена новая таблица. Если скрипт миграции данных содержит ошибки, то может произойти потеря данных. Последствия будут еще более печальными, если это обнаружится не сразу. Советую перед заливкой таких фич просмотреть и записать, как выглядят несколько наиболее характерных для вашего сайта объектов. Например, вы меняете структуру хранения корзины с товарами. Перед заливкой добавьте несколько товаров в корзину. После заливки проверьте, что все товары на месте и не появилось ни чего лишнего. Также проверьте, что вы можете оформить заказ этих товаров. Не забывайте делать бэкапы баз данных перед заливкой.

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

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” чаще всего отправляют руководству или в архив, чтобы можно было восстановить переписку, например, после увольнения сотрудника и удаления его аккаунта.

Вслед за приветствием следует краткое описание содержимого письма, например:

Не могли бы Вы взглянуть на наши вопросы по новой фиче – “Название фичи”