2012-04-23: Правильное автоматическое тестирование

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

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

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

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

Для начала - два совершенно общих принципа.

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

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

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

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

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

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

[ Хронологический вид ]Комментарии