чек лист что это такое в тестирование
Как составить Чек-лист? Для начинающего тестировщика.
Все очень часто слышат про Тест-кейсы и как их оформлять, но не так много времени уделяется Чек-листам, что это такое? Зачем это нужно? И как с этим жить?
Начнем с того, что назначения у тест-кейсов и чек-листов одинаковое, это проверка продукта. Однако есть два основных отличия:
1 Чек-лист описывает кратко, что нам нужно протестировать и результат, Тест-кейс наоборот старается более детально рассказать о тестировании данного функционала.
2 Объем проверяемого функционала, за короткий промежуток, мы можем быстрее проверить продукт, чем Тест-кейсами.
Название функционала, отдельного элемента продукта (Например: Поле поиска)
3 Краткое описание теста
Буквально небольшое описание действия или пункта.
Например: Ввести пароль латиницей
Я выделил основные 3 пункта, можно добавить еще увеличить уровень подзаголовков, для полного удобства и понимания архитектуры проекта, но это уже зависит от вас и вашего объекта тестирования.
Пример Чек листа в XLSX формате
Давайте вместе взглянем на сайт lensgo.ru
И попробуем составить чек-лист с помощью Excel.
Закиньте что-нибудь в корзину и перейдите в нее, а далее к оформлению товара.
У вас должна отобразится страница по адресу https://lensgo.ru/basket/order/
Писать Чек-лист мы будем по форме “Данные о покупателе”
1 Напишем в шапке Чек-листа, Название и описание.
Чтобы другие тестировщики и ты сам смог быстро понять о чем этот Чек-лист.
2 Далее по каждому полю составляем краткий список проверок, результатов и еще проставляем приоритет. Каждая проверка проверяет один пункт, но может проверять и комбинации нескольких пунктов. Составлять список проверок нужно с помощью техник тест-дизайна, без них может получится огромный список тестов:
1 Граничные значения
2 Классы эквивалентности
можно прочитать про это в этих статьях:
Возьмем поле ФИО и составим группы проверок, а в них уже напишем списки проверок с помощью техник тест-дизайна. Немного подумав вычисляем, что можно создать три группы ( Проверка длины поля, Проверка поля на кириллице “ФИО”, Проверка поля на английском “ФИО”) учитываем также, что интернет-магазин ориентирован на Россию.
Вот загруженный пример, но попробуйте без скаченного примера составить проверки для поля “Телефон” и потом сравнить ваши тесты с моими.
Пример Чек листа в Sitechco
Есть огромное количество онлайн сервисов для составления чек-листов, но один из наиболее подходящий для тестировщиков это sitechco.ru
Где вы удобно можете расположить свои проверки, радует еще то, что интерфейс интуитивно понятен и можно быстро редактировать тесты. Еще имеется запуск тестов, отчеты по их прохождению и тест планы, все это очень облегчит вам жизнь при тестировании проекта.
И так вы узнали как можно составить чек-листы для тестирования вашего продукта, надеюсь, что моя статья вам помогла.
Чек-листы в тестировании: что нужно знать тестировщику!
Из этого материала вы узнаете что такое чек-листы, зачем они нужны, как их составлять, когда применять. Поговорим мы и об их преимуществах и недостатках.
Что такое чек-лист?
Важность чек листов трудно переоценить. Каким бы опытным ни был сотрудник, в спешке он может легко забыть важную деталь.
В тестировании чек-лист — это список проверок для тестирования продукта. Чек-листы устроены предельно просто. Любой из них содержит перечень блоков, секций, страниц, других элементов, которые следует протестировать, например:
Выполненные пункты отмечаются статусами, например: “Passed”, “Failed”, “Blocked”, “Skipped”, “Not run”. Эти статусы также могут иметь свой цвет:
Преимущества использования чек-листов:
Разновидности чек-листов
Можно выделить два вида чек-листов: специальные и универсальные.
Специальные чек-листы создаются и используются для конкретных проектов, поэтому пункты такого чек-листа соответствуют специфики проекта. Тестировщик по специальному чек-листу проверяет возможность выполнить уникальное действие, предусмотренное требованиями. Вот примеры пунктов специального чек-листа:
Такие чек-листы не подходят к использованию на других проектах.
Универсальные чек-листы подходят для тестирования проектов одного типа. Проверка по универсальному чек-листу не привязывается к графическим элементам или конкретной реализации, а проверяется сама возможность пользователя выполнить действие. Для универсального чек-листа составляется абстрактный список проверок. Пункты универсального чек-листа могут быть такими:
Универсальные чек-листы можно использовать повторно на проектах одного типа. У многих агентств есть такие универсальные чек-листы, по ним определяется общий уровень качества продукта.
Как составлять работающие чек-листы
Чтобы составить работающий чек-лист, обратите внимание на эти рекомендации:
Преимущества и недостатки чек-листов
Чек-листы лучше применять на ранних этапах, когда софт быстро меняется, потому что тест-кейсы дорого поддерживать.
Тестирование приложений: описание и чек-лист
В этой статье изложен опыт компании Infoshell по тестированию приложений. Речь пойдёт о тестировании в спринте и в проектной работе, предрелизном тестировании и других вопросах.
Тестирование в спринте
В первый день спринта (выделенного на одну функцию или часть продукта периода) необходимо создать тест-кейсы и автотесты. Или отредактировать их, если текущий спринт не первый в цепочке.
Текст-кейс и автотест
Тест-кейс — это документация тестировщика. Это список действий, который нужно совершить, чтобы достичь поставленной цели. Он включает в себя, в среднем, 5 пунктов:
Положительный — фактический результат равен ожидаемому. Отрицательный — если не равен и была найдена какая-то ошибка. «Тест блокирован» — невозможность выполнения шагов. Это означает ошибку, которую необходимо найти и указать в результате.
По желанию в текст-кейс можно добавлять другие пункты. Например, историю редактирования, в которой нужно указывать, кем и когда этот кейс был изменён, что было убрано или добавлено.
При этом в тест-кейсе не должно быть нечётких формулировок, лишних деталей и описаний, умалчиваний или неточностей в описании шагов и результата. Ещё одно важное условие — каждый кейс должен быть независим от остальных. Держите это в голове, так как тест-кейсы и автотесты пишутся на каждую функцию, и начать связывать их автоматически очень легко.
Автотест — код, который пишет разработчик для проверки работоспособности приложения. Позволяет не только сэкономить время на поиск и исправления багов, но и увидеть конкретную строчку кода с ошибкой.
Тест-кейсы и автотесты нужны для того, чтобы проверить, как продукт будет вести себя при разных действиях пользователя: ожидаемых и неожиданных, логичных и нелогичных, правильных и неправильных.
Также полезно Гид по профессии тестировщик: чем занимается специалист в сфере QA, сколько зарабатывает, что надо знать и где учиться.
Тестирование функциональности
В большинстве случаев это тестирование проводится вручную. Этапа три, они идут по порядку:
Дымовое тестирование. Цель — проверить базовую функциональность приложения. Продумайте поведение пользователя, затем начните тестировать приложение. Сделайте позитивный тест и выполните целевое действие. Пусть это будет подписка на email-рассылку.
После него начните тест негативный: попытайтесь «обмануть» программу, кликайте на разные кнопки, иконки, изображения и отслеживайте, как она реагирует на ваши действия. Продукт не должен открывать никаких лишних окон, картинок. Он также не должен давать никакой информации при нажатии «в пустоту».
Если всё прошло хорошо, переходите к следующему этапу. Если хотя бы в одном из этих тестов вы нашли ошибку, приложение нужно отправить на доработку с описанием обнаруженных багов в баг-репорте. Назначьте задачу на исправление и ждите устранения ошибки, после чего повторите дымовое тестирование.
Регрессионное тестирование
Необходимо для того, чтобы проверить, исправили ли разработчики найденные баги. Ещё одна цель регрессионного тестирования — отслеживание того, как внесённые изменения повлияли на работу других частей приложения и его поведение в целом.
Сэм Канер, профессор программной инженерии Технологического института, директор Образовательного и исследовательского центра тестирования программного обеспечения Флориды, выделяет три основных типа этого теста:
Полное тестирование по тест-кейсам. На третьем этапе тестировщик проверяет все функции, которые описаны в его тест-кейсах. Когда результат по каждому из них будет положительным, тестирование можно считать оконченным.
Тестирование в проектной работе
В проектной работе применяют преимущественно регрессионное тестирование. Это обусловлено тем, что тест в данном случае проводят на заключительных этапах. Предположим, запланировано четыре спринта. Тогда тестировщик включается после третьего.
Особое внимание при тестах в проектной работе стоит уделить тестированию взаимодействия. Это функциональный тест, который проверяет способность продукта взаимодействовать с компонентами или системами: от одного и больше. Оно включает в себя тестирование совместимости и интеграционное тестирование.
Тестирование совместимости — нефункциональный тест, цель которого — проверить, корректно ли работает приложение в определённом окружении. Это может быть аппаратная платформа, различные ОС, браузеры и расширения.
Интеграционное тестирование — фаза теста ПО, где отдельные модули программы объединяют и тестируют в группе. Интеграционное тестирование можно автоматизировать с помощью систем непрерывной интеграции (например, Jenkins, TeamCity, Travis CI, Gitlab CI, Circle CI, GoCD или другие).
Предрелизное тестирование
Это особенный, наиболее важный спринт и тестирование. Перед релизом продукт необходимо «прогнать» ещё раз, чтобы убедиться в отсутствии багов (по крайней мере, больших) наверняка.
Сначала нужно провести регрессионное тестирование. В идеале процесс разработки должен быть построен так, чтобы для теста перед релизом оставались только мелкие функции, баги которых не требуют много времени для устранения. Также важно учитывать, чтобы возможные исправления не могли повлиять на другие части продукта и его поведение в принципе. Ведь исправлять всё перед релизом попросту некогда.
Если процесс был спланирован правильно, регрессионное тестирование ограничится проверкой случайных изменений в коде с прошлого спринта. Если нет — случиться может всё, что угодно. Но вероятность того, что вы спокойно завершите работу над приложением в срок, крайне мала.
После регрессионного начинайте тестирование внедрённых багфиксов (исправленных ошибок). Сейчас тестировщик должен проверить, есть ли какие-то негативные последствия от исправления багов, найденных с помощью регрессионного теста, или нет. А также были ли эти ошибки вообще исправлены разработчиками.
Затем идёт тестирование интеграции патча (код, который добавили разработчики для устранения ошибок). Фактически, это тест результата двух предыдущих этапов. Тестировщик пытается понять, не вредит ли патч приложению, и насколько хорошо он «встал» в систему. Помимо патчей на данном этапе проверяют все дополнения, которые были внесены в проект за последнее время. Для этого используются юнит-тесты.
Юнит-тест — автотест для небольшой части кода, которая отвечает за конкретную функцию приложения. Юнит-тесты подают значения. Тест считается пройденным, если программа обрабатывает их верно — так, как было задумано тестировщиком. Если реакция приложения не совпадает с запланированной, тест считается не пройденным. Но разработчики понимают, в какой части кода находится ошибка, и исправляют её.
Это не вся польза юнит-тестов. Они могут очень помочь в борьбе с багами после обновлений. Ведь возвращение к старому коду требует много времени на разбор и сравнение его с новым, а юнит-тест покажет область проблемы сразу.
Последний этап — это финальное тестирование продукта. Оно включает в себя проверку всех функций приложения с учётом спецификации или бэклога, которую команда согласовала с заказчиком.
Начните изучать разработку с бесплатного курса «Основы современной вёрстки». Вы научитесь создавать статические веб-страницы, стилизовать элементы, использовать редакторы кода с полезными расширениями. В конце курса вы опубликуете свой первый сайт на GitHub Pages.
Тестирование на поддержке
Это тестирования, которые происходят после релиза продукта. Они нужны только в том случае, когда заказчик попросит добавить новый функционал или договорится с компанией о дальнейшем обслуживании приложения и исправлении новых багов.
Во время тестирования на поддержке нужно проверять сборку: основной функционал после обновлений. Когда тестировщик обнаружит баг, он должен описать его. Дальнейшая работа над проблемой будет происходить по принципу тестирования во время спринта.
Вывод и чек-лист
Важно придерживаться единообразия стандартов, так как это залог стабильной работы отдела тестировщиков. Мы используем описанные выше методики и принципы, чтобы оптимизировать все процессы, экономить время и силы сотрудников, упрощать разработку и не позволять багам проникать в пост-релиз.
Для удобства можно использовать в работе чек-лист.
Статью подготовил Дмитрий Котенко, генеральный директор Infoshell. Мнение администрации «Хекслета» может не совпадать с мнением автора.
Никогда не останавливайтесь: В программировании говорят, что нужно постоянно учиться даже для того, чтобы просто находиться на месте. Развивайтесь с нами — на Хекслете есть сотни курсов по разработке на разных языках и технологиях
С нуля до разработчика. Возвращаем деньги, если не удалось найти работу.
Чек лист что это такое в тестирование
Допустим, вы имеете общее представление о тестировании, ознакомились с основными терминами и примерами. Но, когда дело доходит до конкретного случая, не знаете, с чего начать и за что взяться. Как вообще проверять продукт, пусть даже и вручную? Как не забыть что-то важное? Для этого существуют чек-листы. Сегодня мы о них и поговорим.
Что такое чек-лист?
Чек-лист – это базовый инструмент тестирования, который поможет вам не забыть о важных тестах, отслеживать прогресс и результат работы. Обычно он выглядит как таблица-список возможных проверок составляющих продукта: страниц, блоков и прочих элементов. Пункты такого списка должны быть минималистичными и предельно понятными. Обязательными столбцами являются версии операционных систем и браузеров, так как в них продукт будет вести себя по-разному. Также стоит отметить, что чек-лист – это уникальный список, создаваемый под конкретный продукт. Под другой продукт применять его будет уже неверно.
Одна строка чек-листа должна отражать одно действие, описанное глаголом в начальной форме. Например:
Смешивать и соединять две операции (действия) в один пункт нельзя.
Каждый пункт должен описываться с помощью глагола, а не существительного. Так будет понятно конкретное, а не абстрактное действие для проверки.
При выполнении пункта чек-листа в столбце статуса отмечается этап проверки, например, Passed (пройден) или Failed (не пройден). В последнем случае можно добавить комментарий о багах. Также суествуют статусы Not run (тест пока не проводился) и Blocked (проверка заблокирована).
Ниже представлен один из базовых примеров чек-листа:
Статус Passed зеленым цветом показывает, что проверка успешно пройдена.
Если же статус – Failed, желательно добавлять в примечания ссылку на баг-репорт.
Плюсы чек-листов:
Насколько детальным будет чеклист, зависит от требований к отчетности, уровня знания продукта сотрудниками и сложности продукта.
Подробнее о чек-листах мы рассказываем на курсе ПОИНТ, который стартует 16.11. Присоединяйтесь, чтобы попрактиковаться в составлении чек-листов и получить множество других полезных знаний о тестировании, которые помогут вам быстро найти работу в индустрии. Курс ПОИНТ ориентирован на практику: вас ждет 17 вебинаров и 17 практических заданий, за время которых вы освоите все нюансы профессии!
Отзывы наших студентов о ПОИНТ:
Прекрасный курс для тех, кто желает освоить специальность тестировщика. В рамках курса дано представление о том что такое тестирование и достаточно заданий для закрепления практических навыков. Преподаватели на связи и всегда готовы объяснить непонятные или вызвавшие затруднение моменты.
Вход в портал мира тестирования ПО! 😅 Подробный, структурированный курс. Построен от простого к сложному (и очень сложному). Постепенное овладение теоритическими знаниями, навыками работы с различными инструментами и техниками тестирования. Хороший фундамент для освоения специальности тестировщика.
Чек лист тестирования сайта
Что подразумевается под чек листами в тестировании? Чек-лист тестирования сайта — это список проверок, которые выполняет тестировщик при тестировании веб-сайта. В данной статье рассмотрим, как составить чек лист тестирования, а также приведем список готовых чек листов тестирования.
В статье будут рассмотрены чек листы, связанные только с веб-тестированием (чек листы для тестирования АПИ или чек листы для тестирования мобильных приложений здесь рассматриваться не будут).
Многие тестировщики (и не только) задаются вопросами: как выглядит чек лист тестирования? Как написать чек лист для тестирования веб-сайта? Как писать чек-лист тестирования сайта? Как правильно его составить? В этой статье мы постараемся ответить на все эти вопросы и дадим примеры (образцы, шаблоны) готовых чек-листов тестирования сайта с готовым оформлением и структурой.
➀ Составление чек листа
Давайте поговорим о том, как правильно составить чек лист для тестирования сайта. Сначала нужно определиться с объектом тестирования. Например, у нас объектом тестирования может быть сам сайт. Разделяем сайт на несколько областей. К примеру, разделить можно следующим образом: меню, основная часть сайта и подвал сайта. И начинаем писать чек лист. После того, как мы написали чек лист, можно его оформить в виде списка, таблицы, определить структуру, нумерацию, как он будет выглядеть. Таким образом мы можем составить чек лист тестирования сайта.
Ниже мы рассмотрим на шаблоны (образцы), как могут выглядеть чек листы тестирования сайта на разные случаи жизни, иногда даже пробуют проводить тестирование на основе чек листов.
➁ Готовые чек листы тестирования
➁.➀ Чек лист функционального тестирования
☑ Сайт открывается и доступен.
☑ При попытке повторно открыть сайт, он открывается и доступен.
☑ Все кнопки на сайте нажимаются.
☑ Все ссылки на сайте открываются.
☑ На сайте нет битых ссылок.
☑ Проверить все формы на сайте.
☑ Проверить валидацию всех обязательных полей.
☑ Знак звездочки есть у всех обязательных полей.
☑ Проверить валидацию для всех необязательных полей.
☑ Проверить основные элементы сайта.
☑ Проверить работу меню.
☑ Проверить, что загруженные документы открываются правильно.
☑ Отправка форм работает корректно.
☑ Проверить, что будет, если удалить куки, находясь на сайте.
☑ Проверить, что будет, если удалить куки после посещения сайта.
☑ Все данные в списках в хронологическом порядке.
➁.➁ Чек лист тестирования верстки
☑ Кодировка UTF-8.
☑ Шрифты прогружаются и работают.
☑ Нет ошибок HTML и CSS.
☑ Проверить элементы на разных разрешениях экранов.
☑ Проверить кнопки на разных страницах.
☑ Формы при сворачивании окна.
☑ Проверить верстку в разных браузерах.
☑ Проверить, что нет больших комментариев в коде.
☑ Есть favicon на сайте.
➁.➂ Чек лист смоук тестирования
☑ Сайт открывается и доступен.
☑ Основные элементы сайта работают корректно.
☑ Нет ошибок в консоли.
☑ Нет битых ссылок.
☑ Основные страницы сайта открываются и работают.
☑ Нет видимых ошибок на главной странице.
➁.➃ Чек лист формы регистрации (логина, пароля)
☑ Можно заполнить поля формы.
☑ После нажатия на кнопку отправить происходит отправка формы.
☑ Письмо отправляется на почту после регистрации.
☑ Поля передаются в запросе.
☑ Проверить валидацию обязательных полей.
☑ Проверить валидацию необязательных полей.
➁.➄ Чек лист интернет магазина
☑ Наличие кнопок Купить, Заказать.
☑ Можно положить товар в корзину.
☑ После заказа приходит письмо на почту.
☑ Есть фильтры для поиска товаров.
☑ Есть форма обратной связи.
☑ Есть раздел с контактами.
☑ Есть ссылки на социальные сети.
☑ Строка поиска находится на видном месте.
☑ Присутствуют хлебные крошки.
☑ Отсутствуют опечатки.
☑ Проверка возможностей личного кабинета.
☑ Легко найти нужный товар.
☑ Нет дублирующихся товаров.
➁.⑥ Тестирование мобильной версии
☑ Сайт открывается в мобильной версии сайта.
☑ Пройтись по пунктам «Чек лист функционального тестирования».
☑ Пройтись по пунктам «Чек лист тестирования верстки».
☑ Пройтись по пунктам «Чек лист смоук тестирования».
☑ Пройтись по пунктам «Чек лист формы регистрации».
☑ Если интернет-магазин: пройтись по пунктам «Чек лист интернет-магазина».
☑ Проверить мобильную версию с поворотом экрана (горизонтальный и вертикальный вид экрана).
☑ Проверить в разных браузерах телефона.
☑ Проверить на разных телефонах.
➁.⑦ SEO чек лист
☑ Проверить, что нет запрета индексации в файле robots.txt.
☑ На всех страницах есть ровно один тег H1.
☑ Сайт на протоколе HTTPS.
☑ На сайте есть favicon.
☑ На сайте есть sitemap.
☑ Нет дублирующихся страниц.
☑ Есть хлебные крошки.
☑ Настроены ЧПУ.
Список чек листов представлен в ознакомительных целях. Готовые чек листы могут помочь при тестировании сайтов, а также служить источником вдохновения для новых идей.