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