Позор тебе! — кричит начальник, найдя в приложении баг. Даже если не кричит, все равно стыдно: как я могла пропустить такое? Это же так очевидно, почему же не учла? Потому что не подумала об этом классе эквивалентности.
Искать классы эквивалентности сложно даже мне, тестировщику с 7+1-летним опытом — что говорить о моих студентах. В книгах и на лекциях ребятам все понятно. Но как только доходит до практики, начинается ступор. Как же их искать, классы эти? Я придумала аналогию с диснеевской героиней — Золушкой. Ребята говорят, лекция стала понятнее.
Будни Золушки
Мачеха рассыпала на полу гречку и овес, перемешала и сказала — «Разбирай!». Золушка три часа раскладывала кучки. Итог мучений — гречка к гречке, овес к овсу.
↓
В каждом мешке своя крупа — свой класс эквивалентности
В тестировании то же самое: выделяем классы эквивалентности (крупу), ищем исключения, перепроверяем. Результат — ошибки находят тестировщики, а не начальство.
Выделяем крупу
В программе есть большая куча разных значений, которые можно проверить — куча крупы вперемешку. Мы пытаемся их разделить, выделить классы эквивалентности: понять, где гречка, где овес, а где чечевица.
Протестируем поле ввода имени при регистрации.
Имеет ли смысл вводить «Маша» и «Ольга»? В окне приветствия будут отображаться разные имена, но мы проверяем распространенные женские имена. Если регистрация работает на одном примере, на втором наверняка тоже. Кидаем к гречке оба: они в одном классе эквивалентности
А что насчет «Ивана»? Тоже распространенное имя, но мужское. А что, если система после регистрации присылает письмо «Уважаем(ый/ая)...»? Тогда реакция на разный пол должна быть разная. Кидаем к овсу, это уже не гречка, а другой класс эквивалентности
А что насчет «Розалинд Аруша Аркадина Алталун Флоренс Луна» ? Берем максимально большое имя, которое влезает на экран. Что будет? Мы предполагаем, что оно может вылезти за границы экрана. Кидаем к чечевице, это уже не гречка и не овес, а другой класс эквивалентности.
Где гречка, а где овес — определяем «на глазок». Используем логику и пытаемся понять, что уникального в данном конкретном поле. Видим там не просто «строковое поле», абстрактную крупу, а конкретику — если имя, то может быть простым, составным, унисекс…
Ищем исключения
Когда собрали гречку, изучаем мешок: сравниваем крупинки, они должны быть идентичны.
Я ввожу в поле «имя» формы регистрации: “Ольга” или “Маша”.
Нет разницы.
То, что все значения внутри класса одинаковые — обман зрения. Невозможно найти все баги в приложении или разобрать 2 миллиона крупинок и ни разу не ошибиться. Среди гречки попадается чечевица!
Вспомним поле ввода имени.
«Максим» и «Иван» — распространенные мужские имена, один класс.
Но при проверке «Максим» работает, а «Иван» — нет. Нельзя вводить меньше 5 символов. Или нельзя вводить имя «Иван».
Месяц назад мои коллеги зашли на сайт банка Х и попробовали оставить заявку на кредит. Ввели ФИО и получили отлуп — «Имя «Иван» вводить нельзя». И фамилию «Иванов», и отчество «Иванович».
Разработчики поставили защиту от тестовых данных — «Иванов Иван Иванович» вызывает подозрение. Но только условие связки компонентов выбрали OR, а не AND и нельзя было быть даже просто Иваном… Если фамилия Иванов ИЛИ имя Иван ИЛИ отчество Иванович — получай ошибку! Вам смешно, а это разные классы эквивалентности!
Мы выделили класс эквивалентности, мы собрали мешочек гречки и сказали, что здесь все идентично. Но мы могли ошибиться, что-то забыть, что-то не заметить. И именно поэтому мы должны все время использовать разные значения. Выделили для поля с именем «распространенные мужские имена», сегодня вводим «Иван», завтра «Максим»…
Перепроверяем
Тестирование — неточная наука, мы можем ошибаться в своих предположениях.
Даже если приложение работает одинаково на любых строках, даже если в требованиях говорится, что разницы между «Анной» и «Анной-Марией» нет, а мы все равно сомневаемся — проверяем. Требования — одно, код — совсем другое. Разработчики тоже ошибаются, вместо «только имена» читают «только одно слово с именем» и ставят ограничение на двойные имена. Или додумывают требование, что длинне 6 символов имен не бывает.
Лучше перебдеть, выполнить 20 тестов и найти баг, чем выполнить 10 и продолбать проблему.
Резюме
Выделите классы эквивалентности (отдельно гречка, отдельно чечевица), поищите исключения и каждый раз используйте немного разные крупинки из кучки одного и того же класса.
- Подумайте, какими бывают «тестируемое поле».
- Представьте, какими не бывают «тестируемое поле».
- Поищите границы.
Из кучи возможных значений выделите группы классов эквивалентности
Домашнее задание
Проверка номера кредитной карты — как будете тестировать?
Наводящие вопросы:
- Каким чаще всего бывает номер?
- Каким он точно не бывает?
- Можно ли его писать и слитно, и через несколько пробелов?
- Что, если пробелы будут в «неправильных» местах?
- Что, если в номере будут буквы?
- Что, если номер будет пустой?
- Что, если номер будет длиннее положенного?
- Что, если номер будет из сплошных нулей?
- ...
PS — это выдержка из моей книги для начинающих тестировщиков, написана в помощь студентам моей школы для тестировщиков
Картинки позаимствованы из лекций, интернета и от моей художницы Вики :-)
Когда я вижу в анонсах (твиттер, рассылка software testing и тп) слова "классы эквивалентности", то четко понимаю кто статью написал ;)
ОтветитьУдалитьИ ведь это еще не конец! :-)
УдалитьСпасибо! Прекрасный стиль изложения. Много полезного нашёл для себя.
ОтветитьУдалитьНе за что! Рада, что вам пригодилось ^_^
УдалитьОльга здравствуйте. Очень нужен Ваш совет и профессиональная помощь по классам эквивалентности.
ОтветитьУдалитьЕсть некое поле "Сумма (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, а далее тестить и оформлять?
Просто каша в голове! Запутался.
Ольга пожалуйста помогите разобраться в данном вопросе. Спасибо.
Сама таблица является чек-листом. А так да, позитив можно объединять, негатив не стоит. Для негатива пикт не нужен, оформите отдельно. Но вообще надо отталкиваться от того, на что эти поля влияют, и тут скорее decision table вам нужен
Удалить