Окончание содержимого

Tabbing

1. Tabbing order should go from Top Left to Bottom right horizontally, if other order is not specified.

2. Tabbing should go onto the next editable field on the window. Read-only and disabled fields should be avoided.

Form Navigation (for WIN applications)

Press	Result
CTRL+TAB	Move forward through tabs.
END	Display the bottom of the active window.
HOME	Display the top of the active window.
CTRL+SHIFT+TAB	Move backward through tabs.
TAB	Move forward through options.
SHIFT+TAB	Move backward through options.
ALT+Underlined letter	Carry out the corresponding command or select the corresponding option. TBD
SPACEBAR	Select or clear the check box if the active option is a check box.
Arrow keys	Select a button if the active option is a group of option buttons. TBD
BACKSPACE	Open a folder one level up if a folder is selected in the Save As or Open dialog box. TBD

Functions running

ENTER	Carry out the command for the active option or button.
F1	Display Help.
F4	Display the items in the active list (list box, drop-down box).
Ctrl + S	Save all unsaved tasks
Ctrl + C	Copy selected items
Ctrl + X	Cut selected item
Ctrl + V	Insert the item
Space	If the active option is a check box, pressing SPACEBAR should select or clear the check box
ESC	Activate Cancel button on the screen if there is any

Attachment — вспомогательное средство передачи информации о проблеме

Цель и характеристики

Attachment — это прикрепленный к дефекту файл, дополняющий описание: скриншот, файлы, необходимые для воспроизведения дефекта, логи программы, видео ошибки и т.д.

Грамотный скриншот должен давать возможность понимать смысл дефекта без необходимости читать описание дефекта.

Если к дефекту прикрепляется файл, об этом обязательно должно быть указано в описании дефекта (нейтральной фразой «See the file/screenshot/log/video attached»).
Прикрепленный файл не должен быть слишком большим по размеру (особенно это касается видео — до 10 мегабайт), а также должен относиться именно к описанной ошибке (например, из лога приложения стоит скопировать в прикрепляемый файл только данные об ошибке).

Attachment обязателен для GUI дефектов!

Правила оформления скриншотов

В общем виде, скриншот должен содержать следующие элементы:

· Сама ошибка

· Выделение прямоугольником места ошибки

· Стрелка к прямоугольнику

· Описание ошибки: «Наблюдаемый результат» и/или «Ожидаемый результат»

Текст на скриншоте также стоит выделить: обвести в прямоугольник и набрать шрифтом, заметно отличающимся от шрифта программы (не нужно использовать розовый Comic Sans, достаточно изменить размер шрифта и выбрать другую гарнитуру).

Требования к скриншотам:

· Делать снимок всего окна программы необязательно — на снимке должна быть видна ошибка и место, где она находится: недостаточно показать сообщение «Fatal error», для понимания дефект необходим контекст (всё окно программы в фоне или левый верхний угол с названием диалогового окна, где эта ошибка появилась).

· Формат файла скриншота — PNG.

· Имя файла скриншота рекомендуется делать числовым нейтральным – 1.png, 25.png и т.п. Описание или ID дефекта в имени файла только увеличивают время на создание скриншотов. Всю полезную информацию лучше вынести на сам скриншот, где она будет хорошо заметна.

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

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

Содержимое отчета

·

Итак, считаем, что все проверено, все дефекты обработаны и нам нужно приступать непосредственно к написанию отчета.

Начнем с того, что каждый отчет можно разделить на части, в каждой из которых представлена соответствующая информация

· Приветствие

· Общая информация (Common Information)

· Тестовое окружение (Test Platform)

· Рекомендации QA (QA Recommendations)

· Детализированная информация (Detailed Information)

· Окончание содержимого

Приветствие

Свое письмо с отчетом необходимо начать с приветствия всех адресатов.

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

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

Общая информация (Common Information)

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

Тестовое окружение (Test Platform)

Как правило в этой части указываются:

· Название проекта

· Номер сборки

· Ссылка на проект (сборку). Необходимо убедиться, что зайдя по этой ссылке вы действительно попадаете на проект или можете установить приложение, поэтому обязательно пройдите по ссылке

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

