чит лист в тестировании это
Чит лист в тестировании это
Как я использовала чит-листы и узнала за день тестирования больше нового, чем за 3 прочитанные книги
Книги, к слову, тоже оказались полезными, но тут главный герой не книги, а чит-листы.
Как я их использовала — по большей части при тестировании незнакомых мне продуктов, потому что когда продукт тебе знаком, ты знаешь все “трещинки”, все поля ввода, ошибки, ямки в коде продукта и с каким выражением лица лучше данные вводить (но это не точно). Бывали случаи, когда чит-листы в моей команде применялись и на знакомых продуктах и, ребята, там столько всего находилось из разряда фантастики!
Как я использовала чит-листы? Внимайте, ребятки.
Шаг первый: гуглить чит-листы! А нагугленное бережно собирать себе в личную коллекцию на все случаи жизни: контрольные списки интерфейса, проверки числовых полей, проверки текстовых полей, email и даже можно разжиться парой листиков по тестированию безопасности.
Шаг второй: хватит это терпеть! Я прыгала из документа в документ, чит-лист один, чит-лист другой, “крутится-вертится шар голубой!” Часть проверок повторялась, я решила — хватит это терпеть!
Шаг третий: пиши, сокращай! Я решила, что нужно оптимизировать это безобразие и сгруппировала проверки в табличку по типам, так стало намного удобнее — каждая вкладка моей таблицы отвечала за тестирование какого-то определенного типа поля, число, текст, а рядом с каждой проверкой стоял статус — прошло или не прошло.
Кому-то сильно интересно сейчас, почему я пою хвалебные оды такому простому инструменту? Чего же в них такого хорошего, в чит-листах? А вот чего:
Агеева Нина, тренер ПОИНТ
П.С. Вот такие классные штуки делают студенты нашего первого потока ПОИНТ
Чек-листы в тестировании: что нужно знать тестировщику!
Из этого материала вы узнаете что такое чек-листы, зачем они нужны, как их составлять, когда применять. Поговорим мы и об их преимуществах и недостатках.
Что такое чек-лист?
Важность чек листов трудно переоценить. Каким бы опытным ни был сотрудник, в спешке он может легко забыть важную деталь.
В тестировании чек-лист — это список проверок для тестирования продукта. Чек-листы устроены предельно просто. Любой из них содержит перечень блоков, секций, страниц, других элементов, которые следует протестировать, например:
Выполненные пункты отмечаются статусами, например: “Passed”, “Failed”, “Blocked”, “Skipped”, “Not run”. Эти статусы также могут иметь свой цвет:
Преимущества использования чек-листов:
Разновидности чек-листов
Можно выделить два вида чек-листов: специальные и универсальные.
Специальные чек-листы создаются и используются для конкретных проектов, поэтому пункты такого чек-листа соответствуют специфики проекта. Тестировщик по специальному чек-листу проверяет возможность выполнить уникальное действие, предусмотренное требованиями. Вот примеры пунктов специального чек-листа:
Такие чек-листы не подходят к использованию на других проектах.
Универсальные чек-листы подходят для тестирования проектов одного типа. Проверка по универсальному чек-листу не привязывается к графическим элементам или конкретной реализации, а проверяется сама возможность пользователя выполнить действие. Для универсального чек-листа составляется абстрактный список проверок. Пункты универсального чек-листа могут быть такими:
Универсальные чек-листы можно использовать повторно на проектах одного типа. У многих агентств есть такие универсальные чек-листы, по ним определяется общий уровень качества продукта.
Как составлять работающие чек-листы
Чтобы составить работающий чек-лист, обратите внимание на эти рекомендации:
Преимущества и недостатки чек-листов
Чек-листы лучше применять на ранних этапах, когда софт быстро меняется, потому что тест-кейсы дорого поддерживать.
Где брать идеи для тестов (подборка полезных ссылок)
Вот выдали нам (тестировщикам) функционал и сказали:
А с чего начать? Для новичка это может быть целой проблемой. Особенно когда нет подробного ТЗ. Поэтому я решила создать эту подборку, где можно поискать вдохновение! ツ
Где брать идеи
Статьи
Они обычно называются «классы эквивалентности для. », или «чек-лист для. », или «чит-лист для. », или как-то так. Вот вам мои подборки:
Классы эквивалентности для стандартного грида — то есть для шапки отчета, по которой можно сортировать
Это еще не конец! — в этой статье Michael Hunter рассказывает про разные методы ввода, файлы, сетевое соединение, сообщения об ошибках, доступность, меню…
Юлия → Iuliia. Схемы транслитерации — если ваша система что-то транслитерирует, то будет полезно.
Чит-листы в Ситечке
В системе «Ситечко» есть чит-листы, это как раз шаблоны для переиспользования (подробнее можно почитать тут).
Чтобы их увидеть, нужно:
Ну и всё, дальше уже выбираете нужный вам.
Работы студентов
Я собираю хорошие работы студентов своей школы для начинающих в конфлюенсе в открытом доступе (ссылка доступна без авторизации). Эти работы помогают другим студентам:
Плагины для автозаполнения полей
Например, тот же Bug Mugnet. Установили плагин, ставим курсор на любое поле ввода, и вдохновляемся. Вот, например, подборка для валидных емейл-адресов:
Исследовательские туры
Туры из книги James A. Whittaker — это когда ты выбираешь какой-то один тур, засекаешь время, и выполняешь задачи тура. Фишка в том, что в каждом туре подробно рассказано, что именно тебе нужно делать.
Они помогают находить баги. Но и мысли для тестирования тоже подкидывают. В какую сторону думать, что проверять — можно найти там вдохновение!
Если у вас есть другие полезные ссылки на чек-листы и идеи для тестирования, скидывайте в комментарии!
PS — больше полезных статей ищите в моем блоге по метке «полезное». А полезные видео — на моем youtube-канале
Портал TMGuru:
Поиск
Cheat-sheet
Чит-лист – список повторяющихся проверок.
Когда создаются чит-листы
Чит-листы составляются с целью их последующего многократного использования. В связи с этим такие списки создаются в отношении распространённых и часто встречающихся составляющих программного обеспечения, с которыми предстоит работать неоднократно не только на текущем проекте, но и на последующих.
Примерами могут быть следующие: валидация поля редактирования для ввода электронного адреса, инъекции SQL и XSS, список проверок для проведения юзабилити тестирования.
Чит-листы также отлично зарекомендовали себя как инструмент для документирования корпоративных стандартов компаний, которые должны быть соблюдены, а потому и проверены в обязательном порядке (например, требования к интерфейсу разрабатываемого ПО).
Каждый отдельный специалист расширяет перечень проверок в своих чит-листах с опытом. На сегодняшний день многие из автоматизированных систем управления тестами также содержат и функционал поддержки списков чит-листов, что в значительной мере упрощает их создание, последующее поддержание и практическое применение.
Написание чит-листов целесообразно с целью:
Перенять опыт именитых гуру тестирования можно как раз через ознакомление с составленными ими чит-листам.
Ниже представлены ссылки на некоторые общедоступные чит-листы:
Чек-лист для тестирования числового поля
При тестировании встречаются как интересные задачки с замудреной логикой, так и простые, вроде проверки простой строки или числового поля. Для простых полей можно один раз написать чек-лист проверок, а потом переиспользовать, лишь немного меняя под «своё» поле.
Сегодня мы разберем чек-лист для числового поля. Сначала я напишу общий чек-лист, потом пройдемся по каждому пункту и разберемся, зачем он нужен, а в конце напишем чек-лист по этому шаблону.
Итак, у нас есть некое поле, куда нужно вводить число. Например, поле «возраст» при регистрации:
При этом на сайте нельзя регистрироваться до 18 лет, есть запрещённый контент.
Какие проверки тут можно провести:
Корректные значения
Представьте, что у вас буквально 5 минут на проверку функционала. И вы успеваете провести только первые несколько тестов из чек-листа. А чек-лист у вас:
Для поля с возрастом какие у нас будут корректные значения? Все, что выше 18 лет:
Тут надо понимать, что мы выбираем какое-то ОДНО значение. Просто каждый раз разное, для избежания эффекта пестицида.
Также важно понимать, что у нас может быть не одно корректное значение. Это когда у нас есть несколько диапазонов, и разные условия на каждом.
Например, тот же возраст:
Или если у нас идет расчет страховки в зависимости от стажа вождения:
Каждый раз берем разные значения, но в этом пункте смысл один — взять корректные значения из ТЗ.
Некорректные значения
Тут есть разные варианты. Что значит некорректное значение?
— А что будет, если мы возьмем значение из «неправильного» диапазона? Что, если мне меньше 18 лет? Ну, скажем, 10.
Потом внимательно смотрим на выбранный интервал:
— Хммммм, но ведь возраст не может быть меньше 0. То есть у нас есть логическая граница, разделяющая два разных класса эквивалентности:
— Если у нас есть некая логическая граница снизу, должна быть и сверху. Какой максимально возможный возраст у регистрирующихся на нашем сайте? Скорее всего, это около 55-65 лет, потому что более старшее поколение не любит компьютеры. Но можно заложить и условные 100-110 лет долгожителей.
Получаем еще один интервал с неявной границей. Но в любом случае, значения 25 и 145 будут различаться — одно реалистичное, а другое нет. Значит, стоит его тоже попробовать!
А дальше снова эффект пестицида. Один раз берем 145, а другой — 6666666.
Тут мы можем столкнуться с тем, что в поле нельзя ввести больше 2-3 символов. Разработчик перестраховался «от дурака». Это не повод опускать руки и отказываться от своей проверки. Потому что скорее всего разработчик просто установил maxlength на поле, а он легко обходится!
Граничные значения
Граничные значения отделяют один интервал от другого. Их обязательно надо тестировать. Потому что именно на границах чаще всего встречаются баги. Почему? Да потому что попадают в оба диапазона, или не попадают ни в один.
В нашем примере в ТЗ есть условие «регистрация только для лиц старше 18 лет». Это значит, что разработчик должен сделать в коде программы логику вида: