чит лист и чек лист разница
Где брать идеи для тестов (подборка полезных ссылок)
Вот выдали нам (тестировщикам) функционал и сказали:
А с чего начать? Для новичка это может быть целой проблемой. Особенно когда нет подробного ТЗ. Поэтому я решила создать эту подборку, где можно поискать вдохновение! ツ
Где брать идеи
Статьи
Они обычно называются «классы эквивалентности для. », или «чек-лист для. », или «чит-лист для. », или как-то так. Вот вам мои подборки:
Классы эквивалентности для стандартного грида — то есть для шапки отчета, по которой можно сортировать
Это еще не конец! — в этой статье Michael Hunter рассказывает про разные методы ввода, файлы, сетевое соединение, сообщения об ошибках, доступность, меню…
Юлия → Iuliia. Схемы транслитерации — если ваша система что-то транслитерирует, то будет полезно.
Чит-листы в Ситечке
В системе «Ситечко» есть чит-листы, это как раз шаблоны для переиспользования (подробнее можно почитать тут).
Чтобы их увидеть, нужно:
Ну и всё, дальше уже выбираете нужный вам.
Работы студентов
Я собираю хорошие работы студентов своей школы для начинающих в конфлюенсе в открытом доступе (ссылка доступна без авторизации). Эти работы помогают другим студентам:
Плагины для автозаполнения полей
Например, тот же Bug Mugnet. Установили плагин, ставим курсор на любое поле ввода, и вдохновляемся. Вот, например, подборка для валидных емейл-адресов:
Исследовательские туры
Туры из книги James A. Whittaker — это когда ты выбираешь какой-то один тур, засекаешь время, и выполняешь задачи тура. Фишка в том, что в каждом туре подробно рассказано, что именно тебе нужно делать.
Они помогают находить баги. Но и мысли для тестирования тоже подкидывают. В какую сторону думать, что проверять — можно найти там вдохновение!
Если у вас есть другие полезные ссылки на чек-листы и идеи для тестирования, скидывайте в комментарии!
PS — больше полезных статей ищите в моем блоге по метке «полезное». А полезные видео — на моем youtube-канале
Чит лист и чек лист разница
Как я использовала чит-листы и узнала за день тестирования больше нового, чем за 3 прочитанные книги
Книги, к слову, тоже оказались полезными, но тут главный герой не книги, а чит-листы.
Как я их использовала — по большей части при тестировании незнакомых мне продуктов, потому что когда продукт тебе знаком, ты знаешь все “трещинки”, все поля ввода, ошибки, ямки в коде продукта и с каким выражением лица лучше данные вводить (но это не точно). Бывали случаи, когда чит-листы в моей команде применялись и на знакомых продуктах и, ребята, там столько всего находилось из разряда фантастики!
Как я использовала чит-листы? Внимайте, ребятки.
Шаг первый: гуглить чит-листы! А нагугленное бережно собирать себе в личную коллекцию на все случаи жизни: контрольные списки интерфейса, проверки числовых полей, проверки текстовых полей, email и даже можно разжиться парой листиков по тестированию безопасности.
Шаг второй: хватит это терпеть! Я прыгала из документа в документ, чит-лист один, чит-лист другой, “крутится-вертится шар голубой!” Часть проверок повторялась, я решила — хватит это терпеть!
Шаг третий: пиши, сокращай! Я решила, что нужно оптимизировать это безобразие и сгруппировала проверки в табличку по типам, так стало намного удобнее — каждая вкладка моей таблицы отвечала за тестирование какого-то определенного типа поля, число, текст, а рядом с каждой проверкой стоял статус — прошло или не прошло.
Кому-то сильно интересно сейчас, почему я пою хвалебные оды такому простому инструменту? Чего же в них такого хорошего, в чит-листах? А вот чего:
Агеева Нина, тренер ПОИНТ
П.С. Вот такие классные штуки делают студенты нашего первого потока ПОИНТ
Как составить Чек-лист? Для начинающего тестировщика.
Все очень часто слышат про Тест-кейсы и как их оформлять, но не так много времени уделяется Чек-листам, что это такое? Зачем это нужно? И как с этим жить?
Начнем с того, что назначения у тест-кейсов и чек-листов одинаковое, это проверка продукта. Однако есть два основных отличия:
1 Чек-лист описывает кратко, что нам нужно протестировать и результат, Тест-кейс наоборот старается более детально рассказать о тестировании данного функционала.
2 Объем проверяемого функционала, за короткий промежуток, мы можем быстрее проверить продукт, чем Тест-кейсами.
Название функционала, отдельного элемента продукта (Например: Поле поиска)
3 Краткое описание теста
Буквально небольшое описание действия или пункта.
Например: Ввести пароль латиницей
Я выделил основные 3 пункта, можно добавить еще увеличить уровень подзаголовков, для полного удобства и понимания архитектуры проекта, но это уже зависит от вас и вашего объекта тестирования.
Пример Чек листа в XLSX формате
Давайте вместе взглянем на сайт lensgo.ru
И попробуем составить чек-лист с помощью Excel.
Закиньте что-нибудь в корзину и перейдите в нее, а далее к оформлению товара.
У вас должна отобразится страница по адресу https://lensgo.ru/basket/order/
Писать Чек-лист мы будем по форме “Данные о покупателе”
1 Напишем в шапке Чек-листа, Название и описание.
Чтобы другие тестировщики и ты сам смог быстро понять о чем этот Чек-лист.
2 Далее по каждому полю составляем краткий список проверок, результатов и еще проставляем приоритет. Каждая проверка проверяет один пункт, но может проверять и комбинации нескольких пунктов. Составлять список проверок нужно с помощью техник тест-дизайна, без них может получится огромный список тестов:
1 Граничные значения
2 Классы эквивалентности
можно прочитать про это в этих статьях:
Возьмем поле ФИО и составим группы проверок, а в них уже напишем списки проверок с помощью техник тест-дизайна. Немного подумав вычисляем, что можно создать три группы ( Проверка длины поля, Проверка поля на кириллице “ФИО”, Проверка поля на английском “ФИО”) учитываем также, что интернет-магазин ориентирован на Россию.
Вот загруженный пример, но попробуйте без скаченного примера составить проверки для поля “Телефон” и потом сравнить ваши тесты с моими.
Пример Чек листа в Sitechco
Есть огромное количество онлайн сервисов для составления чек-листов, но один из наиболее подходящий для тестировщиков это sitechco.ru
Где вы удобно можете расположить свои проверки, радует еще то, что интерфейс интуитивно понятен и можно быстро редактировать тесты. Еще имеется запуск тестов, отчеты по их прохождению и тест планы, все это очень облегчит вам жизнь при тестировании проекта.
И так вы узнали как можно составить чек-листы для тестирования вашего продукта, надеюсь, что моя статья вам помогла.
Чит лист и чек лист разница
Почти все тестировщики знают, что такое чек-листы. Но есть ещё один очень удобный инструмент, повышающий качество тестирования: чит-листы.
Что такое чит-листы?
Зачастую нам нужно осуществлять однотипные проверки в разных местах: валидация поля e-mail, ограничения в числовых полях, SQL и XSS инъекции и т.д. Для этих случаев, чтобы не забыть «что нужно проверить», и создаются чит-листы (иногда их ещё называют cheat sheets).
Существуют стандартные чит-листы. К примеру, подборка тестов для тестирования web-элементов или набор тестов для проверки регистрации. Каждый тестировщик с опытом вырабатывает свои собственные чит-листы для различных условий. Кто-то пытается держать их в голове, а кто-то выписывает в виде списка, чтобы не забыть.
Более того, во многих компаниях есть свои собственные стандарты в разработке интерфейса, которые тоже постепенно включаются в разряд необходимых проверок: например, «каждое поле ввода должно быть со скруглениями», «все сообщения системы должны появляться в виде поп-апов, а не отдельных окон» и т.д.
В результате у тестировщиков появляются наборы проверок, которые можно многократно переиспользовать: формы регистрации одинаково проверяются в разных проектах, SQL и XSS инъекции одинаково проверяются в разных полях ввода. Держать всё в голове? Неэффективно, голова нужна для того, чтобы думать, а не для того, чтобы хранить множество избыточных данных.
Именно поэтому тестировщики пишут чит-листы: списки повторяющихся проверок, которые можно переиспользовать в разных условиях. И да, это настоящий чит в тестировании, почти как IDDQD!
Что дают чит-листы?
Как использовать чит-листы в Sitechco?
Для начала, вы создаёте свои собственные чит-листы, или берёте за пример добавленные нами. В чит-листе вы описываете всё, что должно проверяться в рамках определённых тестовых условий. К примеру, пусть это будет поле email, которое используется во многих окнах вашего приложения. Вы выписываете все основные проверки, которые считаете необходимыми, проставляете им приоритеты. Этот чит-лист вы можете сделать как и любой чек-лист, разным: с тегами или без, с перечнем проверок или с указанием результата в том числе. В результате у вас может получиться что-то вроде такого чит-листа:
После этого, вы можете вставлять этот чит-лист в различные чек-листы вашего проекта. Каждый раз, когда при тестировании какого-либо функционала вам нужно проверять обработку поля Email, вы просто вставляете этот чит-лист. В результате у вас будет полный набор проверок, которые нужно не забыть проверить — а вы сэкономите массу времени!
После вставки чит-листа в чек-лист вы получите отдельную группу тестов, которую после этого сможете отредактировать или расширить под конкретные условия.
Применяем чит-листы с умом!
Чтобы от чит-листов была максимальная польза, следуйте простым советам:
Тестовая документация. Превращаем таблицы в деревья
В предыдущей статье я рассказывала, как в нашей компании проходит первая стадия тестирования проекта — анализ. Сегодня расскажу о следующем этапе — проектирования и документирования тестов.
Этот этап опционален. На некоторых проектах нет задокументированных требований, и тогда зачастую поддержка тестовой документации является единственным разумным способом хранения и передачи знаний о продукте. Иногда тестовую документацию требует заказчик, иногда мы пишем ее для себя. Иногда, если у нас есть хорошо написанные требования, мы отказываемся от документирования тестов в пользу экономии ресурсов.
Вид тестовой документации также зависит от ситуации на проекте и ожиданий заказчика.
Чек-листы vs Тест-кейсы
Чек-лист отличается от тест-кейса степенью подробности. В чек-листе вы не встретите подробных шагов кейса, для использования чек-листа при тестировании очень много информации нужно держать в голове в момент прогона тестов и знать логику работы приложения на отлично.
В нашей компании всегда использовались чек-листы, поскольку на написание тест-кейсов уходит неоправданно много времени, и они тяжеловесны — на прочтение кейса и его осознание тоже уходит время. Кроме того, не стоит забывать про эффект пестицида — баги кода имеют свойство приспосабливаться к тестам. При использовании чек-листа сохраняется некоторая свобода действий, а тест-кейсы этой свободы полностью лишают, увеличивая упомянутый выше эффект. Однако, при прогоне чек-листа в седьмой раз за последние сутки перед релизом часть функциональности, заложенной под одним пунктом чек-листа, теряется по причине человеческого фактора.
Было принято решение расширять чек-листы и делать их подробнее. Так тестировщик, в беспамятстве прогоняющий фичу перед релизом, не забудет проверить ошибки сети в ответ на каждый запрос, не потеряет проверку какой-нибудь «неважной» кнопки или какого-нибудь одного статуса из двенадцати. Так мы пришли к написанию подробной юзер-стори, полностью покрывающей фичу приложения, но по факту являющей собой один громадный тест-кейс.
Плюсы такого подхода:
Таблицы vs Деревья
Однажды я выпила поливитаминов, и меня осенило, что вместо того, чтобы хранить тесты в табличных форматах, куда удобнее использовать деревья, а точнее, вложенные списки. Ведь при написании той самой большой юзер-стори мы так часто сталкиваемся с проблемой, что не знаем, где расположить альтернативные действия. Например, когда у нас несколько кнопок на алерте. Чтобы проверить каждую из них, нам приходится прописывать вызов этого алерта несколько раз. Вместо этого мы могли бы подвесить проверку каждой из кнопок к вызову алерта.
В целом идея была в том, чтобы прописывать те же самые пользовательские сценарии в виде дерева, в котором переход — это действие, а узел — это состояние, в котором оказывается приложение после этого действия. По факту диаграмма состояний-переходов, только объектами выступают экраны приложения. Каждая ветвь такого дерева — тест-кейс.
Когда стали пробовать, столкнулись с проблемами. Оказалось, что привычная нам декомпозиция по экранам приложения не работает: опираться на дизайн при проектировании тестов неудобно. Ветки дерева росли далеко в глубину, и это было неудобно визуально. В погоне за сценарием мы воротили циклы. А еще стало понятно, что отказаться от таблиц нельзя.
Решение крылось в смене подхода к декомпозиции, большей осознанности и отказе от «решений по умолчанию». Древовидная структура тестовой документации действительно удобна, поскольку дает большую свободу при проектировании. Вид декомпозиции определяет, что именно станет узлами нашего дерева. А это в свою очередь определяется особенностями продукта и приоритетами заказчика.
В целом, плюсы использования древовидной структуры:
Итоговые паттерны
Экраны приложения
Источником знаний является навсхема. Первый уровень дерева составляет список кейсов навсхемы, который обычно соответствует разделам приложения. Далее к ним подвешивается список экранов каждого раздела, к каждому экрану — список его состояний. В каждом узле дерева, начиная с третьего уровня, может содержаться чек-лист в табличном формате, описывающий каждый элемент дизайна и способы взаимодействия с ним. Если элементы дизайна сложные и имеют много состояний или на экране есть повторяющиеся элементы, можно декомпозировать еще глубже. Таким образом, одна ветвь дерева описывает жизненный цикл одного экрана.
Ниже в качестве примера приведена общая схема рассуждений при декомпозиции раздела заказов агрегатора авиабилетов.
К листьям этого дерева крепим короткие чек-листы. Так к каждому листу «навбар» линкуем чек-лист на элементы навбара для текущего экрана:
А к каждому листу «секция запланированные поездки» линкуем чек-лист на проверку части списка с активными заказами:
Критерии для выбора такого паттерна следующие:
Объекты/действия
При таком подходе ориентируемся не на навсхему, а на документацию АПИ и клиентскую бизнес-логику. Негативные и позитивные кейсы разбиваем по разным веткам. Желательно, чтобы элементы одного уровня дерева отвечали на один вопрос, но можно оставить это ограничение только для одного уровня иерархии.
Такая схема крайне удобна в тех случаях, когда у нас есть активное влияние пользователей друг на друга, что порождает сложные сценарные цепочки. Примером может служить чат. Относительно предыдущего подхода такую документацию легче поддерживать, поскольку изменения в логике случаются реже, чем в дизайне.
Ниже приведен пример общей схемы рассуждений при декомпозиции по принципу объект/действие.
В такой схеме дополнительным бонусом является возможность использовать ее как карту для исследовательского тестирования и для смоук-теста. Степень подробности тестирования можно регулировать, отсекая при прогоне уровни дерева, поскольку каждый следующий уровень уточняет предыдущий. При углублении в ветвь дерева — углубляешься в функциональность.
Например, для уже упомянутого чата схема документации будет выглядеть примерно так:
Критерии выбора такого паттерна:
На базе Use cases
Бывают ситуации, в которых нерентабельно декомпозировать функциональность и проектировать тесты по двум описанным ранее схемам. Например, если мы хотим покрыть тестами длительную работу с приложением – как в случае с лентой соцсети или прослушиванием музыки в бекграунде. Или когда фича завязана на сценарии с малым количеством альтернатив – например, оформление подписки на контент. В таком случае пользуемся третьим паттерном, основанном на пользовательских сценариях.
Сначала декомпозируем функциональность по use-кейсам. Определяемся с тем, какие действующие лица могут участвовать в процессе работы с приложением и какие цели они могут перед собой ставить. За это будут отвечать первые два уровня нашего дерева. Далее пытаемся найти все возможные входные условия, которые могут повлиять на отработку сценария по достижению текущей цели, и структурируем их в дереве. Их так же удобнее всего делить на позитивные и негативные. Далее к каждому листу подвешиваем сценарный чек-лист на проверку функциональности, отвечающей за достижение цели.
В качестве примера ниже приведена схема для музыкального плеера с функцией загрузки треков для прослушивания офлайн:
Здесь ко всем листьям позитивного сценария подвешиваем чек-лист, который нужно будет прогонять в условиях разных подключений к сети:
Бывает так, что при продумывании возможных use-кейсов цели пользователей получаются очень глобальными. Например, в уже упомянутом агрегаторе авиабилетов цель «купить билет» может поставить в тупик обилием возможных вариантов предусловий и количеством шагов, которые необходимо пройти для достижения цели. Кроме того, в таком приложении очень многое зависит от поведения сторонних систем, что накладывает некоторые ограничения на определение всех предусловий и однозначно выполняемого сценария. Предложения поступают от разных авиакомпаний и могут измениться в любую минуту. В каждый момент времени невозможно гарантировать, что покупка билета пройдет успешно, поскольку этот билет может оказаться куплен, пока мы заполняли данные для брони.
Решение первой проблемы заключается в более детальной декомпозиции. То есть большую цель «купить билет» можно разбить на маленькие цели, соответствующие шагам оформления — «ознакомиться с предложениями», «заполнить данные пассажиров», «оплатить заказ». И далее находить набор возможных предусловий, действий пользователя и результатов для этих маленьких целей.
Решение второй проблемы менее очевидно. Это в целом ограничение use-кейса — в случае, если поведение системы не определяется действиями пользователя однозначно, возникают проблемы с покрытием и проектированием use-кейсов. Для себя решили, что в таких ситуациях мы стараемся прописать все возможные варианты поведения систем, неподвластных пользователю, как предусловия, и тем самым снижаем неопределенность результата выполнения сценария. Либо используем другую схему проектирования тестовой документации.
Критерии выбора такого паттерна:
Отталкиваемся от цели
Мы сменили инструмент и выработали новые подходы к ведению тестовой документации, но от старых подходов не отказывались. Выбор стратегии зависит от потребностей на проекте и приоритетов заказчика. Если логика приложения простая и проект длится недолго, то обычно достаточно стандартных чек-листов на функциональность с минимальной подробностью. Если проект большой, сложный и без требований, то на часть фич стоит написать полноценную «древовидную» документацию. Если на проекте есть хорошо задокументированные требования, то иногда можно не тратить время на написание тестов по функциональности, зато можно уделить больше внимания нефункциональному тестированию (производительности, безопасности) и систематизировать его – опять же, если есть соответствующая договоренность с заказчиком. Или задокументировать только «рискованные» тесты. Юзер-стори все равно пишем почти всегда, но уже не такие подробные — как приемку для заказчика или как смоук-тест, а проведенная до этого работа по декомпозиции помогает нам быстро проектировать сценарий и правильно расставлять приоритеты.
Наличие тестовой документации на проекте позволяет зафиксировать информацию о требованиях, заранее продумать и структурировать тесты, снизить порог вхождения в проект нового тестировщика, снизить риски пропуска ошибок из-за человеческого фактора. Однако, написание и поддержка тестовой документации требуют ресурсов, которые не всегда возможно или не всегда оправданно тратить.