Рекомендации QA (QA Recommendations)

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

В этом разделе должна быть информация о следующем:

· Указан функционал (часть функционала), который заблокирован для проверки. Даны пояснения почему это функционал не проверен (указаны наиболее критичные дефекты)

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

· Если качество сборки ухудшилось, то обязательно должны быть указаны регрессионные места

· Наиболее нестабильные части функционала следует выделить и указать причниу, по которой они таковыми являются

· Даны рекомендации по тому функционалу и дефектам, скорейшее исправление которых является наиболее приоритетным

· Список наиболее критичных для сборки дефектов, с указанием названия и их критичности

· Для отчета уровня Smoke обязательно указать весь нестабильный функционал

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

· Дана информация о всех проблемах, характерных сборке. Проведен анализ, насколько оставшиеся проблемы являются критичными для конечного пользователя

· Указаны дефекты, которые следует исправить, чтобы качество конечной сборки было выше

Детализированная информация (Detailed Information)

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

Smoke

При оценке качества функционала на уровне Smoke теста, оно может быть либо Приемлемым, либо Неприемлемым. Качество сборки зависит от нескольких факторов:

· Если это релизная или предрелизная сборка, то для выставления Приемлемого качества на уровне Smoke не должно быть найдено функциональных дефектов

· Наличие нового функционала. Новый функционал, который впервые поставляется на тестирование, не должен содержать дефектов уровня Smoke для выставления Приемлемого качества всей сборки

· Чтобы установить сборке Приемлемое качество, не должно быть дефектов уровня Smoke у того функционала, по которому планируется проводить полные тесты

· Все наиболее важные части функционала отрабатывают корректно, тогда качество всего функционала на уровне Smoke может быть оценено, как Примлемое

В части о детализрованной информации качества сборки следует более подробно описать проблемы, которые были найдены во время теста.

DV

В этой части отчета указывается качество о проведении валидации дефектов.

Здесь должна быть следующая информация:

· Общее количество всех дефектов, поступивших на проверку

· Количество реджектнутых дефектов и их процент от общего количества

· Список дефектов, котоыре не были проверены и причины, по которым этого не было сделано

· Наглядная таблица с реджектнутыми дефектами

По вышеуказанным результатам выставляется качество теста. Если процент реджектнутых дефектов < 10%, то качество Приемлемое, если > 10%, то качество Неприемлемое.

NFT

При проведении полного теста нового функционала качество отдельно проверенного функционала может быть: Высокое, Среднее, Низкое

В отчете следует отдельно указывать информацию о качестве каждой части нового функционала. В этой части отчета должна быть следующая информация:

· Дана общая оценка реализации нового функционала (сгруппированная по качеству)

· Подробная (детальная) информация о качестве каждой из частей новой функциональности

· Проведен анализ каждой из новых функций в отдельности

· Даны ясные пояснения о выставлении соответствующего качества

· Даны рекомендации по улучшению качества (какие проблемы следует исправить)

· Показана таблица с новыми функциями (название), их качеством, статусом фуннкции из CQ

AT, MAT, Regression

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

Также как и у предыдущего вида тестов, качество этих может быть: Высокое, Среднее, Низкое

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

· Дана сравнительная характеристика каждой из частей функционала в сравнении с предыдущими версиями сборки

· Подробная (детальная) информация о качестве каждой из частей проверенной функциональности

· Даны ясные пояснения о выставлении соответствующего качества каждой функции в отдельности

· Даны рекомендации по улучшению качества (какие проблемы следует исправить)

Окончание содержимого

В завершении содержимое отчета должно включать в себя информацию следующего характера:

· Ссылка на тест-план, который находится на интранет

· Ссылка на документ feature matrix (если таковой имеется)

· Ссылка на документ со статистикой (если таковой имеется)

· Общее количество всех новых дефектов

· Подпись высылающего отчет

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

Уровни критичности дефектов

Подробное описание всех значений поля Severity вы можете найти в табл. 1 «Уровни критичности».

