Home

Автор: Джеймс Бах (James Bach)

Оригинал статьи: http://www.satisfice.com/blog/archives/1669

Перевод: Ольга Алифанова

Статья в Википедии о классах эквивалентности – это отличный пример бедности мышления, обучения и письма, который часто прокатывает за мудрость в кругах тестировщиков. Это узкое, неверно направляющее людей определение, подразумевающее, что тестирование – это такая игра, в которую мы играем с ПО, а не открытое исследование сложного феномена.

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

В этой статье я прокомментирую одну часть статьи в Википедии. В следующей статье я опишу классы эквивалентности так, как вижу их я, и вы сами сможете решить, чье определение лучше – мое или Википедии.

"Классы эквивалентности – это техника тестирования ПО, которая делит вводимые данные на классы эквивалентных друг другу значений, на базе которых создаются тест-кейсы".

Не совсем. Нет никаких оснований полагать, что классы эквивалентности ограничиваются "вводимыми данными". Мыслительный процесс деления на классы эквивалентности может применяться к выходным данным, версиям продукта, тестовым окружениям, или кейсам как таковым. Классы эквивалентности применимы к чему угодно, где вариативность может повлиять на результат теста.

Да, это техника, но более подходящим словом будет "эвристика". Эвристика – это ненадежный метод решения проблемы. Классы эквивалентности крайне ненадежны, но меж тем полезны.

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

Этот текст достаточно неплох. Отметьте выражение "в принципе" и использование слова "пытается". Это смягчающие слова, и это важно, потому что классы эквивалентности – эвристика, а не алгоритм.

Говорить, меж тем, о "кейсах, которые необходимы для работы" – это уводить разговор в сторону от тестирования. Тестирование – это не создание тест-кейсов, и это точно не про количество тест-кейсов, которые вы создаете. Тестирование – это проведение экспериментов, а общее количество экспериментов выходит далеко за рамки вопросов вроде "какой тест-кейс мне написать далее?". Эта фраза должна звучать как "снижая тестовые усилия".

"Преимущество этого подхода – это сокращение времени, требуемого на тестирование ПО благодаря меньшему количеству тест-кейсов".

Извините, но нет. Преимущество классов эквивалентности вовсе не в снижении количества тест-кейсов. Это даже не о снижении тестовых усилий как таковых (хотя верно, что эта техника "пытается" снизить усилия по тестированию"). Классы эквивалентности – это просто способ систематически угадывать, где, возможно, скрываются самые крупные баги, и помогающая фокусировать ваши усилия. Классы эквивалентности – это техника приоритезации. Она помогает вам объяснять свой выбор и защищать его. Лучшая приоритезация сама по себе не снижает усилия по тестированию, но ее цель – наткнуться на крупные баги раньше, а не позже. И мы хотим наткнуться на них целенаправленно, а не случайно. И если мы хорошо сделали свою работу, то да, мы потратим меньше усилий на тестирование. Снижение тестовых усилий – побочный эффект техники классов эквивалентности.

"Классы эквивалентности обычно применяются к данным, вводимым в тестовый компонент, но могут применяться и к выходным данным в редких случаях. Как правило, они вытекают из требований или спецификации для ввода данных, влияющих на обработку тестового объекта".

Обычно? Как правило? Автор провел некое исследование, подтверждающее это? Нет.

Классы эквивалентности – это процесс, которым все мы неформально занимаемся, не только в тестировании, но и в повседневной жизни. Когда вы открываете дверь – вы сознательно решаете толкнуть именно этот квадратный сантиметр металлической доски? Нет, вовсе нет. Вы знаете, что для большинства дверей совершенно не важно, куда их толкают. Все места, которые можно толкнуть, эквивалентны. Это класс эквивалентности! Мы применяем классы эквивалентности ко всему, с чем мы взаимодействуем.

Да, мы применяем эту технику к выходным данным и да, мы можем рассматривать классы эквивалентности, основанные на спецификации, но мы также рассматриваем классы, основанные на том, что мы изучили о тестируемом ПО. Мы применяем классы эквивалентности, основываясь на всем, что мы знаем. Если то, что мы знаем, неверно (к примеру, если в ПО есть неожиданные баги), то наши классы эквивалентности тоже будут неверны. И это нормально, если вы понимаете, что это эвристика, а не золотой билет в страну идеального тестирования.

"Фундаментальная концепция классов эквивалентности исходит из отношения эквивалентности. Программная система – это, по сути, расчетная функция, внедренная как алгоритм на некоем языке программирования. Если заданы входные данные, некоторые инструкции этого алгоритма покрываются (см. "Покрытие кода"), а некоторые – нет…"

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

Фундаментальная концепция классов эквивалентности не имеет ничего общего с информатикой или расчетами. Она про логику. Логика существовала задолго до компьютеров. Класс эквивалентности – это, грубо говоря, набор. Это набор вещей, разделяющих определенное свойство. Интересное с точки зрения класса эквивалентности свойства – это полезность для исследования специфического риска продукта. Иными словами, тестирование классов эквивалентности – это убеждение, что каждый член определенной группы вещей будет с более или менее равной вероятностью находить определенный вид бага, если его применить в определенном виде теста.

Если я определю "тестовые условия" как нечто о продукте или его окружении, что может быть исследовано при тестировании, то я могу определить классы эквивалентности примерно так: Класс эквивалентности – это набор тестов или тестовых условий, которые эквивалентны по отношению к определенному продуктовому риску в определенном контексте.

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

Если вы читали техническую часть про информатику в статье Википедии, вы видели, что авторы решили, что два вида данных, покрывающих один и тот же код, эквивалентны для целей поиска багов. Это совсем, совсем не так! Это фантазия, которую продвигают люди, которые, как я подозреваю, в жизни ничего важного не тестировали. Сходу могу сказать, что покрытие кода как золотой стандарт игнорирует баги производительности, баги требований, баги удобства использования, баги данных, баги безопасности и баги интеграции. Представьте себе два теста, покрывающих один и тот же код и включающих отображаемые на экране данные. В одном тесте ввод настолько длинный, что при печати на экране он выходит за его границы. Это баг, который не будет найден при коротком вводе, хотя оба вида данных "валидны" и функционально "делают одно и то же".

Основная проблема с большинством советов по тестированию

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

Обсудить в форуме