Как сделать чек лист тестирование

Обновлено: 07.07.2024

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

Как же мы в Prozorro тестируем наш сайт или его доработки? Давайте разберем пошагово и посмотрим весь флоу.

Перед тем как тестировать сайт, нужно сначала протестировать макеты сайта.

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

Где может быть создан макет

Есть множество ресурсов для создания макетов, но, пожалуй, самый популярный для дизайнера — это Figma .

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

Зачем тестировать дизайн-макеты сайта

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

Примеры коммуникативных задач нашего портала Prozorro :

показать, что компания работает в сфере госзакупок;
показать основные направления в сфере госзакупок;
показать партнеров, с которыми мы сотрудничаем (тендерные площадки);
показать прозрачность в сфере госзакупок.

Этапы тестирования:

тестирование функциональности;
проверка юзабилити сайта (удобство использования);
тест производительности;
проверка на безопасность;
тестинг интерфейса (UI User Interface. Когда нужно убедиться, что все компоненты системы правильно взаимодействуют друг с другом. Testing).

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

Давайте на примере посмотрим на блок функционального тестирования и составим чек-лист:

Поговорим о юзабилити-тестировании

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

Основная цель юзабилити-тестирования:

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

Чек-лист тестирования сайта на юзабилити:

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

UI Testing: тест пользовательского интерфейса

Не стоит путать тестирование интерфейса с проверкой юзабилити. Это два разных этапа общего теста.

UI-тест проверяет соответствие графического интерфейса сайта.

Чек-лист тестирования интерфейса:

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

Регрессионное тестирование

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

Тестирование покажет, затронули новые фичи старый функционал или нет

Чек-лист регрессионного тестирования:

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

Подводим итоги

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

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

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

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

Чек-лист функционального тестирования

№1 — Тестирование всех форм

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

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

Тестирование валидации всехобязательных полей.

Тестирование форм обратной связи и корректная работа ссылок для пользовательского соглашения.

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

Вот только на что обращать внимание при тестировании? Есть набор основных характеристик, которыми должна обладать хорошая документация:

Полнота
Однозначность
Непротиворечивость
Необходимость
Осуществимость
Тестируемость

Конечно, их может быть и больше. Кто-то использует мнемонику CIRCUS MATTA, кто-то расширяет список под себя и команду. Но эти шесть характеристик — основные. О них и в книгах по тестированию пишут, и в самых разных статьях.

В этой статье я расскажу о каждой из них поподробнее, с картиночками и примерами из жизни.

1. Полнота

Все ли описано? Ничего не забыли? Вдруг у нас остался неописанный функционал или параметр API-метода?

Чтобы проверить этот пункт, просто напишите чек-лист проверок функционала. Вот как начали читать ТЗ, сразу записывайте тесты. Важно именно писать, а не просто прикидывать в уме. Иначе что-то обязательно забудете.

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

Плюс иногда можно пропустить очень важный вопрос, который трудозатратно делать. А ТЗ, напомню, уже согласовано. Так что всё, что продолбали на этапе согласования, делаем за свой счет.

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

2. Однозначность

Требования должны трактоваться всеми одинаково.

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

Налицо конфликт интересов. И ведь каждый будет тыкать в ТЗ для отстаивания своей позиции. Лучше конкретизировать:

Отчет за год должен загружаться не более секунды.
Отчет за весь период времени должен загружаться не более 5 секунд.

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

Аналитик будет думать, что там будет значение 0. Деньги же, цифра!
Разработчик сделает пустое поле, не указано ведь ничего! А это что-то сломает.

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

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

Если это внутренний документ, а у вас сильная команда — можно не расписывать подробно.

3. Непротиворечивость

Требования не должны противоречить сами себе. Такое обычно бывает, когда требований много. Аналитик просто забывает, что уже писал про параметр и снова придумывает его поведение. Иногда придумывает немного по другому.

Например, есть страница нефункциональных требований, где написано, что любая страница должна грузится не более 3 секунд. Аналитик пишет ТЗ на новый модуль отчетности, который использует много данных и сложные формулы. И он пишет, что отчет может грузиться вплоть до минуты. Явное противоречие!

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

4. Необходимость

Круто, когда документация полная. Но это не значит, что простой функционал надо растечь на 10 листов А4. Когда документации много, сложно проверить полноту, сложно удержать в голове, о чем уже говорил, не повторяться и не противоречить самому себе.

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

Пишите только то, что необходимо:

В ТЗ — функционал, основной сценарий и альтернативы, типы ошибок.
В пользовательской документации — то, как пользоваться системой. Но не доходя до крайностей и обучения включению компьютера.

5. Осуществимость

А можно ли реализовать то, что тут написано? Насколько это будет сложно и дорого?