Обычно на проектах по тестированию используется 5 уровней критичности, однако названия этих уровней могут разниться в зависимости от особенностей системы управления дефектами. Для всех уровней приведено уточнение, в какой именно системе управления дефектами используется данный уровень. Если один и тот же уровень назван в разных системах неодинаково, названия уровней приведены через запятую.
Таблица 1 – Уровни критичности

	Название уровня критичности	Определение
	Blocker (JIRA, Bugzilla) Critical (корпоративная JIRA, CQ)	Дефект полностью блокирует работу приложения. Продолжать тестирование при наличии такого дефекта невозможно.
	Critical (JIRA, Bugzilla) Major (корпоративная JIRA, CQ)	Дефект частично блокирует работу приложения/одной или нескольких частей функциональности. Продолжать тестирование при наличии такого дефекта невозможно или возможно ограниченно.
	Major (JIRA, Bugzilla) Average (корпоративная JIRA, CQ)	Дефект нарушает нормальную работу одной или нескольких функций приложения, но не препятствует дальнейшему проведению тестов. Серьезный, очевидный дефект пользовательского интерфейса.
	Minor (JIRA, Bugzilla,корпоративная JIRA, CQ)	Несущественная функциональная ошибка или дефект графического интерфейса. Исправление незначительно улучшит поведение или выполнение сценария. Тестирование проводится согласно сценарию без каких-либо изменений.
	Trivial (JIRA, Bugzilla) Enhancement (CQ, Bugzilla, JIRA,корпоративная JIRA)	Дефект графического интерфейса, не вызывающий значительного ухудшения восприятия проекта пользователями. Мелкий дефект, не требующий обязательного исправления, или рекомендация, не предполагающая обязательного внесения изменений. Тестирование проводится согласно сценарию без каких-либо изменений.

Критерии определения критичности

В данном разделе описываются критерии, на которые ориентируется тестировщик при определении критичности дефекта. Критерии (табл. 2) являются частью стандарта, которого тестировщики должны придерживаться. Наличие критериев гарантирует, что процесс определения критичности дефектов соответствует требованиям компании.
Помимо указанных критериев, при определении уровня критичности дефектов тестировщику следует ориентироваться на целевую аудиторию проекта и сценарии его использования. Достаточно представить себя конечным пользователем проекта и определение уровня критичности облегчится – тестировщик может сам оценить, насколько важна ему та или иная ошибка проекта.
Таблица 2 – Критерии определения уровней критичности

