Home

Автор: Рич Роджерс (Rich Rogers)

Оригинал статьи: https://richrtesting.wordpress.com/2016/02/16/functional-or-non-functional-does-it-really-work/

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

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

Суть проблемы

Проблем, достойных рассмотрения, тут три:

Первая проблема: плохие определения, неподходящие термины

Участники процесса разработки ПО могут легко стать жертвами плохой коммуникации и понять коллег неверно, и зачастую виной тому используемые слова. Когда речь идет о новых идеях и технологиях, некоторая первоначальная путаница вполне естественна, однако не стоит использовать двусмысленную терминологию там, где этого можно избежать. Я полагаю, что "нефункциональное" и "функциональное" тестирование - это именно такая терминология. Далее по тексту я проясню свою позицию.

Вторая проблема: жесткое разделение тестирования на две части согласно этим терминам

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

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

Более того, выносить некоторые виды тестирования в нефункциональное бессмысленно. Наверное, не только я изумляюсь, каким образом туда попало юзабилити.

Третья проблема: типирование людей на основании этих двух категорий

Меня все больше раздражают термины "функциональный тестировщик" и "нефункциональный тестировщик". Кто-то действительно с гордостью несет по жизни звание "нефункционального"?

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

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

"Нефункциональное тестирование" не работает

Давайте рассмотрим термин "нефункциональное тестирование" подробнее. О нем много спорили, и не раз его высмеивали. Чтобы составить фразу, демонстрирующую абсурдность понятия, не нужно быть Эйнштейном. Вот, к примеру, цитаты из статьи Agile Alliance:

• "Нефункциональный тест функционирует".
• "Последний нефункциональный тест пройден".
• "Я не уверен, что этот нефункциональный тест сработает".

Добавлю пример от себя:

• "Операционные приемочные тесты не функциональны".

Я слышал много шуточек по поводу этого термина, однако люди продолжают использовать его. Хорошо знакомое понятие - вовсе не причина продолжать им пользоваться. Нас никто не заставляет продолжать использовать глупую фразу только потому, что она прижилась в отрасли и всем ясна. Меж тем ее все еще навязывают наивным тестировщикам - например, заглянем в глоссарий ISTQB и материалы к нему.

«Нефункциональное тестирование: тестирование атрибутов компонента или системы, не относящихся к функциональности. Пример: надежность, эффективность, юзабилити, поддерживаемость, переносимость».

Альтернативная точка зрения: парафункциональное тестирование

Несколько лет назад Кем Кейнер предложил альтернативный вариант терминологии: парафункциональное тестирование.

Это не новость для многих из нас. Первое упоминание о парафункциональном тестировании, которое мне удалось найти, относится к 2004 году. Это понятие легко рассматривать исключительно как разумную замену нефункциональному тестированию - оба термина определяют тестирование, не относящееся к функциональному.

Тем не менее, если принять во внимание определение функционального тестирования, мне кажется, что между "нефункциональным" и "парафункциональным" есть существенная разница.

Определение функционального тестирования ISTQB опирается на аналогичную терминологию Кросби, и ставит во главу угла соответствие спецификации:

"Функциональное тестирование: тестирование, основанное на анализе спецификации к функциональности компонента или системы."

Описания функционального и парафункционального тестирования в работе Кема Кейнера "Продолжение революции" (2004) базируются на другом подходе: они напрямую увязывают типы тестирования с пользователями и различаются аспектами продукта, понятными и непонятными им.

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

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

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

Можно ли на этом остановиться?

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

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

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

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

А как насчет функциональных тестов?

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

Что мы потеряем, если просто назовем это "тестированием", не деля его на подвиды? При необходимости, чтобы подчеркнуть специфические цели тестирования, можно использовать более точные термины - например, тестирование производительности или доступности.

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

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

Заключение

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

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

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

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