чит лист тестирования календаря
Чит лист тестирования календаря
> Терясь, как правильно ответить, не имея никаких ограничений или спек
Требования к программе у вас есть. Вон они, прямо в задании написаны. Прочитайте их внимательно (!). Затем включите фантазию и придумайте различные числовые и НЕчисловые значения. Попробуйте использовать разные тестовые идеи при генерации значений, не зацикливайтесь на чём-то одном.
Ещё было бы неплохо знать про всякие там «граничные условия» и «классы эквивалентности». Но если вы прямо сейчас начнёте про это читать, это вас может сбить с толку.
Поэтому _сначала_ включите фантазию и придумайте как можно больше значений, а уже _потом_ почитайте у Савина про классы эквивалентности; ну или вот это видео посмотрите:
https://www.youtube.com/watch?v=9kBQEOzgArE
> Как определить, что тестирование завершено/достаточно, и продолжать его не нужно?
Это более сложный вопрос, и на него может быть много разных мнений. Наиболее интересно на эту тему писал Michael Bolton. Вот ссылки на оригинал и на русский перевод:
http://www.developsense.com/blog/2009/09/when-do-we-s..
http://software-testing.ru/library/testing/general-te..
Одно тестовое задание. Что тут требуется от меня сделать? А то я вообще не понимаю. Как я понимаю функция — это фрагмент кода, к которому можно обратится из другого места программы, ну тут дано только название функции, два параметра и тип возвращаемого значения.
Дана программная функция: int test_function(String A, Boolean B);
Необходимо составить для неё набор предположительных тестовых
сценариев для будущего юнит-тестирования.
Входных специфичных данных нет, для рассмотрения необходимо использовать только предоставленную функцию. Навыки программирования для выполнения данного задания не нужны.
P.S. Собеседование уже прошло, мне просто интересно где же утка)
Aleksandr, прочти про классы эквивалентности и граничные значения в книгах Савина и Куликова. Также ознакомься вот с этим видео https://www.youtube.com/watch?v=9kBQEOzgArE
Далее, помни, что дата является одновременно:
— величиной, вводимой с помощью трёх чисел DD MM YYYY
— непрерывной величиной, откладываемой на оси t
Поскольку от тебя требуют написать тестовые случаи (тест-кейсы), почитай ещё и про оформление тест-кейсов в блоге Ольги Киселёвой.
Это почти всё, что нужно для выполнения задания.
Всем привет! Скорректируйте, пожалуйста. Тест-задание такое: Напишите smoke тесты для простого калькулятора MS Windows (операции «+», «-», «/», «*», «=»). Тест-кейсы должны обязательно содержать информацию о тестовых данных, используемых в тест-кейсе.
Написала вот такие:
Angela,
я бы не использовала в смоки в качестве приоритетных 0 и 1. Вот у вас есть
Шаг: Ввести «0» «+» «1», нажать « = »
Ожидаемый результат: 1
Вы сможете определить после этого теста, ваш калькулятор действительно посчитал сумму или ничего не сделал и отображает последнее введенное число?
четверг, 5 апреля 2018 г.
Классы эквивалентности для строки, которая обозначает дату
Большинство примеров про классы эквивалентности приводятся для чисел. Самый заезжанный пример — тестирование калькулятор. Он используется в книгах и статьях, потому что простой и понятный.
Но потом доходит до дела и сразу ступор: а как применять классы эквивалентности где-то еще? Ладно, используем правило «ищи число»: если речь идет о поле с символами, берем длину поля (число) и тестируем на границы. Вроде все хорошо, логично и понятно.
Однако на своих студентах я заметила, что это правило стало серебряной пулей. Если это нечисловое поле — по границам тестируем ТОЛЬКО на длину. Точка. Просишь протестировать дату, получаешь примерно такой ответ:
Четкий формат дд.мм.гггг
Допустим, я могу ввести в профиле свою дату рождения и система сама посчитает, сколько мне лет. Формат даты известен заранее, на поле стоит маска, дату в другом формате я ввести не смогу.
Если никаких ограничений нет, все равно включаем логику — дата рождения не может быть отрицательной. Так что уже как минимум есть граница в TODAY (сегодняшнее число). Надо проверить, можно ли ввести меньше и больше.
По идее, календарик должен блокировать выбор дальше текущего числа. Логично, конечно, усложнить и не давать вводить возраст до 4 лет, но это дополнительные ограничения из серии «а зачем?». А вот «не вводить дальше, чем сегодня» — стандартная практика, вполне можно использовать.
Если ввели с клавиатуры, можно подсвечивать поле красным и выдавать ошибку «Дата рождения должна быть меньше текущей даты». Но даже если никаких ограничений нет, мы просто проверяем, как поведет себя система при вводе этой логической границы и попытке выйти за ее пределы.
Но как быть с другими границами? Которых нет в ТЗ.
Нижняя граница
Конечно, это негативная проверка из серии «упадет / не упадет». Зачем нам четыре теста вместо одного? Потому что разработчик мог поставить защиту от дурака от даты «00.00.0000», а вот если нули только в одном компоненте — ой, все пропало.
Если говорить о нижней границе, то помимо нуля я рекомендую проверить:
А еще некоторые системы сбрасывают в «01.01.1900» всякий треш, пришедший на входе. Ведь с точки зрения системы это вполне корректная дата, так что это бывает значением «по-умолчанию». По крайней мере, я видела такое поведение в системах, с которыми мы интегрировались на работе.
Верхняя граница
Просто строка с датой
 |
