9 сентября 1945 года был зарегистрирован первый в истории баг. B этот день ученые Гарвардского университета, тестировавшие вычислительную машину Mark II Aiken Relay Calculator, нашли мотылька, застрявшего между контактами электромеханического реле. Извлеченное насекомое было вклеено в технический дневник, с сопроводительной надписью: «First actual case of bug being found». С тех пор тестирование программного обеспечения прошло большой путь, и, как всякое новое практическое направление, развивалось динамично, не избежало тупиковых веток, неудачных попыток адаптации и переноса методологий, стандартов и концепций из уже существующих областей. Дополнительной особенностью этого процесса стала зависимость тестирования от собственно программного обеспечения, чьи технологии, методы, инструменты сами переживают период стремительного и интенсивного совершенствования. Опять же, характерная деталь: не имея за спиной богатого опыта теоретических исследований, система обеспечения качества ПО и вслед за ним — тестирование — обрастали всевозможными мифами и попадали под влияние различных идейных течений.
С одной стороны опыт работы с различными проектами и заказчиками позволяет признать справедливость лозунга «Каждому проекту — свою методологию обеспечения качества. Нет идеальных общих решений». Неполные исходные данные, ограниченные ресурсы, «не-начальная» стадия разработки, сжатые сроки — это далеко не полный список особенностей проекта, который несмотря ни на что надо сделать и который при этом никак не вписывается в идеальные рамки «классических» концепций и подходов. С другой же стороны накопленный именно практический опыт выполнения реальных проектов позволяет выделить некоторые основные принципы успешной организации обеспечения качества, важной частью которой является тестирование.
Принцип первый: отказываемся от амбиций. Для успешного тестирования очень важно грамотно и гармонично сочетаться с разработкой. В общем смысле процесс обеспечения качества несомненно является сквозным: он проходит через весь процесс разработки и тестирования. Тестировщики особенно любят отмечать, что в плане обеспечения качества разработка и тестирование равноправны и даже где-то неразделимы. В идеале, это так. Но на практике в связи с многочисленными индивидуальными особенностями проекта и команды крайне важно помнить о зависимости процесса тестирования от разработки. Очень часто успешность, а значит качество создаваемого программного продукта, зависит именно от умения адаптировать тестирование к сложным ситуациям разработки, умения идти на компромиссы, а не держаться за «идеально разработанный план тестирования» в условиях изменившихся требований, сжатых сроков и т.д.
Принцип второй: выбираем момент. В то же время компромиссы и корректировку процесса тестирования по ходу развития проекта можно и нужно стараться минимизировать. Самый действенный способ сделать это — начать тестировать как можно раньше. Если проект разрабатывается «с нуля», то тестирование начинается с анализа требований. Если команда приступает к проекту не на начальной стадии, то тестировщики стартуют вместе с разработчиками изучающими спецификацию и (или) любые другие доступные документы. Тестировать имеющиеся требования необходимо для упреждения тех ошибок, которые легко можно устранить на ранних этапах и которые могут породить множество проблем на последующих стадиях разработки и поставки. При анализе документации смотрим на следующее: корректность требований, непротиворечивость, упорядоченность по приоритетам, проверяемость (тестопригодность), модифицируемость, прозрачность. Характерно, что сложночитаемые участки текста, как правило, отражают неудачи в проектировке проекта. Кроме того, одним из первых действий в работе над проектом следует признать составление глоссария. Лучше всего, если он будет создан именно тестировщиками и утверждён заказчиком. Это позволит избежать многих ситуаций взаимонепонимания в дальнейшем, а значит убережет от потери лишнего времени и денег.
Принцип третий: выбираем свой комплекс мер. Выбирая методологию и планируя процесс управления качеством надо руководствоваться практической целесообразностью именно для конкретного проекта. Цель — качественный программный продукт, а используемые при этом стандарты, методики и методологии тестирования — всего лишь средства, необходимые для достижения этой цели. Например, похвальное желание документировать каждый тест-кейс в подробнейших деталях может существенно затянуть процесс создания тестовой документации, потребует много усилий и — в итоге — может оказаться излишним для опытной команды тестировщиков. Предусмотрительность и стремление к полноте тестирования требует проверки всех комбинаций всех компонентов. А ведь при этом существуют неважные взаимодействия, но мы все равно создаем массивные наборы тестов или увлекаемся неинформативными метриками. В качестве же наиболее востребованных на практике мер можно привести: создание плана тестирования, заготовка блока тестовых примеров/данных, выбор наиболее стандартных конфигураций, отдельный отбор проверок для регрессионного тестирования (стараемся избегать пересечения списка с приёмочными проверками), обучение новых сотрудников в процессе совместного тестирования с более опытным тестировщиком, а не путём чтения документации и список тестов в первые дни.
Принцип четвёртый: организуем команду. Времена, когда разработчики тестировали результаты работы друг друга, а иногда и свои собственные, постепенно проходят. Опыт такого тестирования несомненно также является полезным и может дать интересные результаты, но время на эту работу забирается у разработки, что при интенсивном развитии проекта может оказаться существенным недостатком. А кроме того подобная деятельность сложно поддаётся регулированию («Сегодня есть время — тестируем друг друга, а потом две недели времени на тесты нет — все активно пишем») и часто является причиной нездоровой психологической обстановки в коллективе. Поэтому тестированием должны заниматься специально подготовленные, независимые люди. Более того, если одновременно ведётся несколько проектов, то лучше, например, из трёх тестировщиков организовать отдельную команду, чем «закрепить» за каждым проектом/командой разработки одного тестировщика. Тестируя различные системы, тестировщик получает бесценный опыт, есть возможность посмотреть на проект свежим взглядом. Немаловажно и то, что психологически тестировщик чувствует себя лучше находясь в своей команде, а не в подчинённом положении в команде разработки.
Принцип пятый: используем специальные инструменты. Тестирование — это уже давно не хаотичное нажимание кнопок в надежде на сбой в программе с последующим радостным уведомлением о нём программиста по почте или ICQ. Для проектов любого уровня сложности можно и нужно подобрать соответствующие ресурсы, обслуживающие процесс тестирования. Обязательно понадобится: система отслеживания проблем (BTS — Bug Tracking System), тестовая лаборатория (компьютеры различной мощности, программы позволяющие производить конфигурационное тестирование), централизованный репозиторий для хранения тестовой документации. А также после оценки трудозатрат на автоматизацию (сравниваем с ручным тестированием!) могут понадобиться программы автоматизации тестирования.
Принцип шестой: оптимизируем отчётность. Процесс тестирования, как и любой другой процесс, обязательно должен иметь документированный результат. Однако, очень часто возможности предоставляемые современными средствами тестирования, проектирования, настройки генерации отчётности и графиков начинают заслонять истинный смысл создания этих самых тестовых отчётов; не говоря уже о том, что любая бюрократия обязательно требует временных затрат от всех участников. Наиболее часто запрашиваемыми отчётами для заказчика являются: процент прогнанных на данный момент тест-кейсов с результатами (помодульный список проблем, отсортированный по приоритетам с актуальным статусом) и результаты приёмочного тестирования. Многочисленные сложные таблицы с подробными описаниями и ссылками как правило настолько неудобочитаемы и непоказательны в плане отражения состояния дел, что вызывают раздражение и протест по поводу затраченного времени.
Принцип седьмой: обеспечиваем экспресс-программу. Поскольку условия проведения тестирования могут очень сильно меняться по отношению к планируемым, необходимо разработать чёткую и максимально упрощённую программу экспресс теста продукта. Её же можно использовать для приёмочного тестирования. В эту программу имеет смысл включить: необходимый минимум тестировщиков, время прогона (как правило, желательно уложиться в несколько часов), короткий список наиболее приоритетных проверок только основных функций и основных данных. Даже если в обычном режиме взаимодействие построено на гибкой основе, то во время экспресс-стадии тестирования очень важно оговорить чёткую и непререкаемую схему взаимодействия с командой разработки. Например, если программа не проходит хотя бы один пункт приёмочного теста, то она сразу же возвращается на доработку, тестирование останавливается.
Хороший продукт для заказчика — это продукт удобный в использовании, хороший продукт для исполнителя означает, что он отвечает всем предъявленным требованиям. Цель процесса обеспечения качества состоит в том, чтобы продукт был признан хорошим как исполнителем, так и заказчиком. С увеличением роли тестирования в создании программного обеспечения делать хороший продукт становится легче. Очень показательна и такая тенденция, что серьёзных заказчиков уже не приходится отдельно убеждать в необходимости и целесообразности тестирования. Во всяком случае, за последние 5 лет работы с различными проектами в SaM Solutions мне не приходилось сталкиваться с отказом от тестирования, как от отдельного процесса. Всё больше появляется литературы, интернет-ресурсов, исследований на тему обеспечения качества разработки программного обеспечения. Тестирование — в самом общем понимании этого термина — становится очень многообещающим и перспективным направлением, которое стоит развивать и в которое стоит инвестировать (время, ресурсы и т.п.).
публикации / Ликбез /