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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Панбагон. Ошибка печати в кассе, когда ленты нет, но стоит галка "не печатать чек"

У меня тут отличный пример тестирования нижней границы нарисовался! 

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

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

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

Чек-лист — как тестировать поиск

Я посмотрела, как тестируют поиск начинающие тестировщики, и решила написать этот чит-лист проверок. Это такая серебряная пуля, которую можно применить на любом проекте, лишь немного варьируя под себя, под свой проект.

Поиск — он же есть практически в каждой системе. Поэтому здорово, когда есть шпаргалка «какие вопросы задать аналитику» и «какие проверки провести». Именно это мы в статье и обсудим. Сначала я дам чек-лист, а потом разберу каждый пункт отдельно.

Ссылка на ХАБР (там кликабельное оглавление)

Три имени квадрата и пересечение классов эквивалентности

В книге Юлии Гиппенрейтер «Как учиться с интересом» я нашла такую историю о занятиях Александра Звонкина с детьми:

Обсуждаются сделанные из картона фигуры: квадрат, прямоугольник и неправильный четырехугольник. Мы детально обсуждаем их свойства. Прежде всего, у всех фигурок — по четыре угла. Значит, каждую из них мы можем назвать четырехугольником. Итого: у нас три четырехугольника. 

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

У квадрата как бы три имени: его можно назвать и квадратом, и прямоугольником, и четырехугольником — и все будет правильно.

Моя информация встречается не без сопротивления. Дети упорно стремятся мыслить в понятиях непересекающихся классов.

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

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

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

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

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

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

Классы эквивалентности для имен

Какие могут быть имена:

• свое, короткое, длинное, составное, на английском, транслитерация, регистр
• полное, краткое, уменьшительное: Ольга, Оля, Оленька
• буквы, которые одинаково выглядят на русском и на английском: Oльга и Ольга
• имя, с которого может начинаться фамилия и/или отчество: Александр(ов)
• или не может: Михаил никак не может начинать отчество, потому что в русском языке И в Й перейдет
• имена, у которых возможны разные варианты написания: Наталья/Наталия, Алена/Алёна
• имя, которое бывает и полной формой, и краткой одновременно (Лана, Ася). Может быть и Лана, и Ася по паспорту, а могут быть Светлана и Анастасия
• имя, которое в мужском и женском варианте отличается только окончанием, особенно интересно в подсказках — оба варианта система покажет или только один? (Александр/Александра, Владлен/Владлена)

Нужно ли каждый раз проводить все эти тесты? Конечно, нет! Все зависит от проекта, доступа к коду, времени, отведенного на тестирование...

Ивану кредит не давать!

Пару лет назад мой коллега Иван зашел на сайт банка Х и попробовал оставить заявку на кредит. Ввел ФИО и получил отлуп — «Имя «Иван» вводить нельзя».

Оказалось, что это криво реализованная защита от дурака. ФИО «Иванов Иван Иванович» вызывает подозрение. Скорее всего, это вымышленные данные, которые ввел тестировщик, или человек, который просто дурачится, не хочет давать свои данные.

Конечно, даже Иванов Иван Иванович может встретиться, но таких очень мало и с ними проще работать в ручном режиме. А от вымышленных данных защититься.

Проблема в том, что нужно было запретить связку: имя Иван и фамилия Иванов и отчество Иванович. То есть условие в коде записать через AND.

А разработчики сделали через OR: если фамилия Иванов ИЛИ имя Иван ИЛИ отчество Иванович — получай ошибку!

Так что увы, все Ивановы, и даже просто Иваны. Таких имен нет, выберите другое!

**************************************************************************

Это реальная история, не вымышленная. Я писала о ней в статье «Классы эквивалентности: будни Золушки» — как пример того, что вроде выделил классы эквивалентности, а баг пропустил!

Mockaroo — генератор реалистичных тестовых данных. CSV, XLS, JSON, XML...

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

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

• Он создаст CSV и Excel для тестирования загрузки файлов.
• Он создаст JSON и XML для тестирования API
• И другие форматы по необходимости

Очень неплохой инструмент для тестировщика! Допустим, вы тестируете систему, в которую надо загружать файлики с данными. Можно, конечно, наколбасить файлик самому, но есть проблемы:

1. Сделать большой файл с реалистичными данными будет долго и уныло
2. А если раскопипастить везде значение «Тест», вы можете не найти баг, который легко поймают реальные данные

Помимо CSV и XML, меня особенно радует поддержка JSON и XML — инструмент можно использовать для генерации данных при тестировании API!

Мнемоника БМВ для поиска граничных значений

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

Исходно статья опубликована на Хабре, там у нее есть удобное оглавление, чтобы не листать многабукафф, а сразу перейти куда надо. В блоггере такое сделать сложнее, увы и ах 
╮(︶︿︶)╭