Уровень критичности	Критерий
Blocker(блокирующий)	· Тестирование не может быть продолжено, проект неработоспособен. · В приложении типа "социальная сеть" невозможно войти под корректным пользователем · Установка приложения не завершается успешно
Critical(критический)	· Функции приложения недоступны или заблокированы. · Важные части системы в нерабочем состоянии. · Функция работает с серьезными нарушениями функциональных требований. · Основная задача приложения или его основной части не может быть выполнена. · Дефект нейтрализовать невозможно. · В результате возникновения дефекта произошла потеря данных. · Дефект существенно влияет на работу пользователя. · Нарушение нормальной работы серьезно влияет на системы заказчика, наносит урон его репутации, или нарушает положение о конфиденциальности информации. · Приложение невозможно установить. · Приложение после обновления не работает. · Механизм лицензирования продукта не работает.
Major (серьезный)	· Нормальная работа части приложения нарушена. Существует способ нейтрализации дефекта, но он недостаточно проверен и надежен. · Дефект вызвал серьезные функциональные или другие проблемы. · Причины отказа в работе точно не определены, но отказ имеет место быть, блокирует часть функциональности и воспроизводится всегда. · Функция выполняется некорректно, и это влияет на работу пользователя. · Ввод определенных значений в поле блокирует функцию. · Сохраняется только часть данных, и это влияет на работу других модулей. · Система игнорирует некоторые данные, и это влияет на основные функции. · Одна или несколько функций выполняются не полностью, что влияет на работу пользователя. · Результаты подсчетов некорректны (значительно отличаются).
Average (средний)	· Дефект не блокирует работу приложения. · Наличие дефекта не вызывает значительного ухудшения производительности, функционирования или удобства использования. · Существуют проверенные способы нейтрализации дефекта. · Дефект нарушает нормальную работу функции, но его можно быстро исправить проверенным способом. · Поведение функции частично соответствует сценарию. · Проверка правильности ввода данных не проводится или выдает неверные результаты либо тип данных, вводимых в поле, не соответствует требованиям. · Механизм навигации не работает должным образом. · Дефекты удобства использования серьезно влияют на работу пользователя. · Количество полей на форме не соответствует требованиям. · Функция работает недостаточно четко или не во всех случаях, но это серьезно не влияет на работу пользователя. · Одна или несколько функций выполняются частично (на работу пользователя это влияет незначительно).
Minor(незначительный)	· Дефект не влияет в значительной степени на точность или удобство выпускаемой версии. · Функция имеет несущественное значение или вообще не влияет на работу. · Опечатки, нечеткие формулировки или ограниченная область видимости сообщений об ошибках. · Названия полей, форм, таблиц и окон отличаются от указанных в сценарии. · Длина поля не ограничена или не соответствует требованиям. Сообщение об ошибке в этом случае не выдается. · Формат данных, отображаемых на форме, отличается от указанного в требованиях, но это не влияет на понимание смысла. · Не выдаются подтверждения, сообщения об ошибках или информационные сообщения. · Неверный порядок расположения столбцов на форме. · В аналогичных случаях отображаются разные сообщения. · В аналогичных случаях названия кнопок, форм, полей, окон и таблиц имеют отличия. · Текст сообщений не соответствует стандартам графического интерфейса или сценарию использования. · Табуляция не соответствует требованиям. · Не все файлы или другие установленные проектом объекты удаляются после удаления приложения. · Проверка полей не соответствует требованиям.
Trivial(несущественный)	· Опечатки, нечеткие формулировки или ограниченная область видимости сообщений об ошибках. · Названия полей, форм, таблиц и окон отличаются от указанных в сценарии. · В аналогичных случаях названия кнопок, форм, полей, окон и таблиц имеют отличия. · Текст сообщений не соответствует стандартам графического интерфейса или сценарию использования.
Enhancement(рекомендация)	· Рекомендации по улучшению качества. · Предложения по незначительному улучшению функциональности.

Правила изменения уровней критичности дефектов

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

· дефект обнаружен при тестировании на редко используемой операционной системе (Win2000);

· дефект трудно воспроизвести либо он был воспроизведен только единожды и не имеет четкого пути воспроизведения;

· дефект обнаружен в части приложения, редко используемой пользователями.

Повышать уровень критичности дефектов можно в следующих случаях:

· дефект графического интерфейса очевиден, и его легко обнаружить (например, орфографическая ошибка в хорошо обозримой части интерфейса), или обнаруженный дефект имеет негативные ассоциации и может восприниматься пользователем как оскорбление;

· дефект обнаружен в часто используемой и очень важной для пользователя части приложения;

· потенциально дефект может серьезно повлиять на работу пользователя.

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

Web Testing Check List (составлен Web Testing Team)

B - basic (только основные проверки, которые необходимо сделать при тестировании веб-проектов)

A - advanced (информация для полноценного тестирования элементов веб приложения)

· Web Testing Check List (составлен Web Testing Team)

· Поле (B)

· Кнопка (B)

· Радио баттон (B)

· Чек бокс (B)

· Поле со списком/выпадающий список (B)

· Меню (B)

· Окно (B)

· Скроллинг (B)

· Ссылка (B)

· Таблица (B)

· Поп-ап (B)

· Календарь (B)

· Поле для загрузки файлов (B)

· Сообщения (B)

· Общие проверки (A)

· Банк проверок (A)

