пятница, 24 июля 2015 г.

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

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


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


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



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


mixed-groats-image.jpg  mixed-groats-macro-17517869.jpg
                           ↓
Рисунок4.jpg
В каждом мешке своя крупа  — свой класс эквивалентности


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


Выделяем крупу


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


Протестируем поле ввода имени при регистрации.


Имеет ли смысл вводить «Маша» и «Ольга»? В окне приветствия будут отображаться разные имена, но мы проверяем распространенные женские имена. Если регистрация работает на одном примере, на втором наверняка тоже. Кидаем к гречке оба: они в одном классе эквивалентности


А что насчет «Ивана»? Тоже распространенное имя, но мужское. А что, если система после регистрации присылает письмо «Уважаем(ый/ая)...»? Тогда реакция на разный пол должна быть разная. Кидаем к овсу, это уже не гречка, а другой класс эквивалентности


А что насчет «Розалинд Аруша Аркадина Алталун Флоренс Луна» ? Берем максимально большое имя, которое влезает на экран. Что будет? Мы предполагаем, что оно может вылезти за границы экрана. Кидаем к чечевице, это уже не гречка и не овес, а другой класс эквивалентности.


Где гречка, а где овес — определяем «на глазок». Используем логику и пытаемся понять, что уникального в данном конкретном поле. Видим там не просто «строковое поле», абстрактную крупу, а конкретику — если имя, то может быть простым, составным, унисекс…


Ищем исключения


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


Я ввожу в поле «имя» формы регистрации: “Ольга” или “Маша”.
Нет разницы.


Снимок.PNG


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


Снимок2.PNG


Вспомним поле ввода имени.
«Максим» и «Иван» — распространенные мужские имена, один класс.
Но при проверке «Максим» работает, а «Иван» — нет. Нельзя вводить меньше 5 символов. Или нельзя вводить имя «Иван».


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


Разработчики поставили защиту от тестовых данных — «Иванов Иван Иванович» вызывает подозрение. Но только условие связки компонентов выбрали OR, а не AND и нельзя было быть даже просто Иваном… Если фамилия Иванов ИЛИ имя Иван ИЛИ отчество Иванович — получай ошибку! Вам смешно, а это разные классы эквивалентности!


Мы выделили класс эквивалентности, мы собрали мешочек гречки и сказали, что здесь все идентично. Но мы могли ошибиться, что-то забыть, что-то не заметить. И именно поэтому мы должны все время использовать разные значения. Выделили для поля с именем «распространенные мужские имена», сегодня вводим «Иван», завтра «Максим»…


Перепроверяем


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


Даже если приложение работает одинаково на любых строках, даже если в требованиях говорится, что разницы между «Анной» и «Анной-Марией» нет, а мы все равно сомневаемся — проверяем. Требования — одно, код — совсем другое. Разработчики тоже ошибаются, вместо «только имена» читают «только одно слово с именем» и ставят ограничение на двойные имена. Или додумывают требование, что длинне 6 символов имен не бывает.


Лучше перебдеть, выполнить 20 тестов и найти баг, чем выполнить 10 и продолбать проблему.


Резюме



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


  1. Подумайте, какими бывают «тестируемое поле».
  2. Представьте, какими не бывают  «тестируемое поле».
  3. Поищите границы.


Из кучи возможных значений выделите группы классов эквивалентности

Домашнее задание



Проверка номера кредитной карты — как будете тестировать?


Наводящие вопросы:
  1. Каким чаще всего бывает номер?
  2. Каким он точно не бывает?
  3. Можно ли его писать и слитно, и через несколько пробелов?
  4. Что, если пробелы будут в «неправильных» местах?
  5. Что, если в номере будут буквы?
  6. Что, если номер будет пустой?
  7. Что, если номер будет длиннее положенного?
  8. Что, если номер будет из сплошных нулей?
  9. ...


PS — это выдержка из моей книги для начинающих тестировщиков, написана в помощь студентам моей школы для тестировщиков
Картинки позаимствованы из лекций, интернета и от моей художницы Вики :-)
Статья добавлена на Testbase в навык выделения классов эквивалентности. Теперь не потеряется!

6 комментариев:

  1. Когда я вижу в анонсах (твиттер, рассылка software testing и тп) слова "классы эквивалентности", то четко понимаю кто статью написал ;)

    ОтветитьУдалить
  2. Спасибо! Прекрасный стиль изложения. Много полезного нашёл для себя.

    ОтветитьУдалить
  3. Ольга здравствуйте. Очень нужен Ваш совет и профессиональная помощь по классам эквивалентности.
    Есть некое поле "Сумма (100тр-500тр)" и поле "взнос (0-50%)".
    Выделяем КЭ = 100`000-500`000, гранич знач = 99`999, 100`001, 499`999, 500`001, особые точки = 0, 99`999, 100`000, 100`001, 250`000, 499`999, 500`000, 500`001, и по аналогии с полем "взнос"

    В итоге избежав переизбытка в тестах, внес в pict:
    сумма: #99999, 100000, 250000, 499999, 500000, #500001
    взнос: #-1%, 0%, 25%, 49%, 50%, #51%
    # - негативные тесты.

    В итоге pict выдал: 17 позитивных и 16 негативных (всего 33) тестов.
    Вопрос: как все это оформить, в виде тест-кейсов или чек-лист или сама таблица xls которую выдал pict является чек-листом? Тест-кейсов получается слишком много или позитивные можно объединить, а негативные все отдельно друг от друга?

    Как тогда быть с негативными классами эквивалентности, если выделять их также в диапазоне чисел поля, но вводить спец.символы, отрицательные числа, буквы латин и кириллиц и т.д. их тоже надо вносить в pict, а далее тестить и оформлять?
    Просто каша в голове! Запутался.
    Ольга пожалуйста помогите разобраться в данном вопросе. Спасибо.

    ОтветитьУдалить
    Ответы
    1. Сама таблица является чек-листом. А так да, позитив можно объединять, негатив не стоит. Для негатива пикт не нужен, оформите отдельно. Но вообще надо отталкиваться от того, на что эти поля влияют, и тут скорее decision table вам нужен

      Удалить