Мнемоника — слово или фраза, которая помогает нам что-то запомнить. Самая известная мнемоника — «каждый охотник желает знать, где сидит фазан». Кого не спроси, все с ней знакомы.

А вот в профессиональной сфере все немного грустнее. Спросите товарищей, знают ли они, что такое SPDFOT или RCRCRC. Далеко не факт… А ведь мнемоники помогают нам прогнать тесты, не забыв проверить самое важное. Чек-лист, схлопнутый в одну фразу!

Англоязычные коллеги-тестировщики активно используют мнемоники. Знакомая, читающая иностранные блоги, говорит, что американцы придумывают их чуть ли не на каждый чих.

И я думаю, что это здорово. Чужая мнемоника может не подойти именно под вашу систему или ваши процессы. А свое, родное, напомнит «не продолбать проверить вот это и это» и ограничит количество багов в продакшене.

Сегодня я хочу поделиться с вами своей мнемоникой БМВ для исследования граничных значений. Ее можно:

• дать джуниору для общего развития в тест-дизайне;
• использовать на собеседовании — задачу «найди границу в числе» кандидат обычно решает, а вот найдет ли он границу в строке или для загрузки файла?

Мнемоника БМВ

Б — большой
М — маленький
В — в самый раз

БМВ — большой, маленький, в самый раз

Ее легко запомнить. Просто вспоминаешь эту классную машинку и сразу расшифровка готова! Но что она значит и как поможет на собеседованиях?

Классы эквивалентности для строки, которая обозначает дату

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

Но потом доходит до дела и сразу ступор: а как применять классы эквивалентности где-то еще? Ладно, используем правило «ищи число»: если речь идет о поле с символами, берем длину поля (число) и тестируем на границы. Вроде все хорошо, логично и понятно.

Однако на своих студентах я заметила, что это правило стало серебряной пулей. Если это нечисловое поле — по границам тестируем ТОЛЬКО на длину. Точка. Просишь протестировать дату, получаешь примерно такой ответ:

• Нормальная дата (17.03.2018)
• Дата «в прошлом» или «в будущем» (смотря что подходит под ваше ПО)
• Пустое поле
• Нафигачили туда 100500 символов
• Ввели «0»

За сим границы и проверены. И даже ноль проверен, чем тренер недоволен? А тренер недоволен тем, что по границам вместо ДАТЫ тестируется СТРОКА. Поэтому я предлагаю написать проверки именно для даты. И прежде, чем читать дальше, отложите книгу в сторону и попробуйте сами набросать эти проверки.  А потом сравните, все ли вы нашли?

Четкий формат дд.мм.гггг

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

С тремя параметрами работает, а с одним — NPE

Это не совсем панбагон, так как проблему нашли и обезвредили на этапе тестирования. Так, байка с работы, которая хорошо иллюстрирует мысль «начинайте с простого!».

Что тут у нас?

Мы добавили некую сущность, которая в том числе должна возвращаться в ответе API поискового метода. У метода есть пачка разных параметров, из которых обязательный только один — query, поисковый запрос.

Разработчик сделал один автотест «для себя», для отладки:

<magicSearch xmlns="http://some_url/soap/2_13">
    <query>Иванов</query>
    <partyType>PHYSICAL</partyType>
    <include>
        <partyInfo>SOME_PARAMS</partyInfo>
    </include>
</magicSearch>

Все работает!

Сколько места в БД выделить названию организации?

Вот у вас есть сайт, на котором могут зарегистрироваться компании. При создании базы сколько места дадите под название организации?

name  NVARCHAR2(100)

name  NVARCHAR2(300)

name  NVARCHAR2(500)

Что привлекательнее? А разумнее? Правильно — ничего 

Рано или поздно вы огребете что-то типа too large for field 'name' (actual: 340, maximum: 300). 

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