Васю: домашний адрес с улицей Ленина.
Петю: домашний адрес с переулком Турчанинов и рабочий с улицей Ленина.

поиск по любому полю;
поиск по конкретному полю;
множественный поиск по конкретному атрибуту (в одном адресе проверить и тип, и улицу);
.

Когда данных с гулькин нос, это неважно. А когда их миллионы, нужно искать баланс. И такой выбор возможностей поиска — это именно компромис для скорости и потребляемых ресурсов под сценарии использования.

Осуществимо желание отсеять Петю? Да. Но это просто не нужно. Потому что вреда принесет больше, чем пользы. Ради того, чтобы в выборку из 1000 человек не попали 10 лишних, платить несколько миллионов за дополнительные мощности серверов смысла просто нет.

6. Тестируемость

Можно ли протестировать этот функционал?

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

Если в компании принято все покрывать автотестами, то это станет проблемой. Может, разработчик прочитает ТЗ и сам поймет, что ещё фреймворк тестов дорабатывать надо. А может, он не вспомнит об этом. И тогда ваша задача — вспомнить. Чтобы сразу заложить время на доработки.

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

При этом бывает и так, что тестировать все равно придется разработчику. Скажем, когда делают рефакторинг, что может проверить тестировщик? Только регресс провести, посмотреть, что ничего не отломалось. А если есть автотесты, то это проверят они =)

Однако если тесты (авто или ручные) прошли успешно, это ещё не значит, что рефакторинг прошел хорошо. Сама суть рефакторинга — переписать код, чтобы он был более оптимален и читабелен. Чтобы его было легче поддерживать в дальнейшем и интегрировать с другими частями системы.

И именно это и надо проверить! А проверить это может только разработчик. Он и выполняет тестирование в данном случае.

Бонус: мнемоника CIRCUS MATTA и другие доп материалы

CIRCUS MATTA — мнемоника для ревью пользовательских историй. Это как раз про тестирование требований! Истории должны обладать качествами:

Completeness — полнота
Independent — независимость
Realisable — реализуемость
Consistency — консистентность
Unambiguity — однозначность
Specific — специфика заказчика
Measurable — измеримая
Acceptable — приемлемая
Testable — тестируемая
Traceable — трассируемая (можно проставить взаимосвязи)
Achievable — достижимая

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

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

Функциональное тестирование

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

Что проверяем?

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

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

Тестирование совместимости

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

Что проверяем?

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

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

Кросс-платформенное тестирование

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

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

Что проверяем?

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

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

Тестирование безопасности

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

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

Что проверяем?

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

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

Тестирование локализации и глобализации

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

Что проверяем?

У каждой локации, как и у ее жителей, есть определенные особенности, которые отличают ее от других и должны быть учтены при разработке приложения:

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

Тестирование удобства использования

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

Что проверяем?

Говоря об удобстве использования приложения необходимо упомянуть несколько моментов для проверки:

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

Тестирование производительности

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

Что проверяем?

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

Performance: проверяем скорость реакции системы при определенных заданных показателях нагрузки;
Load: проверяем, выдерживает ли система различные нагрузки с одинаковой производительностью, начинаем с минимума и постепенно доводим до обусловленных показателей, проверяем запас прочности;
Volume: применяется по большей части к базам данных приложения, проверяем, какой объем информации они способны выдерживать и корректно обрабатывать;
Stability: некая проверка на прочность, как долго система сможет показывать достаточно высокий уровень производительности при стабильной нагрузке, убеждаемся, что нет сбоев;
Scalability: масштабируемость - это фактор, который может пригодиться не сразу, но его стоит предусмотреть, что если вы оставите меньше серверов для обработки, или наоборот добавите, любые изменения в масштабах системы не должны уменьшать производительность;
Stress: стрессовое тестирование проверяет систему как бы “за рамками” возможного, и относится ко всем вышеперечисленным типам. Поэтому мы рассмотрим его отдельно.

Стрессовое тестирование

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

Что проверяем?

Проводя стрессовое тестирование важно уделить внимание предельным возможностям системы по каждому из видов производительности:

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

Выводы

Mobile App Testing - обязательный и необходимый этап в разработке приложений, если вы хотите достичь максимальных результатов. Обнаружение и исправление ошибок - не единственная задача тестирования. Необходимо уделять достаточно внимания всем функциям, а также нефункциональным характеристикам программных продуктов, тогда тестирование сможет обеспечить высокий уровень качества.

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

Мы в компании Wezom всегда проводим тестирование начиная с ранних этапов разработки продукта, чтобы минимизировать риски и максимизировать качество результата.

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

Оставьте ваши контактные данные. Наш менеджер свяжется и проконсультирует вас.

Читайте также: