Типы границ для классов эквивалентности

 

Ссылка на Хабр

Про типы границ я впервые услышала на тренинге Алексея Баранцева. Зачем они нужны? Да просто чтобы не забыть всё проверить. Написал чек-лист, потом проверяешь себя:

— Все учел? Вот эти классы эквивалентности, какие границы логические? А какие технологические? ...

Так можно вспомнить о проверке, про которую забыл или просто не подумал! Полезная штука.

Алексей дал нам тогда про такую типизацию границ:

• Физическая — которую физически нельзя преодолеть.

• Логическая — ограничение, накладываемое логикой, не программой.

• Технологическая — ограничение, накладываемое используемой технологией.

• Произвольная — ограничение, наложенное аналитиком или заказчиком.

Лично я предпочитаю совмещать физическую и логическую. Потому что физическая — это то, что мы вообще преодолеть не можем. Например, при всем желании мы не введем строку отрицательной длины, ну никак не сможем.

Но то, что физически сделать нельзя, часто в программе сделать можно. Например, ввести в количество участников митапа «1,5 человека» — физически невозможно, но программа то позволяет. Значит, для программы это уже логическая, мы же понимаем, что это невозможно.

Так что в моей классификации есть всего три типа границ (сокращенно ЛТП):

1. Логическая — ограничение, накладываемое логикой, не программой.

2. Технологическая — ограничение, накладываемое используемой технологией.

3. Произвольная — ограничение, накладываемое аналитиком или разработчиком.

Рассмотрим каждую из них!

Как яндекс диск сдох при одновременном перемещении папки

Ладно, ладно, не сдох! Локально сломался 👀

Это я просто под эмоциями до сих пор от этого случая 👿 А ведь при такой программе (которая позволяет хранить файлы и работать с ними разным людям) этот кейс должен быть в составе основных проверок. Но обо всем по порядку.

Мне нужна была картинка из книги. Я их обычно беру из папки «Катя и эмоции», куда мы с художницей в своё время нарезали персонажей из книги:

И так как делалось это всё в рамках первой книги, то и картинки эти до сих пор там лежат. Так что я открываю яндекс-диск, папку с книгами, а там... Первой книги нет 😕

Работа в двух вкладках: чит-лист проверок

Ссылка на Хабр

Чит-лист — это шпаргалка по выбранной теме, что не забыть проверить. Берете чит-лист как основу, адаптируете под свой проект, и готово!

В своей книге про тест-дизайн я написала ряд чит-листов, которыми и хочу теперь поделиться. Сегодня поговорим про очень важную тему — одновременное использование. Если говорить про веб-приложение, то это одновременная работа в двух вкладках браузера.

Если в приложении есть возможность открыть одну и ту же форму несколько раз — это обязательно надо проверить:

• Веб — открыть форму в нескольких вкладках браузера.

• Десктоп — там тоже иногда можно открыть в отдельной вкладке форму. Или запустить приложение несколько раз (имитируя разных пользователей).

• Мобилки — открыть с разных устройств.

Параллельное выполнение одинаковых действий часто ломает систему. Поэтому обязательно проверяем. Тем более что совместная работа — вполне распространенный кейс работы с программой. Те же гуглодоки для того и нужны, чтобы работать с ними вместе или самому с разных компьютеров.

Пройдемся по операциям CRUD (create, read, update, delete) и посмотрим на чек-листы для каждого типа!

1 автотест = 1 проверка (на примере Postman-a)

Вообще это правило и ручных тестов касается, но сегодня поговорим на примере автоматизации в Postman. Итак, общее правило тестов, особенно автоматических:

1 тест = 1 проверка

Почему именно так? Да потому что проще будет понять "почему всё упало".

Давайте посмотрим на примере Users. Дергаем метод http://users.bugred.ru/tasks/rest/getuser:

{

  "email": "test_cu_11@mail.com"

} 

* Email может меняться, так как система живая, данные создаются и удаляются.

Итак, мы хотим проверить ответ и пишем такой автотест:

Генераторы картинок (подборка инструментов)

Для тестирования иногда нужны картинки определенных размеров. В этой статье я собрала разные сервисы, на которых можно легко получить картинку нужного размера. 

Это может быть как dummy image, то есть «пустышка», так и картинка на определенную тематику (чтобы не так скучно было) — котики, бекон, актеры... В пустышках удобно то, что сразу виден размер картинки. А с остальными не так скучно, особенно если тестировать аватарку =)

Большинство сервисов из этого поста — те, которые генерят картинку по размерам, ширине и высоте. Если нужно по весу, то см пункт 14. Ширину и высоту можно подменять прямо в URL почти везде — это удобно, можно за один раз наклепать себе с десяток тестовых данных. 

1. Dummyimage.com

Создает «пустышки» — картинки нужного размера без излишеств. Внутри картинки прописан её размер, не более.

Очень удобный интерфейс — открыл сайт, ввел ширину-высоту (цвет и формат по желанию) — перешел по сгенеренной ссылке и сохранил. Если нужно несколько картинок, то можно менять размеры прямо в URL. Пример картинки размером 600 на 500:

https://dummyimage.com/600x500/000/fff   

 

2. Placeholder.com

Тоже создает «пустышки» картинки нужного размера. Но на этом сайте на главной странице слишком много «лишней» информации, воспринимается сложнее. Впрочем, можно это всё не читать, а указывать размеры прямо в URL. Примеры картинок:

https://via.placeholder.com/150         — квадрат 150 на 150

http://via.placeholder.com/640x360   — прямоугольник 640 на 360

Визуализация ТЗ — диаграммы, схемы, картинки

Чем проще и понятнее описаны требования — тем меньше багов будет в функционале. Потому что не будет разных прочтений, додумок и прочего. А еще в простыне текста легко потеряться и что-то просто забыть реализовать.

Как же сделать ТЗ понятнее? Можно улучшить текст — вместо скупого текста составить вариант использования. А можно использовать визуализацию. То есть добавить в требования картинки, диаграммы, таблицы...

Причем сделать это может не только аналитик, но и любой член команды. Тестировщикам особенно полезно визуализировать ТЗ, потому что это помогает сразу увидеть проблемные места и уточнить их ещё до реализации. Раннее тестирование и всё такое.

State & Transition Diagram — что это и как применять

 State & Transition Diagram (сокращенно S&T) — схема состояний и переходов. Техника для визуализации ТЗ. Она наглядно показывает, как некий объект переходит из одного состояния в другое.

Вот объект находился в состоянии А, потом произошло какое-то действие, и он попал в состояние В. Потом он попадет в состояние С и другие... Принцип не меняется, было одно состояние, стало другое.

Decision Table — что это и как применять

Decision Table (таблица решений) — техника, помогающая наглядно изобразить комбинаторику условий из ТЗ.

Чем проще и понятнее требования, тем меньше будет разночтений. И тем меньше исправлений после реализации. И тем проще нам, тестировщикам, писать тест-кейсы по таким требованиям ))

Ссылка на ХАБР

В тестировании таблица решений используется для того, чтобы на основе требований составить тест-кейсы. И ничего не забыть при сложных комбинациях входных условий! Ведь каждая строка или столбец таблицы → готовый тест-кейс.

Пример чек-листа для smoke-тестов с реального проекта

 

Скачать чек-лист «Экспресс-тестирование»

Это реальный чек-лист с реального проекта (с разрешения бывшего руководства), на котором я работала 9 лет назад. Я ничего в нем не приукрашивала сейчас, чтобы он выглядел более качественно или круто. Разве что удалила название системы ¯\_(ツ)_/¯

Это чек-лист для быстрой проверки релиза на production, то есть на реальном сервере, с которым работают пользователи. Мы тогда называли это «экспресс-тестирование», но по сути это smoke-тесты. Когда мы базово проверяем работу системы, не закапываясь сильно в конкретный функционал.

Пример чек-листа на ролевые модели с реального проекта!

Скачать чек-лист на модуль «Здания»

Это реальный чек-лист с реального проекта (с разрешения бывшего руководства), на котором я работала 9 лет назад. Я ничего в нем не приукрашивала сейчас, чтобы он выглядел более качественно или круто. Разве что удалила название системы ¯\_(ツ)_/¯

Как понятно из названия, тестируемый модуль — «Здания». В системе можно было создавать здания, точки присутствия, назначать ответственных за всё это дело... Соответственно, была сделана ролевая модель. Это когда есть разные пользователи с разным уровнем доступа:

• Админ системы — полный доступ везде
• Админ зданий — полный доступ к зданиям (но не к пользователям)
• Ответственный за здание — простой пользователь, которому дали полный доступ к одному или нескольким зданиям
• ...

В чек-листе проверяется:

• Функционал самого модуля — всякие там вариации ввода адреса, фоточек и прочего. Функциональное тестирование. Делается под админом, который может всё.
• Ролевая модель — что могут или не могут делать другие пользователи. Особенно важно, что они делать не могут, это тоже надо тестировать, что результат будет «нет доступа».

Название тест-кейса — как оформлять

Главное правило хорошего названия:

 Причем это касается любого названия, будь то тест-кейс или баг.

Из названия тест-кейса я должна понять, какую проверку мне надо провести, не заглядывая в описание шагов. Вот, например, я вижу тест-кейс «Корректное имя»? Корректное — это какое? И какое действие я должна сделать? Куда это корректное имя вводить? При регистрации? Авторизации? В личном кабинете? При указании имени получателя? В загружаемом в систему файле? Где?

Допустим, при регистрации. Правильно ли будет переименовать тест-кейс в «Регистрация с корректным именем»? Или, скажем, сделать общую папку на тестирование регистрации и внутри уже писать «Корректное имя»?

На самом деле это название все равно не отвечает на вопрос «а что мне делать то?». Потому что что такое «корректное имя», я могу и не знать. Для одной системы «Оленька» будет корректно, а для регистрации в гос услагх → нет. Да и даже если обратить в проверкам, которые мы придумали ранее , то сколько там корректных имен? Много! Тогда как будет выглядеть наш набор тест-кейсов? Примерно вот так:

Корректное имя

Корректное имя

Корректное имя

Корректное имя

Корректное имя

....

Некорректное имя

Некорректное имя

Некорректное имя

И если мне дадут задание выполнить тест-кейс с уменьшительно-ласкательной формой имени, то я буду долго его искать среди десятка похожих названий, заходя внутрь каждого, чтобы понять, о чем речь.

Что такое тест-анализ

Тест-анализ — это тот же тест-дизайн, только немного с другим уклоном. На самом деле их часто вообще не различают.

Но если пытаются, то то, что ближе к Коберну:

• State-Transition Testing 
• Decision Table Testing 
• Use Case Testing

Это тест-анализ.

А то, что ближе к комбинационному, то есть уже собственно построение тестов — это тест-дизайн:

• Тест-анализ граничит с аналитикой, 
• Тест-дизайн — с автоматизацией.

Как найти границы на клиенте и сервере

Ссылка на ХАБР (там кликабельное содержание! В блоге такое не сделать)

Как обычно тестировщик ищет границы в поле? Если в ТЗ есть ограничения, то тестирует их. А если их нет? С нижней границей все понятно — это пустое поле. А как найти верхнюю? Вставляем большую строку и смотрим, сколько символов сохранится. И всё…

Но если у нас клиент-серверное приложение, то границы разработчик может поставить на каждом звене!

И тестировщик должен проверить их все. Почему? Потому что когда мы одно значение дублируем несколько раз в разных местах, велик шанс ошибиться. При этом границу на клиенте очень легко снять. Что будет, если пользователь обойдет границу на клиенте? Не сломает ли он нам сайт большой строкой?

В этой статье я расскажу, как искать границы для поля в веб-формочке. Возьмем для примера форму редактирования пользователя в бесплатной системе Users.

Когда применять тест-кейсы

Тест-кейсы нужны, когда у нас:

1. Жизненно важные системы, ошибка в которых может привести к гибели (самолетостроение, медицина, ПО для атомных станций). Здесь надо тестировать очень аккуратно и тщательно. 
2. Сложная система или сложная часть системы. Чтобы каждый раз не вспоминать «а как мне это сделать?», лучше написать тест-кейс.
3. Постоянно новые люди в команде (все джуниоры проходят через этот проект)

Тест-кейсы не нужны:

1. Простые системы (веб-сайты одностраничники, мобильные приложения и т. п.).
2. Ситуации, когда в команде всего один или два тестировщика, знающие свой продукт. Время, потраченное на создание и поддержку тест-кейсов никогда не окупится.

Познакомьтесь со своей системой и потом уже решайте, что подходит именно для нее  — творческие чек-листы, формальные тест-кейсы или микс из этих подходов.

Так как тест-кейсы очень сложно поддерживать, то чаще используют чек-листы или комбинацию "чек-листы & тест-кейсы".

В последнем случае большинство проверок пишут в виде чек-листов, а особо сложные (пойди туда, не знаю куда, принеси то, не знаю что, кувыркнись три раза и громко крикни "ДЕДЛАЙН!", только тогда формочка и откроется) уже в виде тест-кейсов, чтобы каждый раз не вспоминать, как этот хитрый сценарий работает.

PS — это выдержка из моей книги для начинающих тестировщиков, написана в помощь студентам моей школы для тестировщиков

Что такое минимальный файл для воспроизведения бага

Допустим, что у нас есть система, в которую можно загружать файлы:

Пример функционала с загрузкой файла

И вот мы загрузили файл, а система упала. Отчего? Из-за названия, расширения, данных внутри или размеров? Найдите проблему и уберите лишнее:

• Падает из-за названия? Внутри пусть будет 1 ячейка (одна колонка, одна строка)
• Нельзя загрузить больше 10 столбцов? Пусть столбцов будет 10, но лишь 1 строка
• Слишком много строк? Строки оставляем, а колонку делаем одну
• Проблема в конкретном значении? Например, система не может обработать високосный год? Снова оставляем одну ячейку — с этим годом. А еще лучше — пробуем воспроизвести без файла (если система предоставляет альтернативу).

То есть минимальный файл — это в котором ничего лишнего. Минимум:

• строк
• колонок
• данных внутри
• длины имени файла

Но, разумеется, на этом минимальном файле баг должен воспроизводиться. Упадет на одной ячейке? Ок, оставляем только ее. А если система первую строку игнорирует / считывает как «шапку», то нам понадобится уже две строки — одна для шапки, а вторая с «падающим» значением.

Генератор текста нужной длины

https://generator-online.com/text/

Коллега прислала ссылочку, сказав так:

Я нашла отличный сайт для генерации текста нужной длины, именно текста, а не просто строки) Даже кнопка есть — скопировать в буфер обмена, ваще красавчики)

Посмотрела, и правда, классно! Есть несколько языков, но главное, что есть русский! Можно делать абзацы разной величины, надо просто указать min и max символов. Конечно, в русском ответе встречаются слова undefined, но все равно приятная штука!

См также:
Как сгенерить большую строку, инструменты — если неважно, будет текст или просто «аааааа» на миллион символов

PS — статья написана в помощь моим студентам, уже и на Testbase, в навыке подбора инструментов. Теперь не потеряется!

Протестируй треугольник! Онлайн-тренажер

Ссылка на тренажер

Хотите попрактиковаться в тест-дизайне? Заходите к Арсению Батырову на огонек! Он создал онлайн-тренажер для популярной на собеседованиях задачке про треугольник. И даже закопал туда парочку багов 

Тут вы можете попрактиковаться самостоятельно, а потом получить готовый подробный ответ «как надо было тестировать».

Очень хорошая штука, особенно для новичков. Буквально несколько дней назад в чате моей школы для начинающих тестировщиков был такой вопрос:

Нашёл тут в статьях Ольги Назиной задачу про треугольник, которую часто задают на собеседованиях. Но почему-то нигде нету на неё ответа, хотя я так понимаю задача эта часто всплывает то тут то там на собесах. Может кто знает какой правильный ответ нужно дать чтобы интервьюер подумал о тебе как о грамотном тестировщике Джуниор уровня?

Вообще не советую искать готовые ответы. Иначе вы блеснете на собеседовании на этой задаче, но с треском провалитесь на другой. Так что сначала попробуйте сами. И только потом читайте готовый ответ!!!

Но в любом случае штука классная, используйте на здоровье!

PS: Тренажер сохранен на Testbase в разделе «Test it — бесплатные тестовые площадки». Теперь не потеряется!

Dummy image — как создать тестовую картинку

Ссылка — https://dummyimage.com/

Хороший инструмент для проверки граничных значений, если ограничения идет по ширине или высоте. На сайте легко можно создать картинку нужного размера.

Конечно, это не единственный сайт, но довольно популярный. Так что решила написать о нем, добавить в полезные инструменты по тегу ツ

А про альтернативы мы поговорим в следующий раз.

Повтори 24 раза — и сломаешь игру!

Звучит как заклинание, не так ли? ツ
Но ведь оно работает!

Эту историю моя коллега Ольга Алифанова постоянно рассказывает студентам. Случай из ее опыта тестирования игр:

Если подменить пакет дешевого барахла на дорогое через артмани, в клиенте будет виден дорогой предмет, но сервер знает правду, другие игроки через обмен или аукцион увидят правду. Но! Если 24 раза положить его на склад и забрать обратно, сервер начнет верить клиенту. Вот как игрокам это в голову пришло? А они этот баг нашли. И в итоге сломали экономику сервера.

Просто абстрактный аукцион из интернета

Теперь немного поясню:

В тестировании всегда начинаем с простого!

Сегодня я хочу поговорить про тест-дизайн и тест-анализ. Навеяно ситуацией с работы, но и у студентов часто встречается. Применение техник — это здорово и круто! Но, пожалуйста, не надо усложнять.

Когда люди узнают про тест-анализ, про то, что можно сокращать количество тестов, объединяя несколько в один и выкидывая малоприоритетные, в головах устанавливается какой-то флажок «Меньше тестов = круче!». Иначе не знаю, как это объяснить.

Мои тесты, не отдам!

Проводила ревью автотестов джуниора (назовем его Вася) на сложную задачу: API-метод, возвращающий результаты поиска с некоторым набором параметров. Параметров много, поэтому и вариаций тестов много. В теории.

Смотрю на результат — получилось 30 тестов, описание которых не понимаю даже я. При том, что я на проекте работаю 6 лет и знаю его очень хорошо. А описание нам надо отправить заказчику.