Вы — руководитель проекта, который хочет понять, на каком языке общаться со своей армией QA специалистов? Планируете выбрать стратегию контроля и повышения качества на проекте, но не знаете, какие тесты будут нужны?
Или вы — начинающий тестировщик, который хочет «почитать чего-нибудь», чтобы подготовиться к интервью? Вас обязательно спросят «какие виды тестирования вы знаете». Вы, наверное, как большинство самих собеседующих, думаете, что надо перечислить какой-то линейный список…
А может вы из тех, кто думает, что ad hock и smoke тестирование — это примерно одно и то же, а тестирование UI не может быть автоматизированным.
Если да — статья для вас. Если нет — пожалуйста, посмотрите на схемку, там все правильно? Жду комментариев и поправок!
++ Эта статья может оказаться удобной шпаргалкой для дизайнеров тестов. А может и нет. Советы по дополнению тоже приветствуются в комментариях.
NB: в статье нет и не должно быть описаний всех перечисляемых видов тестирования. Объясняются только спортные термины, все остальное можно найти в сети. Целью статьи является систематизация, обобщение знаний о видах тестирования, а также выставление логических связей между ними.
Группировка видов тестирования
Вы уже задавали в интернете поиск «виды тестирования» и видели кучу интересных названий и описаний, даже что-то запомнили. Почти все статьи, посвященные видам тестирования имеют группировку тестов по категориям. Подход к группировке у всех разный. Мне нравится тот, что использовался в статье про тестирование ПО на Википедии, поскольку я считаю его наиболее полным — в нем есть место, куда вкрутить любой вид теста.
Но мне не нравится линейность таких группировок. К тому же не очевидно, что принадлежность конкретного экземпляра теста к одному из видов, например, к тестированию юзабилити, не означает, что тот же тест не является функциональным и sanity. На этом заявлении со мной очень многие не согласятся, и я призываю вас читать дальше.
Взяв за основу группировку из Википедии, я нарисовала карту знаний, чтобы расставить все виды тестов по полочкам и визуально ощутить их многообразие. Мне эта карта бывает полезна в процессе планирования тестов — я проверяю, не забыла ли я чего. Делюсь схемкой с вами:
Посмотреть в полном размере.
Скачать исходник в формате xmind можно тут.
Названия тестов приведены на английском, чтобы избежать неточности перевода.
Правда и вымысел о функциональных тестах.
На собеседованиях спрашивают:
— Какие виды тестирования кроме функционального вы знаете?
Вы отвечаете:
— Нагрузочное, тестирование безопасности, автоматизированное…
А я отвечаю:
— Не функциональное.
Функциональные тесты — это класс тестов, а не конкретный вид.
Суть в том, что тестирование сводится к проверке разрабатываемого ПО на то, делает ли софт то, что задумывалось и с таким успехом, как хотелось бы клиенту. То есть,
мы тестируем на соответствие требованиям и здравому смыслу.
Не зависимо от того, если ли у вас бумажка, называемая ТЗ или SRS, требования, на основе которых вы проводите проверку, всегда есть. Например, «сделайте калькулятор, у которого будут кнопочки, и который будет выполнять все математические операции.» Мы можем уточнить, конечно, какие именно нужны операции или понять и сделать согласно своему видению, но так или иначе минимальные требование у нас уже есть.
Нет требований — нет разработки. Справедливо и обратное — есть разработка -> есть требования.
Можно считать, что требований нет, если разработчики не поняли, что от них ждут, и не смогли приступить к работе. Я знаю хороших разработчиков, которые не приступают к разработке, пока не получат ответ на вопрос: «а для чего этот софт должен делать то-то и то-то? Какая конечная цель использования?» Если же разработчики работают — значит требования есть. Если нам есть что разрабатывать, значит есть что тестировать. Наличие формально описанных требований — вещь очень важная, но не является обязательной.
Все требования делятся на функциональные и не функциональные. А значит и тесты тоже.
Что проверяют suitability тесты?
Функциональные тесты, которые в моей схеме называются «suitability» — это самые важные тесты, не прохождение которых равносильно заявлению «вы ничего не сделали». Это — тесты на функциональную пригодность. Они включают в себя проверку следующих утверждений:
- приложение делает то, что должно делать
- приложение не делает то, что не должно делать
Первый тезис покрывают позитивные тесты, второй — негативные. Но позитивные и негативные тесты не являются подкатегорией функциональных тестов, так как это деление может касаться и не функциональных тестов.
Почему важно проверять второй тезис? Пример: при вводе пинкода банкомат не должен его показывать на экране, а еще он не должен передавать его в незашифрованном виде. Это — critical issue.
Если эти тесты провалены — софт не готов. То есть мы получаем инверсию этих тезисов:
- приложение не делает то, что должно делать
- приложение делает то, что не должно делать
Под эти 4 тезиса можно подписать почти все результаты ваших функциональных suitability тестов. первая группа будет с пометкой PASS, вторая — FAIL. Почему не все? Потому что может быть обнаружено в результате тестирование следующее:
- приложение делает то, что должно делать, но не надо бы
- приложение не делает то, что не должно делать, а надо бы
Такие результаты никогда не будут critical, так как «всё по ТЗ». Они могут быть выявлены в результате usability и UX тестирования, при тетсировании спецификации или при проверке покрытия кода регрессионными тестами, когда обнаружится рудиментарный работающий функционал, который уже давно не используется на практике. Кроме того, результаты послежней категории могут быть выявлены в результате тестирования здравого смысла.
И вот эту группу дефектов очень часто закрывают, с чем я не могу до конца согласиться, потому что
такие дефекты тоже влияют на качество ПО
Почему sanity тесты относятся к функциональным?
Требование, которые редко дают в явной форме, но которые распространяются на любой софт — это
Любой функционал должен соответствовать здравому смыслу
Проверка на здравый смысл — узкое место многих проектов, так как упускается из-за своей всеочевидности и всеумолчательности, а также из-за стремления выполнять поставленную задачу, а не достигнуть конечной цели, о чем я уже писала в первой части. Я посвящу здравому смыслу отдельную статью.
Есть еще такая важная вещь — защита от дурака. Проверки на такую защиту будут относится к тетсированию здравого смысла, если они явно не прописаны в требованиях. Если описаны — это suitability. В любом случае — функциональные. Что не мешает им на самом деле быть UX тестами.
Нужны ли нам compliance тесты?
Любой софт, в зависимости от своего вида, попадает под те или иные существующие стандарты. Заказчик может не знать об этих стандартах и не упомянуть в требованиях о них. Но это не значит, что можно махнуть на стандарты рукой. К примеру, если вы делаете веб-приложение, вполне логично проверить его на соответствие стандартам W3C.
Вернемся к примеру с калькулятором. Требования умещались в одну строчку и не было указано ни каких стандартов. Однако при тестировании мы будем иметь в виду стереотипную концепцию калькулятора, что тоже по сути стандарт — «так устроено большинство калькуляторов». Нас же не просили «проявить креатив» и сделать что-то нестандартное?
Кроме того, нам сказали про математические операции. Считать их стандартом или здравым смыслом — не могу определиться. Но при тестировании вы будете их использовать — в этом я не сомневаюсь.
Функциональный или не функциональный тест?
К не функциональным требованиям относятся, кроме всего прочего, требования к отказоустойчивости. Например: «при сбое компонента его функции должны выполняться другим, параллельным компонентом». Соответственно, покрываться они будут не функциональными тестами — стресс тестами, тестами надежности и стабильности.
А теперь рассмотрим случай, когда отказоустойчивость является функциональным требованием. Например, разрабатывается и тестируется отказоустойчивый кластер, а не система, в которой он используется. Целью разработки является создание продукта, который будет обеспечивать отказоустойчивость. Тогда тестирование будет функциональным.
Другой пример — Jmeter. Популярный инструмент для проведения нагрузочного тестирования. Его функционалом является нагрузочное тестирование. Это — случай, когда субъект тестирования стал объектом тестирования. Рекурсивненько, да? Тесты нагрузочного тестирования JMeter являются функциональными.
Вот из-за таких запутанных случаев не уместно разделять функциональные тесты по видам функционала (только по видам требований). И не уместно относить сами функциональные тесты к объектам при категоризации «по объекту тестирования».
Объекты тестирования
Самый плодородный подход к классификации тестов — это категоризация по объектам тестирования. Велико разнообразие технологий, интерфейсов, архитектур, функциональных предназначений и характеристик системы. Все требует своего подхода к тестированию. Отличаются методы и инструменты.
Приложу эту группу отдельно:
Справа я написала две группировки, они условны, поэтому не являются родительскими узлами. Потому что эти требования могут быть и функциональными, и не функциональными, в зависимости от того, что разрабатываем. В общем случае инфраструктурные мы будем проводить до и для передачи в production. А эксплуатационные мы будем проводить на prod-like среде, когда уже будет определено, на каком железе будет жить наша система.
Полное тестирование безопасности, например для сертификации в ФСБ, могут быть частью инфраструктурных тестов, если используются аппаратные способы защиты или внешние системные модули, которые мы не разрабатываем сами. А некоторые средства защиты будут «вшиты» в наш софт и тестироваться как часть функциональных требований. Например, в рамках тестирования функции передачи сообщения о транзакции от банкомата к банку-эмитенту, мы проверим шифрование пин-кода.
Тестирование интерфейса пользователя
UI testing — это и группа тестов, и конкретный ее представитель. Я предлагаю понимать так, все что нельзя выделить как usability или UX тесты — предлагаю называть в общем, UI тестами.
Интерфейс пользователя может быть не только графическим, вы же знаете. Если бы речь шла только о графическом, то назывался бы вид GUI testing. CUI можно и нужно проверять. Если в требованиях написано, что консоль должна выводить сообщения об успехе зеленым, а об ошибках — красным, то проверка этого будет тестированием UI. Тесты того, насколько понятна и полезна пользователю выводимая в консоли информация — это уже UX и функциональные suitability тесты (если требования к выводимым данным отвечают назначению приложения).
GUI можно протестировать на соответствие макету. Сам макет можно проверить на соответствие принятому стандарту, общему для всех форм данного ПО. Можно проверить действие горячих клавиш.
Железо можно проверить на соответствие форм-фактору. Да, у любого железа есть интерфейс. То, чем оно касается другого железа или то, до чего дотрагивается пользователь — это интерфейс.
Всё это не имеет ни какого отношения к тому, как пользователь взаимодействует с интерфейсом.
Сам по себе факт наличия и внешнего вида кнопочки — вещь важная, но недостаточная. Под как в вышесказанном имеется в виду следующее:
- доступен ли элемент интерфейса для манипуляции?
- на сколько сложно разобраться в интерфейсе?
- имеет ли смысл наличие данного элемента в контексте решения задач, стоящих перед пользователем?
- удобна ли последовательность манипуляций пользователю?
На эти вопросы отвечают usability и UX тесты. Признаться, я с трудом прощупываю грань между ними. Мне очень понравилась одна презентация на эту тему. В ней описывается разница между самими понятиями usability и UX через перечисление распространенных заблуждений. Эти же заблуждения могут быть основой для составления UX тестов и обоснования заведенных по ним дефектов.
Всё можно проверить на защиту от дурака. И интерфейсы — это то самое место, в которых эта защита применяется. Такие тесты будут тестами здравого смысла, а иногда и тестами безопасности.
Повторим пройденное:
- Есть кнопка или нет — это UI тест.
- Нажимается кнопка или нет — это usability тест.
- Эффективно ли нажатие кнопки для решения задачи пользователя — это UX тест.
- Что будет, если кнопку нажать несколько раз:
- — это функциональный тест, если от количества нажатий зависит определенное действие.
- — это стресс тест, если может вызвать сбой.
- — это тест на защиту от дурака, если только дурак может додуматься столько тыкать. Шучу. Это — тест на здравый смысл — если нет смысла нажимать несколько раз, и это может исказить результат — возможность должна быть заблокирована.
Test-to-pass и Test-to-fail
Об этом я вычитала в книге Software Testing By Ron Patton. Вот цитата:
There are two fundamental approaches to testing software: test-to-pass and test-to-fail. When you test-to-pass, you really assure only that the software minimally works. You don’t push its capabilities. You don’t see what you can do to break it. You treat it with kid gloves, applying the simplest and most straightforward test cases.
Паттон пишет, что тесты, которые должны пройти успешно (Test-to-pass), должны проверяться в первую очередь. Если они не прошли, то остальные можно не проверять.
Меня не удивляет то, что это разбиение тестов почти нигде больше не упоминается. Причина этому — что эта характеристика почти эквивалента разделению тестовых сценариев на позитивные и негативные. По сути, так оно и есть, кроме одного момента:
Позитивные и негативные бывают тест кейсы. Метками «test-to-pass» и «test-to-fail» можно сгруппировать тестовые наборы для smoke, acceptance и regression тестов, которые могут содержать в себе как негативные, так и позитивные сценарии.
Tets-to-pass — это тесты в нормальном, наиболее часто используемом режим эксплуатации.
Test-to-fail — это тесты на неизведанной территории, которая может оказаться минными полем. Эти тесты вы не будете проводить после каждой сборки. Они нужны только для поиска особых состояний системы, в которых возможно возникновение ранее не обнаруженного дефекта или вообще сбой всей системы. Такие тесты могут быть ad hock, а негативные тесты — это могут быть случаи, которые проверяются при принятии баг фикса, и они должны пройти успешно.
Цель негативного теста — убедиться, что система правильно реагирует на неправильное действие. Цель test-to-fail наверняка сломать систему.
Про ветку «Сценарии» в карте знаний
Обратите внимание, что
Часть характеристик тестов по виду относятся к набору тестов (например, регрессионные), а часть — к конкретному тест кейсу (например, позитивный тест).
На вышеприведенной карте знаний характеристики тест кейсов выделены желтым, характеристики тестовых наборов выделены голубым, а универсальные — зеленым. Очевидно, что характеристик наборов тестов больше, чем характеристик сценариев.
Поэтому может показаться, что разделение тестов по видам сценариев — не так уж важно. На деле конкретных тест кейсов в разы больше, чем наборов, и упустив какой-то вид, вы теряете кучу проверок!
Виды тестов, которые перечислены в узле «Сценарии» — это на самом деле названия методик подготовки сценариев, которые приняты считать видами тестов Черного ящика. Соблюдение этих методик дает на выходе конкретные тесты. Поэтому уместно приводить их как категории тестов.
Почему эти тесты не относятся к Black Box? Потому что даже тестируя спецификацию надо думать о том, что будет, если ввести значение больше допустимого, и как должна система реагировать на ошибки вообще. Об этом надо думать и при написании unit-тестов, которые к Black Box никак не относятся.
Обратите внимание, что тесты нижнего уровня в ветке «Сценарии» могут быть совместимы с тестами из соседней, такой же желтой, подветки.
— Я не стану детально расписывать тонкости и отличия между остальными видами тестов. Про все это много информации в сети. К тому же, это не является основной целью статьи. Про UI и функциональное тестирование я много распиналась, потому что это — больная и очень спорная тема. Возможно, стоить вынести эти абзацы в отдельные статьи. Я подумаю над этим.
Характеристика теста
Как говорилось выше, каждый фактический тест одновременно может является тестом разных видов, в зависимости от того, в каком разрезе на него посмотреть. Принадлежность теста к некоторым видам из одной категории исключает принадлежность к некоторым видам другой категории.
На мой взгляд, очень важно это понимать, планируя стратегию тестирования и общаясь с коллегами. Навешивая неправильные ярлыки на тесты можно придти к расхождению в понимании задач, упустить важные проверки, и, в итоге упустить конечную цель.
Поэтому я предлагаю следующее. Если у вас много тестов, вы запутались в них, не понимаете, какие еще нужны, каких не хватает, какие надо расширять, какие актуализировать
заведите на тесты персональные карточки, типа досье.
Каждый тестовый набор будет обладать почти всеми следующими характеристиками:
- Вид требований
- Объект тестирования
- Знание системы
- Степень автоматизации
- Степень подготовленности тестов
- Глубина тестирования
- Сценарии.
Эти характеристики касаются самих кейсов. Можно отметить, какие тест кейсы входят в набор, отметив галочками все использованные виды. - Время проведения тестирования
- Степень изолированности компонентов
- Динамичность
Также могут понадобятся иные данные — название, дата создания и прочее. В нашем контексте это не важно.
Сам же тест может представлять собой ссылку на документ, на папку с документами, ссылка на объект в трекере. Либо карточка теста может быть в самом документе или даже типом тикета, привызяваемом к тестам как родительский элемент. Можно также кастомизировать имеющуюся TMS под такую категоризацию. Организация системы управления тестами — это отдельная тема.
Есть одно исключение: exploratory / ad hoc testing. Для этого вида тестирования нет файлов, содержащих описание теста. Если есть хотя бы чек-лист или цитата из требований — это уже не ad hock. Если есть необходимость в таких тестах — карточку все равно надо заводить, даже если тело теста пустое.
Что это дает?
Дав характеристику имеющимся тестам, вы увидите, какие тесты у вас есть, а каких нет. Можете взять приведенную в начале карту знаний и закрасить те блоки, тесты по которым у вас есть. Вы увидите, что попробовали не все. Что-то из оставшегося будет не применимо к вашему проекту, а что-то — упущено из виду.
Вы поймете, что не имея сценариев, вы не можете оценить, какие тесты вы провели — делали ли негативные проверки? Проверяли ли вы на соответствие стандартам, удобство использования, искали ли уязвимости и так далее.
Тестирование покрытие кода VS оценка покрытия тестами
Вы должны понимать и всегда иметь в виду, что покрытие кода тестами и вообще тестовое покрытие — это не совсем одно и то же. Если на вашем проекте внедрена практика тестирования покрытия кода, то это не значит, что на вашем проекте есть все необходимые виды тестов. Пробегитесь по списку «по объектам» и вам бросятся в глаза объекты, которые тестами покрытия кода не покрываются.
Программа — это больше, чем просто написанный и собранный код.
Составление матрицы тестов
Матрица видов тестирования как комбинация возможных сочетаний характеристик тестов была бы полезна для составления полной картины того, какие тестовые наборы нужны, а в каких нет смысла.
Для составлении матрицы необходимо взять две шкалы, отметить значения на каждой из них и проставить связи между ними.
Проблема номер 1: у нас 10 измерений.
Проблема номер 2: Все 10 характеристик применимы одновременно, а значит полный набор комбинаций будет декартовым произведением всех подкатегорий, заканчивая низшим уровнем.
Проблема номер 3: Если бы тесты по видам требований можно было однозначно проецировать на множество объектов тестирования, то количество сочетаний существенно сократилось бы, а сама матрица стала бы простой и очевидной.
Можно говорить о матрицах тестов трех видов:
- Универсальная, применимая ко всем проектам. Содержит максимальный набор сочетаний, но сложная для составления.
- Стандартная для вида разрабатываемого ПО. Например, можно расписать матрицу тестов для абстрактного интернет-магазина.
- Конкретная матрица тестов для отдельно взятого проекта.
Можно взять карту знаний и вычеркнуть те тесты, которые не имеют смысла для вашего проекта. Например, убрать все виды тестирования UI для теста системы, в которой все сервисы запускаются планировщиком задач, а GUI ну просто нет, убрать тестирование информационной безопасности для тестирования приложения, доступ к которому есть только в подсети при доменной аутентификации, а работа с финансами и персональными данными отсутствует. Убрать интеграционные тесты Stand Alone приложения. Таких проектов на самом деле очень мало, и к большинству разрабатываемых систем применимы практически все виды тестов!
Категоризация тестов по компонентам конкретной ИС
Если генерировать матрицу для конкретного проекта, возникает соблазн добавить разделение тестов по компонентам системы.
Ошибочно будет представлять это разбиение как дочерние категории функциональных тестов.
Во-первых, дочерние категории там уже есть, и они применимы к каждому отдельно взятому функционалу.
Во-вторых, некоторые компоненты реализуют не функциональные требования.
Также ошибочно будет отнести компоненты к объектам тестирования, так как имеющиеся подкатегории не накладываются на перечень компонентов.
Кажется логичным также перечислить компоненты в категории component / unit testing. Не тут-то было. Unit тестами называются тесты изолированных блоков системы. При этом нет ограничения на то, на каком уровне абстракции вводить изоляцию. Unit тесты, которые пишут для себя разработчики — могут относится к отдельно взятому классу или методу класса. А все классы — составлять лишь часть функционального блока, например, генератор отчётов. С точки зрения руководителя проекта, сам генератор отчетов — является отдельно взятым компонентом системы, и он в праве называть тесты этого компонента — юнит тестами. Почему бы нет?
Я считаю, что компоненты или функциональные блоки конкретной ИС — это 11 измерение тестов.
При этом каждый блок будет иметь лимитированный своим предназначением (требованиями) набор тестов.
Целесообразно не расписывать 1 матрицу тестов для всей разрабатываемой ИС, а расписать свою матрицу для каждого функционального блока + одну общую, куда войдут применимые виды интеграционных и End-To-End тестов.
Несовместимые тесты
Из здравого смысла следует следующее:
- Автоматизированные тесты не могут быть ad hock. Исключение: если вы используете для автотестов ИИ.
- Тестирование покрытия кода не может быть полностью ручным. Исключение: кода так мало, что можно глазами увидеть и ручками записать, в какой участок кода мы попали при прохождении сценария, а в какой — нет.
- Бета-тесты почти никогда не бывают тестами белого ящика. Даже если взять Open Source проект, то бета-тестеры, имея исходный код, могут в него не заглядывать, и просто попытаться использовать софт для решения своих задач. Если пользователь посмотрел в код, то, по моему мнению, даже ничего не поменяв в нем он стал частью команды разработки, и занимается уже не бета-тестирвоанием, а скорее code review.
- Приёмочное тестирование всегда динамическое.
- Code review — это вид статического тестирования, который возможен только для белого ящика.
- Compliance тестирование не может быть ad hock.
По этому списку надо пробежаться при составлении матрицы ваших тестов. Возможно, вы увидите еще какие-то невозможные сочетания.
Выводы
Какие лично я для себя сделала выводы из приведенного мною анализа тестов:
- Каждый тест можно определить большим числом характеристиками.
- Часть характеристик тестов по виду относятся к набору тестов (например, регрессионные), а часть — к конкретному тест кейсу (например, позитивный тест).
- Часто вид проведенного тестирования зависит от получаемого результата, то есть характера выявленного дефекта.
- Понимание видов тестирования позволяет сделать более полноценный тест план и придумать более эффективные тест кейсы.
- Набор тестов зависит от индивидуальных особенностей проекта.
- В каждой проектной команде важно договориться, что вы называете тестами юзабилити, что — приемочными тестами, что — юнит тестами, что смоуком. Ввести свою конвенцию наименований, в которой под каждым односложным названием будет подразумеваться набор тестов, попадающих сразу под несколько характеристик.
Предлагаемую мною систематизацию тестов можно использовать в следующих целях:
- Способ организации хранения тестов в вашей Test Management System или при ее полном отсутвии
- Мониторинг тестового покрытия системы (не кода)
- Можно создать полу-автоматизированный генератор планов тестирования, если еще немножко подумать над всем этим
- Для обучения и проверки сотрудников
Я надеюсь, что статья была для вас полезна, и теперь у вас есть пища для размышления над вопросом:
А все ли мы сделали, чтобы выявить дефекты?
и что теперь вы сможете сами для себя ответить на вопрос, какие именно тесты вам нужны.
Кроме того, я надеюсь, что вы поняли о чем я, и вы ощутили, на сколько сложнее и интереснее задача определения видов тестирования на самом деле по сравнению с тем, как она обычно подается в статьях о видах тестирования.
ссылка на оригинал статьи http://habrahabr.ru/post/257159/
Добавить комментарий