Название Элемента	Functional Test	GUI Test
Поле (B)	· Обязательность ввода · Обработка только пробелов · Использование пробелов в тексте (1. пробелы в начале и в конце строки должны отсекаться при сохранении, 2. пробелы внутри текста отсекаться не должны) · Минимально/максимально допустимое количество символов (осуществлять проверку на ввод большого текста без пробелов не нужно) · Формат данных (исходя из его логического назначения и требований приложения) · Формат числовых данных (если допускаются): негативные, дробные с точкой и запятой, с точкой и запятой 123.123.123,00) · Ввод тегов и скриптов (проверка должна осуществляться только в пользовательской части - ввод тегов в админку для проверки их применения на фронте не производится. Введенные теги должны отобразиться в том же виде, в котором они были введены) · Использование специальных символов (введенные символы должны отобразиться в том же виде, в котором они были введены, если только ввод спец. символов не запрещен требованиями приложения) · Возможность редактирования введенных значений · Корректное распределение текста по строкам (переход на новую строку автоматически) · Уникальные данные (например, уникальность логина, email'а пользователя) · Автоматическая постановка курсора в первое поле для ввода при открытии формы	· Название поля (спеллинг, соответствие с открытым модулем или страницей) · Выравнивание названий полей (выравнивание по левому краю или правому краю (в зависимости от требований приложения, отступы, идентичность расстояний между названием и полем) · Корректное расположение текста внутри текста, длинный текст не выходит за границы поля при вводе · Унификация дизайна (цвет, шрифт, размер (высота/ширина), выравнивание полей) · Расположение вводимого текста внутри поля (унификация, выравнивание по нижнему краю (для textarea - по верхнему), если иное не определено специфичными требованиями приложения)
Кнопка (B)	· Отсутствие вызова одного и того же действия повторно при нажатии на кнопку несколько раз · Недоступные кнопки не скрыты, а заблокированы (если кнопка недоступна в данный момент, то она не должна пропадать с формы, пользователь должен знать ее существовании; но кнопка должна быть задизейблена - некликабельна и отображается более светлой) · Нажатие на пространство между близко расположенными кнопками не должно приводить к действию · Нажатие на пространство возле кнопки не должно приводить к действию · Должно работать нажатие на всю площадь кнопки, а не только по ее названию	· Название кнопки (спеллинг, соответствие с действием) · Эффект ‘нажатия’ (вид кнопки должен изменяться при нажатии, если это не противоречит возможностям браузера) · Название хинтов (соответствие с названием кнопки, спеллинг) · Унификация дизайна (цвет, шрифт, размер (высота/ширина), цвет подсветки, выравнивание). Проверка осуществляется как для кнопки, как элемента, так и для названия кнопки
Радио баттон (B)	· Функциональность (включение/выключение) · Не может быть меньше 2 радиокнопок · По умолчанию одна радиокнопка должна быть включена · Не может быть включено более 1 радиокнопки · При переходе на следующую страницу и возвращении назад выбранная радио кнопка не должна сбрасываться	· Унификация дизайна для всего приложения · Выравнивание расположения радиобаттона с соответствующим названием · Выравнивание расположений радио баттонов (по краю)
Чек бокс (B)	· Функциональность (включение/выключение) · Обязательность выбора хотя бы одного чекбокса · Наличие дополнительного чекбокса, выставляющего/снимающего все чекбоксы при наличии больше 10 чекбоксов · При переходе на следующую страницу и возвращении назад выбранный чекбокс не должен сбрасываться · Отсутствие функции сортировки таблицы по полю, которое содержит только чекбоксы	· Унификация дизайна для всего приложения · Выравнивание расположения чек бокса с соответствующим названием · Корректность отображения задисэйбленного чек бокса
Поле со списком/выпадающий список (B)	· Сортировка по алфавиту или по смыслу · В случае, если значения выходят за границы списка, и нет возможности увеличения размера списка, то необходимо отображение хинтов (всплывающих подсказок) · Выбор пункта списка по нажатии соответствующей первой буквы на клавиатуре · Возможность выбора нескольких значений для поля со списком · Возможность введения значений вручную (если это позволяет приложение) · Возможность выбора значния из списка указателем мыши либо стрелками с клавиатуры	· Спеллинг значений · Подсветка при выборе каждого из значений, при выборе нескольких значений одновременно · Унификация дизайна (цвет, шрифт, размер (высота/ширина), цвет подсветки, выравнивание). Проверка осуществляется как для поля, как элемента, так и для значений, и их названий
Меню (B)	· Осуществление соответствующего перехода при выборе пункта меню · Визуальное различие в момент работы на определенной вкладке (подсветка, подчеркивание)	· Подсветка таба при наведении курсора · Изменение курсора при наведении · Эффект ‘нажатия’, если это не противоречит возможностям браузера · Если работа в данный момент в выбранной вкладке, то в меню она отличается визуально, при этом является некликабельной · Совпадение названий в случае, если меню дублируется в нескольких местах
Окно (B)	· Возможность изменения размера окна браузера. Несколько способов сменить разрешение окна браузера при тестировании: · Сменить разрешение самого экрана. · Воспользоваться виртуалкой. · Воспользоваться расширениями для браузеров. · Возможность изменения масштаба страницы.	· Появление скролла при уменьшении (изменении) размера окна браузера · Сохранение расположения элементов при уменьшении (изменении) окна браузера, при изменении масштаба.Если дефект воспроизводится только при смененном масштабе, то в описании дефекта одним из шагов можно указать «увеличить/уменьшить масштаб до …%» · Соответствие названия окна в зависимости от назначения страницы (например, название окна должно быть Profile, если пользователь находится на странице профиля) · Спеллинг, синтаксис названий · Унификация названий
Скроллинг (B)	· Отсутствие скролла в случае, если текст вмещается на странице без прокрутки. · Соответствующее изменения текста при использовании скролла. · Возможность изменения положения скролла при помощи мыши, кнопок Page up/down, Home/End.	· Унификация видов и типов скроллов на всех страницах (если есть кастомный скролл, он должен быть применен на всех идентичных формах)
Ссылка (B)	· Функционирование ссылки (должен осуществиться переход на соответствующую страницу) · При наведении указателя мыши отображается подсказка (желательно) · Форматы ссылок и префиксов · Срабатывание ссылки только при клике на саму ссылку, а не на пустую область возле нее	· Унификация стилей (в соответствие с дизайном сайта) · Расположение ссылок (в соответствие с дизайном сайта). Например, расположение всех ссылок слева или справа от элементов · Названия (унификация, идентичность названий ссылок одинакового назначения, спеллинг, соответствие с открытым модулем или страницей, вместимость названия ссылки в отведенном блоке) · Измененение вида курсора при наведении на ссылку · Изменение вида ссылки при наведении курсора (подчеркивание)
Таблица (B)	· При появлении нескольких страниц есть кпопки Вперед, Назад, На первую, На последнюю страницу (пагинация) · Проверка сортировок (+ проверка сортировки по дефолту) · Проверка фильтрации (если есть возможность) · Апдейт значений таблицы после добавления/изменения/удаления данных · Единичное/множественное выделение нескольких значений	· Унификация дизайна для всего приложения (цвет, шрифт, размер (высота/ширина), выравнивание) · Название (соответствие с текущим модулем, спеллинг) · Выравнивание иконок сортировки в названии колонок · Выравнивание названий колонок, значений внутри таблицы · Корректное отображение длинных названий (соответсвующие переходы на новые строки, сокращение названий (появление..., либо сокращение по слову) · Корректное отображение данных после использования сортировки (размеры колонок и столбцов фиксированы, текст не разбивает структуру таблицы)
Поп-ап (B)	· Должен быть модальным · Корректное выделение background'а страницы (если фон страницы изменяется при появлении поп апа, то при изменении масштаба страницы фон должен заполнять всю страницу - размер измененного фона соответствует размеру страницы) · Фиксированное положение поп-апа (динамическое изменение положения) в случае использования скролла	· Cпеллинг, синтаксис текста, расположенного на поп-апе · Отображение поп-апа по центру страницы, окна, формы · Выравнивание текста, представленного на поп-апе · Корректное расположение текста на поп-апе: текст должен быть в рамках поп-апа, длинное название должно располагаться на новой строке, если иное не определено специфичными требованиями приложения
Календарь (B)	· При возможности ввода даты вручную необходимо проверить разные форматы · Проверки логичности ввода (даты в будущем, валидации возраста и т.д)	· Унификация дизайна для всего приложения (цвет, шрифт, размер (высота/ширина), выравнивание) · Отображение календаря рядом с полем · Корректное выравнивание всех элементов и ссылок в календаре
Поле для загрузки файлов (B)	· Обязательность выбора файла · Форматы · Ограничения на размер · При отсутствии изображений должен быть соответствующий thumbnail, либо картинка совсем не должна отображаться · Контроль за размером (высота/ширина), должен быть ресайз · Загрузка исполняемых файлов (EXE, PHP, JSP etc.). Переименованный EXE	· Унификация дизайна для всего приложения (цвет, шрифт, размер (высота/ширина), выравнивание) · Выравнивание названий загруженных файлов, самих thumbnails файлов
Сообщения (B)	· Пользователь должен быть информирован о действиях, происходящих в системе посредством сообщений об успешном завершении операции · На необратимые действия, такие как удаление, должны быть подтверждающие сообщения · Введенные в форму данные не должны сбрасываться после появления сообщения об ошибке	· Сообщение о том, что нет соответствующих айтемов (в таблицах, при поиске, при переходе на страницы) · Спеллинг, синтаксис сообщений · Соответствие сообщений по смыслу в зависимости от выполняемого действия · Соответствие названия требуемого действия в сообщении об ошибке действию, которое пользователь должен выполнить. Например, если необходимо выбрать значение из списка, в сообщении об ошибке должно быть указано ‘Please select’, а не ‘Please enter’ · Унификация стилей (цвет, размер) для всего приложения · Соответствие цветов типу сообщений (красный для сообщений об ошибках, зеленый для сообщений об успешном завершении операции), если данные цвета не противоречат специфичным требованиям приложения · Соответствие названий полей в сообщениях об ошибках и сообщениях об успешном завершении операции названиям полей, форм, таблиц, кнопок, и т.д. · Соответствие порядка выведения сообщений об ошибках в соответствие с порядком расположения полей, в которых были найдены ошибки · Поле, в котором содержится ошибка должно (желательно) выделяться цветом · Невалидное значение не должно отображаться в сообщении об ошибке. Пример как быть не должно: "Email 2309234@@mail.ru не соответствует допустимому формату”. · Согласование числительного и связанного с ним существительного должно соблюдаться. Например, "1 день", "2 дня", "5 дней".
Общие проверки (A)	· Перед тестированием каждой новой сборки необходимо осуществить очистку кэша и кукис. Для полной очистки кэша и куки можно воспользоваться приложением Ccleaner. · 404 Error (переход по некорректному урлу должен вести на страницу с 404 ошибкой, а не просто на страницу Page cannot be found. страница 404 ошибки должна быть реализована в общем дизайне тестируемого приложения) · Tab order (сверху вниз слева направо). Поля, доступные для прочтения и задисэйбленные должны пропускаться · Logo должен быть ссылкой на главную страницу · Фокус на кнопке для исполнения действий (ввод данных -> нажатие Enter -> действие осуществилось) · Проверка Breadcrumbs ("Хлебные крошки" - элемент навигации, являющийся признаком удобства пользования сайтом в целом и перемещением по его структуре) · Отображение flash-элементов при отключенном/неустановленном в браузере flash-плеере (пользователю должно быть предложено скачать и установить последнюю версию flash-плеера; на месте flash-объекта должно отображаться альтернативное изображение) · Проверка работоспособности отправки email нотификаций (как админу, так и пользователю), если только отсутствие писем не является спецификой проекта · Проверка работоспособности приложения при отключенном JavaScript. Основная функциональность и навигация должна работать. Подробное описание того, как отключить JavaScript и на что обращать внимание, находится здесь. · Тестирование ссылок и прав доступа. Подробнее здесь. · Всегда проверять взаимосвязь компонентов. Обращать внимание на то, как ведет себя один компонент при изменении/удалении другого. Например, при удалении категории товара не должны удаляться все товары в этой категории.	· Уменьшение/увеличение масштаба страницы (элементы должны соответственно перераспределиться с сохранением пропорций) · Уменьшение/увеличение размера окна браузера (элементы должны соответственно перераспределиться с сохранением пропорций, взаиморасположение должно сохраняться)

Банк проверок (A)

Расширенный список возможных проверок для каждого элемента веб страницы для полноценного тестирования веб приложения

Дата добавления: 2015-10-23