Пример для теста из реальной жизни — 876 символов (ИНН 5406649116, проверьте на https://egrul.nalog.ru/):

ОБЩЕСТВО С ОГРАНИЧЕННОЙ ОТВЕТСТВЕННОСТЬЮ СИБИРСКИЕ ТРАДИЦИИ В КОМПЛЕКСНОМ ПРАВОВОМ (ЮРИДИЧЕСКОМ) ОБЕСПЕЧЕНИИ ГРАЖДАН И ЮРИДИЧЕСКИХ ЛИЦ ВСЕХ ГРАЖДАНСКО-ПРАВОВЫХ ФОРМ И ВСЕХ СФЕР ХОЗЯЙСТВЕННОЙ ДЕЯТЕЛЬНОСТИ НА ТЕРРИТОРИИ Г. НОВОСИБИРСКА, НОВОСИБИРСКОЙ ОБЛАСТИ В ЦЕЛОМ, В ТОМ ЧИСЛЕ СУДЕБНОЕ И ДОСУДЕБНОЕ СОПРОВОЖДЕНИЕ ИНТЕРЕСОВ КЛИЕНТА, А ИМЕННО: ПРЕДОСТАВЛЕНИЕ ПИСЬМЕННЫХ ИЛИ УСТНЫХ КОНСУЛЬТАЦИЙ И ЗАКЛЮЧЕНИЙ ПО ПРАВОВЫМ ВОПРОСАМ В СФЕРЕ БИЗНЕСА (ПРАВОВОЙ АУДИТ); СОСТАВЛЕНИЕ ДОКУМЕНТОВ ПРАВОВОГО ХАРАКТЕРА (ЗАЯВЛЕНИЯ, ЖАЛОБЫ И Т.П.), В ТОМ ЧИСЛЕ ПРОЕКТОВ ГРАЖДАНСКО-ПРАВОВЫХ И ИНЫХ ДОГОВОРОВ; ОСУЩЕСТВЛЕНИЕ ЭКСПЕРТИЗЫ ПРЕДСТАВЛЕННЫХ ЮРИДИЧЕСКИХ ДОКУМЕНТОВ НА ПРЕДМЕТ ИХ СООТВЕТСТВИЯ ИНТЕРЕСАМ КЛИЕНТА И ПОЛОЖЕНИЯМ ДЕЙСТВУЮЩЕГО ЗАКОНОДАТЕЛЬСТВА; ОКАЗАНИЕ ПРАВОВОЙ ПОМОЩИ ПРИ ПРОВЕДЕНИИ ПЕРЕГОВОРОВ; ПРЕДСТАВЛЕНИЕ ИНТЕРЕСОВ КЛИЕНТА В АДМИНИСТРАТИВНЫХ И ИНЫХ ОРГАНАХ (УЧРЕЖДЕНИЯХ);

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

Если название выводится в личном кабинете — проверьте, не обрезается ли оно там?

Если название светится еще где-то в системе, всегда полезное проверить, что будет, если оно длинное? Влезет ли? 

Класс эквивалентности «Ноль-не ноль»

Всегда тестируй ноль!

Всегда тестируй «ноль». Всегда:

— Заказ пиццы? Купить ноль штук.

— Калькулятор? Разделить на ноль.

— Видеоплеер? Открыть файл размером ноль байт.

Именно в нуле любят собираться ошибки. На сайте вроде просто поле, а где-то внутри система делит на него при подсчете процента покупки. Подставил ноль — все сломалось. Профит! Баг! Или продуман только позитивный сценарий — всегда заказывают больше нуля книг / пицц / настолок. Ввел ноль, а код обработки значения не написан. Опять сломалось… Или оставил поле пустым, а система тебе БАЦ, и эксепшен...

Поэтому тестируй ноль! Где? Давайте посмотрим.

Поле ввода — цифры есть

Числовое поле

Тут все просто. Если видим числовое поле, пробуем ноль

Число книг: ноль / не ноль.

Кол-во пар обуви: ноль / не ноль.

Возраст пациента: ноль / не ноль.

Номер заказа: ноль / не ноль.

Выручка в рублях: ноль / не ноль.

Коэффициент похожести: ноль / не ноль.

...

Заказ книг на OZON. Количество товара — числовое поле

Это логично, такую проверку делают многие. Легко найти число в числовом поле! :-)

Но что, если поле не числовое? Сразу затык.

Технологическая граница в подсказках по ЮЛ

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

Нас часто спрашивают — «Какие баги мы не нашли?». Сегодня я хочу рассказать о баге, который нашелся в подсказках Дадаты, и который хорошо показывает, зачем и как пытаться искать технологические границы.

Для поиска технологической границы надо пихать «Войну и мир» во все доступные для ввода поля. ВО ВСЕ!

Стоит там ограничение или нет → все равно пытаемся пропихнуть.
Взять ту же форму регистрации.

Искать границу надо только там, где нет ограничений?

Поле «Имя» ограничено по вводу, поля пароля — нет. Это не значит, что «Войну и мир» надо вставлять только в пароль. В имя тоже пытаемся. Можно ли ввести больше N символов? А если вкопипастить? А если посмотреть на HTML и снять ограничение по длине?

Классы эквивалентности: будни Золушки

Позор тебе! — кричит начальник, найдя в приложении баг. Даже если не кричит, все равно стыдно: как я могла пропустить такое? Это же так очевидно, почему же не учла? Потому что не подумала об этом классе эквивалентности.

Искать классы эквивалентности сложно даже мне, тестировщику с 7+1-летним опытом — что говорить о моих студентах. В книгах и на лекциях ребятам все понятно. Но как только доходит до практики, начинается ступор. Как же их искать, классы эти? Я придумала аналогию с диснеевской героиней — Золушкой. Ребята говорят, лекция стала понятнее.

