MaksTsepkov: Массовая правка: замена PCRE ^ на {{RightNote|Еще про архитектуру}}

2023-12-07T15:21:47Z

Массовая правка: замена PCRE ^ на {{RightNote|Еще про архитектуру}}

MaksTsepkov в 09:12, 23 апреля 2012

2012-04-23T09:12:34Z

Новая страница

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

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

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

Итак, после вступления - начинаю.

Для начала - '''два''' совершенно '''общих принципа'''.
# Следование методологии не может быть оправданием конкретных предпринимаемых действий.
# При реализации чего-либо правильно опираться на распространенные практики отрасли в этой области и соотносить свои действия с ними.

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

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

'''Мое представление о хороших автоматических тестах''', на соответствие которым я предполагаю смотреть при оценке. В виде некоторой цепочки положений, которые вытекают одно из другого. Они касаются не столько самих тестов и применяемых технических средств, сколько процесса создания тестов. При описании применяется термин '''тестировщики''', роль которых у нас играют аналитики и инженеры, в соответствии с принятым в отрасли.
# Business value автоматических тестов - сокращение усилий на выпуск продукта надлежащего качества. Следование этому принципу должно быть доказательным и признанным заказчиком.
# Люди, отвечающие за выпуск продукта - тестировщики (у нас - аналитики и инженеры) и представители заказчика - доверяют автоматическим тестам. Без этого business value не достижимо. Поэтому тестировщики играют роль непосредственных заказчиков для '''любых''' автоматических тестов, и именно они - оценивают их целесообразность.
# Доверие результатам автоматических тестов повышается, если тесты представлют собой белый ящик - последовательность выполняемых действий видна тестировщикам, и они могут в нее вмешиваться. В отрасли является нормой, когда автоматические тесты реализуются на некоторых скриптовых языках в терминах модели. Они понятны тестировщикам, которые часто их разрабатывают и почти всегда - могут доработать и изменить. Тесты на верхнем уровне джолжны быть компактны.
# В отрасли применяется подход Data-Driven тест, в котором в составе теста отделены входные и проверочные данные. Данные написаны компактным, легко понимаемым и модифицируемым образом. Это позволяет легко создавать множество прогонов одного теста на разных данных, тестируя сложные случаи, например, данные на границе допустимого диапазона или спецсимволы в строках. И это точно доступно тестировщикам и IT-службы представителям заказчика.
# Тесты выполняются в рамках фреймворка, который собирается на основе одного (или даже нескольких) из большого количества стандартных.
#* Фреймворк обеспечивает взаимодействие с программой на нескольких уровнях - UI, веб-сервисы, процедуры базы данных, интеграция через MQ, файлы или другим образом. При этом тест может предполагать взаимодействие разных видов. А конкретные процедуры интеграции и взаимодействия реализуются на основе стандартных библиотек.
#* Фреймворки также обеспечивают логирование, включая внутренний лог теста на уровне белого ящика, и отчеты разного уровня - для тестировщиков, разработчиков и менеджеров.
#* Фреймворк обеспечивает ведение тестов и данных для них, запуск тестов в ручном режиме или при сборке, подключаясь к серверу непрерывной интеграции. Хорошие фреймворки на основе BDD позволяют связывать тесты с тест-кейсами.
#* Предпочтительны фреймворки с открытым кодом, и их - тоже много. Для тестирования Web-приложений стандартом де-факто является Selenium, который также подключается к большинству фреймворков (взаимодействие с базой данных и интеграция - они вне Selenium). Рассказыввали также Auto IT X и Robot Framework, но приводились и большие списки, включая композитные конструкции. Есть способы тестировать продукты-черные ящики, включая приложения, запускающиеся под Citrix или закрытые flash-апплеты в броузере - ориентируясь на графические картики, и это можно применять вместе с другими методами. Выбирать надо с учетом специфики проекта - интерфейсы, интеграция и прочее.
#* Над фреймворком прорабатывается некоторая надстройка, ориентированная на конкретный проект. Обеспечивает интеграцию, ведение тестов как белого ящика. А иногда - и представление дополнительных отчетов или макроуправление тестами. Средства для всего этого - имеются (НР QTP не любят потому, что он сам - черный ящик).
# Тестов у проекта - много. И выполняются они - долго. Поэтому они требуют структуризации. И это - нормально.
#* Применяется выделение Build Acceptant Test (BAT). Они выполняются после каждого билда в первую очередь, и остальные запускаются только когда эти - не прошли. Прочие автоматические тесты могут выполняться реже, в том числе - только при регрессионном тестировании.
#* Применяется деление тестов по функциональным областям. Тогда запускаются сначала BAT-тесты, потом тестирование функционала тех областей, которые затронуты разработкой, и лишь потом, если предыдущие этапы завершены - все остальные. С учетом появления времени новых изменений кода.
#* Применяется приоритезация тестов по критичности функционала и рискам, связанным с его утратой. С соответствующей настройкой исполнения тестов.
#* Тестирование через конечный UI тяжело сопровождается и часто медленнее. Поэтому его применяют ограниченно, например, для одного документа, проверяя остальные варианты на уровне прямого взаимодействия через данные. И пренебрегая связанными с этим рисками, полагаясь на дешевое устранение чисто UI-ошибок.
# Тесты требуют внимания и дизайна.
#* Если пренебрегать тестами и их дизайном - они превращаются в дорогой, слабополезный и несопровождаемый код, становятся обузой.
#* Разумное применение тестов, наоборот, приносит измеримый эффект в виде экономии усилий на разработку проекта в целом и удовлетворенности заказчика качеством.
#* Организация процесса может быть различной, но в любом случае он встраивается в процесс разработки как одна из составляющих и предполагает совместную деятельность и взаимодействие разработчиков, тестировщиков и аналитиков. Границы ответственности между ними также могут быть разными, при том что за конечное business value автоматических тестов отвечают тестировщики - автоматическое тестирование является частью тестирования в целом.
#* Unit-тесты применяются многими как составляющая часть автоматических тестов (часть людей используют это как синонимы, но многие - разделяют). Формальная граница проводится по-разному, но по-любому они встроены в общий процесс как составляющая, организуются и оцениваются соответственно.

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

[[Категория:Архитектура]]

{{wl-publish: 2012-04-23 13:12:34 +0400 | MaksTsepkov }}

← Предыдущая		Версия 15:21, 7 декабря 2023
Строка 1:		Строка 1:
		+	{{RightNote\|[[:Категория:Архитектура\|Еще про архитектуру]]}}
	В этом посте речь пойдет о критериях, которым должна, с моей точки зрения, удовлетворять организация любых автоматических тестов. Картинка сложилась на SQA days под влиянием выступлений и соотнесения их с положением с тестами в компании. Поэтому приводимый дальше список критериев и положений может быть несколько перекошен в отрицательную сторону, то есть на те составляющие, которых у нас нет. Но это - дело поправимое.		В этом посте речь пойдет о критериях, которым должна, с моей точки зрения, удовлетворять организация любых автоматических тестов. Картинка сложилась на SQA days под влиянием выступлений и соотнесения их с положением с тестами в компании. Поэтому приводимый дальше список критериев и положений может быть несколько перекошен в отрицательную сторону, то есть на те составляющие, которых у нас нет. Но это - дело поправимое.

Блог:Максима Цепкова/2012-04-23: Правильное автоматическое тестирование - История изменений

MaksTsepkov: Массовая правка: замена PCRE ^ на {{RightNote|Еще про архитектуру}}

MaksTsepkov в 09:12, 23 апреля 2012