| Просто поле для ввода |
Даже если у нас нет ограничения на формат, мы сначала смотрим на строку как на дату. Это очень важно — видеть в поле тот смысл, который заложил туда разработчик, а не просто абстрактную строку. Вы ведь не знаете заранее, как она обрабатывается. Может быть, никак, это правда строка. А может, над ней висят какие-то правила, ограничения, преобразования.
Поэтому наш план действий:
Как тестировать дату конкретного формата, мы рассмотрели выше. Надеюсь, не надо пояснять, что маска на поле может быть любой, хоть дд.мм.гггг, хоть гггг/мм/дд, хоть какая-то другая. Это не мешает нам подставить туда все нули, все девятки или ввести магическое 01.01.1900.
Рассмотрим оставшиеся пункты.
Разные форматы даты
Система умеет работать только с российским форматом? Или с другими тоже? Проверяем основные:
Использование персонажей и сценариев в тестировании Календаря
Привет! Меня зовут Евгений Емельянов, я руководитель проекта Календарь Mail.Ru. Сегодня я расскажу вам о том, как мы прокачали тестирование мобильных приложений Календаря с помощью персонажей и сценариев. Такое тестирование широко применяется в юзабилити-исследованиях и при изучении взаимодействия пользователей с интерфейсом. Мы решили применить похожие методики для классического ручного тестирования мобильных приложений. Поначалу, команда была настроена скептически, но результаты оказались весьма положительными, поэтому мы хотели бы поделиться с вами своим опытом.
Nota bene: в маркетинге и «юзеро-центричном» дизайне, персонажи — это вымышленные действующие лица. Они представляют собой различные группы пользователей, разделяемых по географии, демографии, поведению и привычкам. Маркетологи используют персонажей для описания различных сегментов рынка.
Персонажи могут быть полезны при определении целей, пожеланий, ограничений потребителей бренда или продукта. Могут помочь при принятии решений о тех или иных новых разработках, изменениях в текущем функционале, дизайне. Пользовательские персонажи — это представление целей и поведения гипотетических групп пользователей продукта. В большинстве случаев персонажи создаются по данным, полученным из опросов и интервью пользователей. Данные содержат описание поведенческих шаблонов, целей, навыков, возможностей и внешней среды. Для воссоздания более реалистичного образа добавляются вымышленные небольшие персональные черты. Для каждого продукта обычно создается более одного персонажа, но всегда должен быть основной персонаж, являющийся представителем главной целевой группы.
Проблема назрела
Вымышленные друзья
Проект «Календарь» небольшой, уютный и почти семейный. Мы стараемся общаться с пользователями напрямую, минуя техническую поддержку. Поэтому мы неплохо знаем наших пользователей, их основные задачи и в курсе большинства проблем. Составить портреты основных групп не составило труда.
Обычный пользователь: добавляет календари с событиями (праздники, спорт, кино), дни рождения, пользуется различными напоминаниями о них. Изредка добавляет личные события или новые дни рождения.
Мобильный: использует календарь только на смартфоне — iOS или Android. Очень редко заходит в веб-интерфейс. События, в основном, личные, как однократные, так и периодические.
Активный: использует веб-интерфейс и один из мобильных клиентов — iOS или Android, часто переключается между двумя клиентами. Создает и редактирует много событий и задач, часто приглашает участников или сам является участником событий.
Технократ: использует веб интерфейс и клиенты на обеих мобильных платформах. Создает много событий и задач. Использует нестандартные подходы к инструментам, строит собственные схемы работы с событиями и задачами.
Пьяный мастер: особый вид, редко встречающийся в природе, способный сеять хаос и разрушения. Постоянно путает кнопки, вбивает в формы поток сознания, по десять раз жмет на Submit, рассылает спам и всячески пытается сломать то, до чего дотянется.
У этих пяти групп пользователей пересекаются юзкейсы, но довольно сильно отличаются сценарии (набор юзкейсов и порядок их выполнения). К примеру, быстрая и стабильная синхронизация данных между клиентами критична для «Активного» и «Технократа» и не особо важна для «Мобильного», так как он пользуется только мобильным клиентом. Исходя из этих соображений мы составили сценарии использования для каждого персонажа на основе уже существующих юзкейсов.
Далее мы составили несколько сценариев взаимодействия между персонажами для групповой работы в календаре. Важный момент — все сценарии, в том числе групповые, обкатывались на представителях групп внутри компании. Таким образом мы проверяли одновременно и правильность выбора наших персонажей, и приближенность сценариев к реальной жизни. Мы использовали «коридорное тестирование» на коллегах, но для чистоты эксперимента пробовали и опрос сторонних пользователей с помощью почты и мессенджеров. «Коридорное тестирование» оказалось эффективнее, так как при общении с лояльными пользователями возникал корректирующий эффект «помочь любой ценой». И пользователи замалчивали какие-то моменты, подстраиваясь под ожидаемый, в их понимании, результат.
Процесс пошел
Ложка нюансов
Естественно, персонажи — это не таблетка от всех болезней. Есть проблемы, связанные с использованием методики, и проблемы, которые персонажи не решают.
Основная из них — эпизодическая избыточность и наложение юзкейсов у разных персонажей и в разных сценариях. Мы боремся с этим, разбивая юзкейсы по параметрам выполнения. Например, создаем события раздельно по персонажам, и у каждого свой набор параметров, максимально приближенный к реальности, охватывающий все возможные условия создания события.
Еще одна проблема — некоторые юзкейсы нельзя включить в сценарии, так как они или очень редко встречаются в реальной жизни, или носят для персонажа синтетический характер. Такие юзкейсы мы оставляем отдельно от сценариев и проходим их при полном тестировании всего функционала.
Профит
По итогам работы с персонажами и сценариями были выпущены 3 обновления наших мобильных клиентов. Ссылаться на улучшение статистики по нахождению обидных багов самими пользователями нельзя, так как выпущенные версии сильно различаются и сравнивать их между собой не совсем правильно. Но есть другие, не менее важные полезные эффекты.
Во-первых, тестерам намного веселее работать с персонажами. Процесс тестирования стал более разнообразным, выросло понимание продукта и самих пользователей. Вместо охоты за абстрактными и сложно воспроизводимыми в реальных условиях багами, в первую очередь отлавливаются критичные для конечного пользователя проблемы.
Во-вторых, тестеры также участвуют не только в функциональном, но и в юзабилити-тестировании. И теперь количество мнений при обсуждении интерфейсов пополнилось активными пользователями продукта со своей аргументацией и видением.
В-третьих, снизился порог вхождения для новых тестеров. Недавно мы провели эксперимент и взяли на позицию тестировщика человека без опыта тестирования. Не считая «курса молодого бойца» по общим вопросам, эффективное тестирование началось примерно через три дня.
Нельзя забывать, что разработчики тоже должны тестировать свои приложения, и для них есть свои сценарии. Нишевые продукты, вроде нашего Календаря, сталкиваются с проблемой использования непосредственными участниками. Сценарии и персонажи прекрасно справляются с вопросом «зачем мне это вообще использовать, у меня нет такой потребности». В нашем случае разработчики со временем начинают пользоваться продуктом в жизни, понемногу отходя от сценариев.
И последнее — персонажи используются нами не только в функциональном тестировании. Благодаря проделанной работе мы структурировали и довели до ума важный и полезный инструмент, который потенциально можем использовать в маркетинге.
Юрий Ветров (@jvetrau), руководитель группы проектирования интерфейсов Mail.Ru Group:
Персонажи — мощный инструмент проектировщика и дизайнера, который позволяет фокусироваться на наиболее востребованных в реальном использовании продукта сценариях. Было здорово увидеть, что он нашел применение и в процессе тестирования качества реализации, а не только применительно к юзабилити.
В идеальной ситуации баги исправляют все и сразу. Но в жизни всегда есть куча задач, отодвигающих полный и бесповоротный багфикс — новый функционал, срочные хотфиксы и т.п. Поэтому нужен хороший способ расставления приоритетов как при исправлении багов, так и в их поиске. Использовать для этого ключевые сценарии использования наиболее важных категорий пользователей — самое то. Это значит, что в первую очередь находятся и исправляются проблемы, мешающие пользователям чаще всего.
До этого на персонажей опирались при экспертной оценке юзабилити и пользовательских тестированиях. Использовать их для проверки качества реализации — интересный и достаточно свежий подход. Давно и много читаю о современных методах работы над интерфейсами и про такой еще не доводилось слышать. Так что это отличнейшее дополнение в копилку продуктовой команды.
Чит лист тестирования календаря
Почти все тестировщики знают, что такое чек-листы. Но есть ещё один очень удобный инструмент, повышающий качество тестирования: чит-листы.
Что такое чит-листы?
Зачастую нам нужно осуществлять однотипные проверки в разных местах: валидация поля e-mail, ограничения в числовых полях, SQL и XSS инъекции и т.д. Для этих случаев, чтобы не забыть «что нужно проверить», и создаются чит-листы (иногда их ещё называют cheat sheets).
Существуют стандартные чит-листы. К примеру, подборка тестов для тестирования web-элементов или набор тестов для проверки регистрации. Каждый тестировщик с опытом вырабатывает свои собственные чит-листы для различных условий. Кто-то пытается держать их в голове, а кто-то выписывает в виде списка, чтобы не забыть.
Более того, во многих компаниях есть свои собственные стандарты в разработке интерфейса, которые тоже постепенно включаются в разряд необходимых проверок: например, «каждое поле ввода должно быть со скруглениями», «все сообщения системы должны появляться в виде поп-апов, а не отдельных окон» и т.д.
В результате у тестировщиков появляются наборы проверок, которые можно многократно переиспользовать: формы регистрации одинаково проверяются в разных проектах, SQL и XSS инъекции одинаково проверяются в разных полях ввода. Держать всё в голове? Неэффективно, голова нужна для того, чтобы думать, а не для того, чтобы хранить множество избыточных данных.
Именно поэтому тестировщики пишут чит-листы: списки повторяющихся проверок, которые можно переиспользовать в разных условиях. И да, это настоящий чит в тестировании, почти как IDDQD!
Что дают чит-листы?
Как использовать чит-листы в Sitechco?
Для начала, вы создаёте свои собственные чит-листы, или берёте за пример добавленные нами. В чит-листе вы описываете всё, что должно проверяться в рамках определённых тестовых условий. К примеру, пусть это будет поле email, которое используется во многих окнах вашего приложения. Вы выписываете все основные проверки, которые считаете необходимыми, проставляете им приоритеты. Этот чит-лист вы можете сделать как и любой чек-лист, разным: с тегами или без, с перечнем проверок или с указанием результата в том числе. В результате у вас может получиться что-то вроде такого чит-листа:
После этого, вы можете вставлять этот чит-лист в различные чек-листы вашего проекта. Каждый раз, когда при тестировании какого-либо функционала вам нужно проверять обработку поля Email, вы просто вставляете этот чит-лист. В результате у вас будет полный набор проверок, которые нужно не забыть проверить — а вы сэкономите массу времени!
После вставки чит-листа в чек-лист вы получите отдельную группу тестов, которую после этого сможете отредактировать или расширить под конкретные условия.
Применяем чит-листы с умом!
Чтобы от чит-листов была максимальная польза, следуйте простым советам:
Где брать идеи для тестов (подборка полезных ссылок)
Вот выдали нам (тестировщикам) функционал и сказали:
А с чего начать? Для новичка это может быть целой проблемой. Особенно когда нет подробного ТЗ. Поэтому я решила создать эту подборку, где можно поискать вдохновение! ツ
Где брать идеи
Статьи
Они обычно называются «классы эквивалентности для. », или «чек-лист для. », или «чит-лист для. », или как-то так. Вот вам мои подборки:
Классы эквивалентности для стандартного грида — то есть для шапки отчета, по которой можно сортировать
Это еще не конец! — в этой статье Michael Hunter рассказывает про разные методы ввода, файлы, сетевое соединение, сообщения об ошибках, доступность, меню…
Юлия → Iuliia. Схемы транслитерации — если ваша система что-то транслитерирует, то будет полезно.
Чит-листы в Ситечке
В системе «Ситечко» есть чит-листы, это как раз шаблоны для переиспользования (подробнее можно почитать тут).
Чтобы их увидеть, нужно:
Ну и всё, дальше уже выбираете нужный вам.
Работы студентов
Я собираю хорошие работы студентов своей школы для начинающих в конфлюенсе в открытом доступе (ссылка доступна без авторизации). Эти работы помогают другим студентам:
Плагины для автозаполнения полей
Например, тот же Bug Mugnet. Установили плагин, ставим курсор на любое поле ввода, и вдохновляемся. Вот, например, подборка для валидных емейл-адресов:
Исследовательские туры
Туры из книги James A. Whittaker — это когда ты выбираешь какой-то один тур, засекаешь время, и выполняешь задачи тура. Фишка в том, что в каждом туре подробно рассказано, что именно тебе нужно делать.
Они помогают находить баги. Но и мысли для тестирования тоже подкидывают. В какую сторону думать, что проверять — можно найти там вдохновение!
Если у вас есть другие полезные ссылки на чек-листы и идеи для тестирования, скидывайте в комментарии!
PS — больше полезных статей ищите в моем блоге по метке «полезное». А полезные видео — на моем youtube-канале