Будни Золушки

Мачеха рассыпала на полу гречку и овес, перемешала и сказала — «Разбирай!». Золушка три часа раскладывала кучки. Итог мучений — гречка к гречке, овес к овсу.

 

                           ↓

В каждом мешке своя крупа  — свой класс эквивалентности

В тестировании то же самое: выделяем классы эквивалентности (крупу), ищем исключения, перепроверяем. Результат — ошибки находят тестировщики, а не начальство.

Баги повсюду. «Планета самоцветов» и ежедневный бонус

Скачала игрушку от Nevosoft «Планета самоцветов». Составляешь три одинаковых по цвету самоцвета в ряд — они взрываются, ты получаешь очки. Если самоцвет стоит на ячейке, она взрывается вместе с ним.

Планета самоцветов — игра «Три в ряд»

Каждый уровень дает цель и средства: взорвать 30 ячеек за 15 ходов, набрать 1500 очков за 30 секунд... Со временем уровни усложняются, появляются неразбиваемые ячейки, самоцветы «в цепях», которые взрывать надо дважды, бомбы и пустые ячейки.

Не успел выполнить цель исходными средствами? Потерял жизнь. Потерял все жизни — жди, пока они восстановятся. Одна жизнь восстанавливается один час. Максимум может быть 5 жизней.

Классы эквивалентности для редактирования сообщения

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

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

Давайте возьмем для примера сайт http://ru.qahelp.net/.
Там можно создавать вопросы и отвечать на них. К каждому вопросу и ответу можно добавлять комментарии.

Я задала своим выпускникам онлайн-интенсива простой вопрос, как мы будем тестировать возможность редактирования ответа на вопрос?

Результаты порадовали (варианты очень интересные):

1. Что я могу редактировать свой ответ.
2. Что я могу открыть для редактирования и передумать, нажать отмену. Должно сохраниться прежнее состояние.
3. Если пишется дата создания ответа, то:
   3.1: Действительно ли такое время и дата. Может быть другой GMT
   3.2: Какая дата после редактирования и сохранения изменений: старая или новая.
4. Не внести изменения и сохранить. Должно остаться прежним. Со временем - как в 3.2
5. Если были комментарии к ответу, то что с ними происходило после 1-4. Должны сохраняться.
6. Проверить что все инструменты для редактирования работают.
7. Ответ может быть "простой" и кем-то откомментированный (тобой же или другим человеком).
8. Открыть для редактирования сразу в 2 вкладках и отредактировать. Проверить синхронность.
9. Открыть одновременно в двух вкладках для редактирования. В первой вкладке выйти из режима редактирования и удалить. Во второй вкладке сохранить редактируемое. Обновить вкладку во втором браузере. Вопрос: останется во второй вкладке или исчезнет?..

Хороший чек-лист, грамотное выделение классов эквивалентности 

Но что из этого надо проверить в первую очередь? Если пользователь не стремится специально разломать систему, то для него в первую очередь важно, чтобы кнопка редактирования в принципе работала. А потом уже всякие дата-время, внезапная отмена и прочая-прочая.

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

Но давайте пока временно отбросим эту проверку, отнеся ее к негативным тестам. У нас должна быть возможность редактировать ответ. Отлично! А какой ответ бывает?

• Свой.
• Чужой.

Другие варианты разделения на классы эквивалентности?

• "Простой".
• Откомментированный.

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

********************************************

Шаги для воспроизведения:
1.       Даем ответ на чей-нибудь вопрос.
2.       Просим коллегу его прокомментировать
3.       Нажимаем «редактировать»

Результат
Ничего не происходит 
См пример тут - http://ru.qahelp.net/question/skolko-tratite-na-samoobrazovanie/

Я не могу исправить очепятку в своем посте, потому что его уже откомментили (если еще не комментировали, то редактирование работает, проверила тут - http://ru.qahelp.net/question/vash-top-5-dokladov-s-sqa-days-vseh-vremen/).

Ожидаемый результат
Открывается форма редактирования.

********************************************

Собственно говоря, нашла эту ошибку я чисто случайно. Заметила у себя опечатку, попробовал отредактировать, а фиг.

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

Не просто "аааа, фсе пропало, РЕДАКТИРОВАНИЕ НЕ РАБОТАЕТ НИГДЕ!!!", а грамотно, с локализацией ошибки. На то мы и тестировщики 

Напоследок хочу сказать, что всегда пробуйте посмотреть на задачу с разных сторон. Сначала с точки зрения пользователя "Что я могу делать? Ага, а какие состояния могут быть у этого элемента, которые могут мне помешать (такие, как комментарий в нашем примере)?".

А потом не вредно посмотреть и с точки зрения тестировщика — "Крушить, ломать! ПО побеждать". Удачи в поисках интересных классов эквивалентности