Средства разработчика позволяют очищать файлы 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 причины: